Fast-forwarding decision making

Let's go faster.

All organisations waste a huge amount of time believing that they are making progress on decisions, when in fact they’re just involved in the theatre of decision making. This happens through indirect actions that feel like progress is being made, but in fact contribute nothing to it. Small changes can speed up progress dramatically.

This post is an expansion of an internal note that I circulated at work, mostly as advice to myself rather than for anyone in particular. This is because the behaviours that I’m going to outline are unbelievably easy to fall into when you are trying to create ideas, gain consensus, and ultimately make decisions. They feel like progress — little pushes that you can do and feel good about — but ultimately they just create delay.

I’ll pitch the takeaway up front, and it’s this: hold yourself accountable for making decisions and progressing discussions as quickly as possible, by whatever means necessary. Be restless while a decision hasn’t been made. Dead time is your enemy. Be creative about ways of shaving minutes, hours and days from a decision point.

Some scenarios to think about

Let me outline some scenarios where time gets lost. Then, for each, I’ll pitch some alternative ways for progress to be made, faster. These scenarios are simplified for the purpose of this post, but I’m pretty sure they’ll seem familiar to you.

Bug #1: Letting free calendar slots decide your timeline

The first scenario is tragically common. Here’s what happens.

In order to make a decision, you find the list of people that need to be involved in order to reach consensus. Let’s say in this particular case it’s seven people that represent several teams that your decision has an effect on.

Then you open up your calendar and find the next available free slot where the group can meet for an hour to talk the idea over. This happens to be in nine days’ time because of the busy schedules of one or two people in the group. “Great,” you think. “I managed to find a slot with all of us!” 

You smile, because you know it’s hard to find time with this group.

You put some notes in the calendar invite. You write that you want to discuss your current thinking about a new project that your team is doing next. You attach a short document with some notes outlining some different approaches you’d like to discuss and that you want help picking one. 

Then nine days pass where absolutely nothing happens.

Even though you thought you’d made progress — and wasn’t it amazing that you could even get this group together! — you’ve just allowed arbitrary availability in everyone’s schedule decide that your work is going to take another nine days. When you think about it that way, it’s a bit preposterous.

Instead, in an alternate universe, maybe the following happened.

After booking in the meeting and attaching your notes to the agenda, you send a message to the group outlining what your project is trying to achieve and that there are several ways to do it.

You enumerate the approaches in the message and highlight that you think that the second option is the most reasonable. You also say that you’ve reserved a meeting slot in the future if it needs some further debate. However, within 24 hours, all of the people in the group have replied asynchronously to say that they agree that the second option is the most viable, and they’re supportive of your team putting a prototype together. The meeting isn’t needed, and it gets cancelled. You then start building the prototype.

You just saved eight whole days in this alternate universe. And it was just by investing twenty minutes to write a message.

Bug #2: Being afraid of sharing anything other than perfection

Here’s another scenario.

You’re building that prototype, and it becomes apparent that there are several options that you could take to serve the generated data, each with clear advantages and disadvantages around speed, eventual consistency and access patterns.

Given that your team is producing a feature that others are going to use, you figure it’s a good idea to get their input. After all, they’re the customer. You spend an afternoon writing a document containing everything that the prototype has helped you learn so far, and you outline the options to serve the generated data.

However, you’re aware that there are some influential and senior engineers in the group that you’re going to be sending this to, so you want to make sure that you’re not wasting their time when they open it. 

You decide to take the next few days to make sure that your document contains absolutely everything that they would want to see. You spend hours constructing flow diagrams, putting together code samples, detailing and formatting example requests and responses, and referencing all of the different websites and resources that you’ve used in your research in the footnotes and appendix.

When you’re done, you’re proud: it’s a document of great beauty. In an act of pure Friday afternoon celebration, you hit the share button, list out the group that you’re sending it to, and boom: it’s done.

Then you sit and wait for the comments — and maybe even praise! — to roll in. Thirty minutes later, you see a message come through from one of the engineers. It says “we’ve got internal libraries that already handle this problem for you”, and they send you a link to the GitHub repository and the documentation. 

You’ve spent a week trying to solve a problem that’s already been solved. What a waste of time.

In an alternate universe, maybe the following happened.

After realising during the prototype that there were multiple ways in which data could be served from your feature, you decide to ask the teams that are going to use it for their input. After all, they’re the customer. 

You send them a group message: “Did you all have any thoughts on how you wanted to access this data from our feature? I’m just starting to look at this.” One of the engineers replies. “We’ve got internal libraries that already handle that for you, have a look,” and they send you a link to the GitHub repository and the documentation. 

You use that library and finish the prototype more quickly than you thought you would. It’s still only Monday afternoon.

Your alternate universe self just saved almost a week of work.

Bug #3: Relinquishing control into the ether

Just one more scenario, and then I’ll stop.

You’ve been working on hardening up your prototype so that you can deploy it into production for some initial testing with the other teams. Given that it needs to go into the live environment, you spend a few days writing documentation, increasing test coverage, and tidying up some of the hackier bits of your code from earlier in the week.

Once you’re done, you write up a detailed pull request description, and then you submit it for review. You see the CI system build it, run the tests and then produce a green checkmark saying that it’s good to go. You’re pretty pleased with what you’ve done, so you close the browser tab and you wait for those reviews to come in.

In tomorrow’s stand up meeting, you say that you’ve finished the work, but you’re just waiting for someone to review it. You find yourself saying the same thing the next day as well. And the next day. You get a message from the other team wondering when they’re going to be able to start trying your service out in production.

You’re a bit puzzled by the response. “I’m still waiting for reviews, and it’s been three days,” you say. “Why didn’t you tell us?” they reply. “We’ll look at it now.” One hour later, and after a few comments, it’s merged and deployed.

In an alternate universe, maybe the following happened.

After submitting the pull request, you send a message to the teams that are going to use your service to say that it’s available for them to look at. You ask that if they’ve got any time, you’d appreciate some eyes on it. “Sure,” one of the engineers says. “I’ll check it out shortly after I’ve finished this deploy.” One hour later, and after a few comments, it’s merged and deployed.

Your alternate universe self just saved three whole days by sending a message.

Now it’s your turn

Isn’t it amazing how much time we’re willing to waste without really thinking?

You have to take complete ownership over the speed in which decisions are made, and do whatever you can to bring those decisions in faster. Your project, team or company is all about progress: the speed in which you ship, iterate, or fail and learn. 

If something is slowing progress down, then what is it? And how can it be eradicated?

Go into the next couple of weeks with these scenarios in mind, and see whether you can identify them in yourself and others. Give some of the alternative scenarios a go instead. See how you get on. 

Slices of time saved every day, compounded over weeks and months, can actually be the factor that makes the difference between hitting an ambitious deadline and missing it. You might have the most brilliant programmers in the world, but how many days are being lost between the code? Weeks can be turned into days, and days can be turned into hours.

And while you’re here…

A neat opportunity.

My publisher The Pragmatic Programmers have an amazing Spring sale running until 20th April.

You can get 50% off the digital versions of my books by using the code GROW2023 at checkout. If you’ve been on the fence, then maybe’s the time to get off of it.

Here’s the links to the titles:

• Become an Effective Software Engineering Manager

• Effective Remote Work

Until next time.