Deadlines & Estimates

Building products is littered with deadlines, estimates and plans based on those things. They have many good uses, but we often use them as a very blunt instrument and create bad outcomes.

Want to know what these “bad outcomes” are? Build a better toolbox? Want to know a magic trick? Read on, friend!

These things should come with warning labels

Deadlines and estimates are not free. They have risks and problems that sometimes we don’t see as they’re so embedded in our day to day practices.

Estimates are wrong

Jerome goes to the bank and asks the teller “how much money do I have?”. Which is the more helpful answer: “$30,000” or “I don’t know”?

It’s “I don’t know”. Because Jerome actually has $100 in his account. Knowing is only better than not knowing when you’re right.

Estimates are inherently fallible and likely incorrect. When we ask for them and make decisions based on the answers, we can rapidly get into trouble.

Estimates convey uncertainty... uncertainly.

We all know that estimates are not precise. But people understand different things by an estimate of “2 weeks”. One person might think best case, one worst case, and one “best guess, so worst case 3 weeks”.

But the person talking might’ve meant “best guess 2 weeks as long as we don’t hit a major issue that takes 3 months to resolve”. We all think we know what’s going on, but we’re normally all wrong.

Estimates turn into deadlines

When you ask someone how long something is going to take, they normally tell you. You may forget about it quickly, but they hold onto it. It’s a commitment they’ve made and they want to stick to it. Without setting a deadline you’ve created one by accident. But why is that a bad thing?

Deadlines create crunch. Crunch builds bad products.

If you ask smart people for something by a deadline, you’ll probably get it. Unfortunately, along the way they’ll compromise quality, stability and a bunch of other “non-essential” work to hit that deadline.

Crunch ruins productivity and burns people out

To meet a deadline people will normally feel compelled to work long hours to make it. This spike in hours is not free. They will be less productive on the other side. But now you might have another deadline. The productivity is lower, so the crunch is harder at the end and the drop in productivity is worse.

This cycle continues, with everyone feeling proud about the hours they’re working, while being less and less effective; until they burn out.

So, the estimates we’re asking for aren’t helping that much, they’re causing people to feel false deadlines that then causes bad product decisions and trashes our productivity. What can we do instead?

A new toolbox (with a magic trick at the bottom)

Most people’s toolbox just contains the question “how long will this take?”. It’s a blunt tool that comes with so many of the problems we talked about earlier. I don’t have 1 tool that’s better in every situation, but I do have a lot of better tools I use that handle specific situations. Maybe you have other tools, I’d love to hear about them!

Note: All of these can be questions from someone to someone else, or someone to themselves.

Q: How confident are you it will be done by Friday? A: 70%.

This is your go to when the timeline is being set externally. It makes the uncertainty explicit, is clear that there is a possibility that it might not happen, and gives everyone enough information to make decisions based on that uncertainty.

Q: How long will this take with X% confidence? A: 3 weeks.

Sometimes other work depends on your work. Someone might need to know the earliest it’s reasonably ready, or when it’s pretty much guaranteed. This question actually drills into what you want to know, and makes sure both parties are on the same page about what the estimate actually means.

Q: What’s the T-shirt size of this? A: M.

This is much more commonly seen. Most people have done this. You have a bunch of different projects, a guess at the impact of each and you want a guess at engineering effort so you can prioritise the low-hanging fruit. The important thing in this case is the relative cost of the work, not the absolute cost. So use whatever scoring system you want: s/m/l, cherry/apple/pineapple, 1/2/3/5/8. The important thing is to stay away from real times but give a relative sense of size.

We need to have everything finished 3 months from now. So, how can we be finished 3 weeks from now?

Sometimes external deadlines are set. They’re firm deadlines. They’re almost always set by people external to the company. Regulatory agencies don’t care that it was a rough week, they’re going to fine you anwyay. These hard deadlines are defined by the fact that work after the deadline is massively less impactful than work before the deadline. “The CEO wants this by Friday!” is not this.

The goal here is to deeply understand the requirements of this hard deadline. Not the loose version of them. This is the time to be persnickety. Poke and prod at every line and figure out what the absolute most important thing you need to do is. Now figure out how to do that so far before the deadline that no one is even worrying about it yet. Now iterate and add in the softer requirements piece by piece. When the deadline comes, don’t panic. Just ship what you have. It was ready months ago, now it’s just better.

I originally encountered this approach during a story someone told me at at a conference. They were leading a team at a bank who had to build out a system for doing regulatory reporting for some new legislation. The fines for missing the deadlines for this reporting were huge. However, the rules were insanely complex and they quickly realised they were not going to finish everything. They went to management, explained the problem and started looking for a solution. It turned out, the fines were for *not sending the report*. You then got another 3 months to correct any errors. The team went back, focussed on making sure *there was a report* and then started adding as many use cases as they could. They sent off the incorrect reports, but got another 3 months to fix the problems.

Importantly in these cases, saying it’s a “must hit” deadline doesn’t get you anything. Work doesn’t appear out of thin air. Quality, stability, correctness, actually finishing is going to be cut somewhere. You can think critically and choose where you’re going to make compromises upfront, before panic sets in, or you can bury your head in the sand and make those compromises accidentally.

The Magic Trick

Now, we get to the most important tool of all. The tool that does genuinely magically fix every problem with deadlines. The tool I reach for most often and has always brought me the greatest success.

Anything I can do to help?

Don’t ask for an estimate. Don’t set a deadline.

The vast majority of the time I just don’t care how long it’s going to take. It’s not going to change any decisions or make a difference. We’re asking because that’s what we do, so we can write it somewhere and all feel like busy business people who are doing business well. Is this work the most important thing? Let’s do it. It’ll be done when it’s done.

When someone asks me for an estimate, I ask what decision they’re trying to make and we find the right tool. Normally it’s this one.

So before you ask “how long do you think it will take?” please take a moment to think whether the value of knowing that information outweighs all the problems we talked about earlier and maybe, just maybe, don’t ask.

Instead ask: “Anything I can do to help?”.