There is a particular skill I would like to share, which I wish I had learned when I was younger. I picked it up through working closely with a previous boss (a CTO who had founded a company and raised it up to hundreds of employees and multi-million dollar deals) but it wasn’t until I read The Story of VaccinateCA that I noticed it was a distinct skill and put into words how it worked. The Sazen for this skill is “One Day Sooner.” I would like to give warning before explaining further however: This skill can be hazardous to use. It is not the kind of thing “Rationalist Dark Art”  describes because it does not involve deception, and I think it’s unlikely to damage much besides the user. It’s the kind of thing I’d be tempted to label a dark art however. Incautious use can make the user’s life unbalanced in ways that are mostly predictable from the phrase “actively horrible work/life balance.”

It works something like this: when you’re planning a project or giving a time estimate, you look at that time estimate and ask what it would take to do this one day sooner, and then you answer honestly and creatively.

What does it look like?

I used to work directly under the CTO of a medium sized software company. My team was frequently called upon to create software proofs of concept or sales demos. The timelines were sometimes what I will euphemistically call aggressive. Consider a hypothetical scene; it’s Thursday and you have just found out that a sales demo is on Tuesday which could use some custom development. Giving a quick estimate, you’d say this needs about a week of work and will be ready next Wednesday. What would it take to do this one day sooner?

Well, obviously you can work through the weekend. That gets you two more days. Given a couple of late evenings and getting enough total hours in is easy. That’s not the only thing though. There’s some resources from Marketing that would be good to have, you emailed them and they said they could meet with you on Monday. You want this faster though, so you walk over to their office and lean in, pointing out this is a direct assignment from the CTO so could we please have the meeting today instead. What else? Oh, there’s a bunch of specification writing and robust test writing you’d usually do. Some of that you still do, since it would be a disaster if you built the wrong thing so you need to be sure you’re on the right track, but some of it you skip. The software just needs to work for this one demo, on a machine you control, operated by someone following a script that you wrote, so you can skip a lot of reliability testing and input validation.

I appreciate The Story of VaccinateCA, a description of an organization whose goal was helping people get the Covid-19 vaccination. I think it is worth reading in full, but I will pull out one particular quote here.

We had an internal culture of counting the passage of time from Day 0, the day (in California) we started working on the project. We made the first calls and published our first vaccine availability on Day 1. I instituted this little meme mostly to keep up the perception of urgency among everyone. 

We repeated a mantra: Every day matters. Every dose matters. 

Where other orgs would say, ‘Yeah I think we can have a meeting about that this coming Monday,’ I would say, ‘It is Day 4. On what day do you expect this to ship?’ and if told you would have your first meeting on Day 8, would ask, ‘Is there a reason that meeting could not be on Day 4 so that this could ship no later than Day 5?’

This is One Day Sooner. 

I have worked in environments that had this norm, and environments that did not have it. I have asked questions analogous to “Is there a reason that meeting could not be on Day 4” and received answers roughly equivalent to “No, not really, I just didn’t think of that.” As a result of deliberate choices in my career path, I have never had human lives so closely tied to the speed at which my team could execute but I strongly believe having lives on the line would not magically make more people adopt more speed.

One more note on what One Day Sooner looks like: I find it exhilarating and rewarding to work in this mode and suspect this is true of some others as well. You don’t twiddle your thumbs, you don’t accept being put off, you don’t do a lot of unnecessary busywork just to make something simple happen. I often found it fun, even when I sometimes worked fourteen hour days, because things were happening and moving forward fast and I felt like I had an impact. Your mileage may vary.

How do you do it?

Above all else, it works by asking yourself every day what it would take to get this done one day sooner.

First, set a goal. Clearly describe what outcome you want. This description does not need to be a detailed multi-page specification sheet, and I suggest that you should have an evocative one sentence or at most one paragraph core goal even if you write a more detailed specification to describe the details. 

Second, frequently ask what your blockers are and what the next step is. A blocker is anything that prevents forward motion towards the goal. A step is an incremental motion towards the goal. If you’re walking to a destination, a blocker is a deep river in your path and a step is a footstep in the right direction. 

Third, take responsibility (possibly heroic) for removing blockers and taking steps. After every step you take, you should be closer to the goal. It doesn’t matter if the blockers or steps look like they’re in your job description or not. It may be more useful to ditch the entire idea of responsibility and just think about what steps to take.

Fourth, keep alert for weird ways of solving the problem or signs that you’re off target. It may be worth Babbling and Pruning, or Actually Thinking For Five Minutes, or Actually Trying. It may also be worth thinking about what you’d do with vastly more resources. This is especially true if you are blocked. Your steps must actually be leading towards your target, even if they’re attempts with expected value instead of uncertain value.

As a technique, One Day Sooner does not mean turning in low quality or shoddy work. “This thing should be polished and reliable” is something that can be part of your goal. Sometimes this technique means taking a hard look at exactly how reliable something really needs to be, because the answer is that something which works half the time and is ready one day sooner is actually better. Sometimes this technique means taking a hard look at how reliable something normally is, because the answer is that something which works 99% of the time is unacceptable.

I know that I spent more words talking about what it looks like and how it goes wrong than how to do it. This technique is more about an attitude than a procedure. If you notice the attitude conflicts with the above procedure, throw out the procedure and actually cut.  

What would it take to get this done one day sooner?

How can it go wrong?

This list is not exhaustive. This list is largely compiled from personal experience or close observation. While some highly esteemed deeds happened in very close proximity to this list, this list itself is not a place of honour and this list is a warning about a danger.

The concept of Taboo Tradeoffs may be useful at this point. 

Part of what makes this technique work is aggressively looking for things to trade off in service of moving your timeline forward. Anything that is not part of your goal is likely to get traded off. If you paid attention in How Do You Do It or if you’re paying attention while working on your goal, you’ll notice if something is about to get traded off and should have been part of the goal. One Day Sooner doesn’t have to trade off safety, important tests, or looking polished, though it can. In my own experience, this technique induces tunnel vision where things that aren’t your goal fade in importance.

Sunday afternoons relaxing in the park, your workout routine, and eating things that aren’t frozen pizza are usually not made part of the goal and thus suffer. You can mitigate this by establishing a soft rule to work under One Day Sooner norms for up to a fixed duration (mine was two weeks) and then stop and work at a slower and more relaxed pace. You can also mitigate this by establishing firm boundaries around what resources (including your time) that you allow the goal to make use of; the technique still works if you only allow it to make use of the hours between nine in the morning and five in the evening just as it works if you don’t allow it to spend money. This technique is by default actively hostile to the concept of “time off.” Mitigation is not prevention.

The long term consequences are unlikely to be part of the goal. Sometimes you can speed up a process by throwing lots of money at it, and this is the correct tradeoff to get your target One Day Sooner but a poor tradeoff in an absolute sense. Sometimes you burn yourself or your teammates out and render people basically useless for months in order to get twice the productivity from them for a week, and this is the correct tradeoff to get your target One Day Sooner but a poor tradeoff over the long view. You can mitigate this by having someone in the loop who isn’t dedicated to your goal and can push the brakes. Mitigation is not prevention.

Many people you interact with will not share your goal, or at least will not share your target of making it happen One Day Sooner. When talking to these people it is easy to come across as rude, obsessive, annoying, or otherwise a problem. Knocking on someone’s door twice a day to ask if they’ve signed off on that thing you sent them can seem perfectly reasonable from within your One Day Sooner tinted glasses. It is unlikely to make that person think fondly of you. You can mitigate this by thinking of goodwill and attention as a finite resource to be spent wisely. You can also mitigate this by inculcating the One Day Sooner approach in them and convincing them that your goal is a worthy one. Mitigation is not prevention. 

Related to long term consequences, it is possible when aiming this hard at a goal to break rules. Sometimes this is on balance worth it. I am not going to say that it is never worth it and that all rules are well crafted and vitally important. I am going to caution that if you notice you’re about to break a rule you should stop and think about that decision. Having someone not invested in the One Day Sooner loop around to vet your questionable choices is one form of mitigation, but those people can have a lot of incentives towards caution that take much of the power of the technique away. If circumstances permit, having open communication with someone in real authority (say, the person who wrote and enforces the rules and has the authority to suspend them) helps tremendously. The best mitigation I’m aware of is keeping a careful distinction between policy, best practice, and law. Mitigation is not prevention.

This technique is about going very fast towards a goal. It does not help you decide if this is a good or worthwhile goal. Completing a desperate race to the finish line only to find out that you created the wrong thing hurts, and you are unlikely to have the reserves to try again. You can mitigate this by being careful with your initial spec and doing frequent mini-demos or having a minimum viable product that’s actually getting used. Mitigation is not prevention.

Conclusion

I wrote and published this for three reasons. One is that I wish I’d understood this principle earlier in my career and so wanted people like me to be able to find and learn the technique earlier. I find working like this to be exhilarating and could have optimized my career to get to do more of it. If you’re trying to get important work done quickly, I want you to have this tool. The second is that this is a technique I keep available and polished in my mental toolbox, and would like a place to point people at to explain why I might be metaphorically (or literally) knocking on their office door twice a day.

The third is that sometimes this is a bad technique to use. I mean “bad” in the sense that it will burn up your time, relationships, and health in the service of a goal which is not worth any of that. Some communities and organizations can inculcate this technique without spelling out what exactly it means. Worse, some people may wind up slipping into this mentality without the goal and burn themselves on it. Naming the technique makes it easier to see it and do something which is not that. If you're going to push yourself like this, please do it for a goal you actually thought about and decided was worth it.

New to LessWrong?

New Comment
5 comments, sorted by Click to highlight new comments since: Today at 9:42 PM

I think Anthropic didn't have this mindset with the recent sparse coding paper. I heard rumors about it before publishing, but after publishing there was a bunch of interest into sparse coding, with multiple teams working on circuit discovery and elsewhere in interpretability. Plausible to me that if a draft were widely shared this could have happened sooner.

This is a really good post. It is simple, coherent, and does a good job accounting for problems.

A concrete example of this kind of thinking focused on getting stuff is jacobjacob's How I buy things when Lightcone wants them fast post.

Yeah, How I Buy Things is a pretty central example of this kind of thinking and has a good list of specific tactics.

Thank you for the compliment! 

Nice, for me, this was one of those things in the business world that was kind of implicit in some models I had from before, and this post made it explicit. 

Good stuff!

The section on ‘How do you do it?’ looks like a generalised version of John Platt's Strong Inference, a method of doing science that he believed ‘makes for rapid and powerful progress’. The essence of Strong Inference is to think carefully about a scientific question (the goal) to identify the main competing hypotheses that have yet to be discriminated between (the blockers), and devise and perform experiment(s) that rapidly discriminate between them (taking responsibility to remove the blockers and actually perform the next step).

Strong inference consists of applying the following steps to every problem in science, formally and explicitly and regularly:
1) Devising alternative hypotheses;
2) Devising a crucial experiment (or several of them), with alternative possible outcomes, each of which will, as nearly as possible, exclude one or more of the hypotheses;
3) Carrying out the experiment so as to get a clean result;
1') Recycling the procedure, making subhypotheses or sequential hypotheses to refine the possibilities that remain; and so on.

He also favoured Actually Thinking, as opposed to scientific busywork:

We speak piously of taking measurements and making small studies that will “add another brick to the temple of science.” Most such bricks just lie around the brickyard. Tables of constants have their place and value, but the study of one spectrum after another, if not frequently re-evaluated, may become a substitute for thinking, a sad waste of intelligence in a research laboratory, and a mistraining whose crippling effects may last a lifetime.