Take a random situation, some every day scene – and make a decision. I feel that kids are born with the ability to just decide, at least that’s my take away when watching my kids making countless decisions each day. Vanilla or chocolate, Bicycle or Football, Indoor or Outdoor. There’s not as much deliberation and thoughtfulness in those as I’d like to see at times – but it’s ok, the output is there.
Decisions are vital to get from point a to point b. You have to decide that you want to go to point b, you have to even decide that you might want to be somewhere else in the first place. You have to plot a plan and decide on which route, which approach to take. You have to decide when to start. There’s plenty of big decisions that contribute to a plan succeeding or failing, and there’s a plethora of small decisions that people usually forgot about in hindsight. Let’s talk about decision making.
My kids don’t mind making all the big and small decisions themselves. And there’s something very honest in the way they decide and move forward, the acknowledgement that, at the end of the day, someone will have to make a call.
Who’s making a decision in a project, a team or an organisation? That’s a thing I stumble upon quite often. I fundamentally don’t think that teams can make decisions – individuals do. My question is along the lines of “who decides if the group disagrees” – and that’s usually the one person calling the shots. If everyone agrees on something, is that really a decision? Let’s all have cake. Super controversial. No veto. Surprise.
Healthy decision making demands clarity on who is making what kinds of decisions. You have a tech lead, and what exactly is the tech leads authority? In a lot of cases, that boils down to establishing specific areas where the final authority for decision making is described in a clear way (that can just be verbal agreements, no need to bring out the contract printer.) That doesn’t mean that one person should be making all the decisions in their funny little decision room. Of course decisions should be massively influenced and discussed by the groups that will be affected by the outcome, but it’s just not realistic to pretend that companies, organisations, software teams function best as democracies. The most needed ideas, sometimes, are the least popular ones – at least in the beginning.
Ok, so you need to make a decision on some critical topic. How do you go about it? There’s probably research on it, but I’d break it down into roughly three phases.
The first is the one where the problem is explored and possible solutions are discovered and discussed. This is the phase where the team learns the relevant context for an upcoming decision. Say you want to build a new service and are unsure what the right programming language to use for that new stack is – this is where you’d explain why a new service, why the ask for looking at the best languages and so on. You share information to help everyone to inform the decision making process in the best way possible. You also use this time as an opportunity to learn as much as possible about the viable solutions or options. However, there’s one important thing to consider in this phase. The first is to only actively involve as few people as possible. The second is that this whole phase needs to be aggressively time boxed. Why?
There’s a point where gathering more information, discussing more nuances about something stops adding value. Imagine you’re in a restaurant and you have no idea what some item on the menu means – maybe because it’s in French and you forgot everything you learned in French. You ask the server, and once she starts explaining that it’s something with Fish you know what you need to know. It really doesn’t change your mind if Mr. Fish has been fried in a pan, boiled in hot water or is actually raw. You just hate fish. The point at which you were equipped with everything you needed to know to make a good decision was reached super early, and everything after that was just not needed.
So make sure to listen, to gather input, to involve folks that need to be involved, but focus on getting to an actual outcome. I’ve coined the phrase of “making sure the size of the process fits the size of the problem” around here, and I think it’s very suited for informing the duration and extent of decision making processes. If 3 people are affected and they all agree, that’s your decision right there. If something alters the course of a project for three years, well, maybe give yourself and the group some more time.
Phase two is where the decision is actually made and explained. Those things go together. I think that much more decisions are made everyday than is generally known, simply because folks don’t speak about that. Making a decision is one thing, but you need to take some time to explain what was considered, why a call was made in a certain why and how that will now be actioned (if applicable). This is also a great time to make sure you acknowledge disagreement, if any exists. As a general rule, I try to not make a decision if I can’t explain why I made it – that’s a good thing to either go back to learning more on, or to delegate to more knowledgeable folks. Decide, Explain why, move to action.
Third phase is moving to action. In this phase you need to urgently stop discussing the other options. It adds no value and only makes you slower, less focused and less good. Do one thing, and be committed about that. The worst you can do when executing on something is to half-ass it. If you decide to do build the new service in Rust, you don’t want to debate every second day how much better it would’ve been to build it in Ruby. Might have been, but is not. The value of doubts in this phase is limited – either you're learning something so significant that you have to change the approach alltogether: then it's not doubts, it's stopping and reevaluating. That has value. For anything else, doubts only serve to slow you down and distract. Don't do it.
There’s a fourth phase. That’s the one of learning. Learning what went well and what didn’t, what should have been considered but wasn’t. I feel a critical reflection with all of our small and big decisions is necessary every once in a while, but make that something that lives outside of your regular decision making flow. Find problems, find solutions, make a call.
The value of having a decision making process that is fast, transparent and based on ownership and clear roles is priceless. This is what makes teams actually fast. Really, really fast.
Decide. Build. Ship. Rinse and repeat.