In the past months, I have learned something about myself. I learned that I value a good development process a lot. One thing, in particular, seems to spark the most discussions: when to make decisions. Some people also call this "When to converge". This topic needs some unpacking.
TL;DR
When you make the wrong decisions too early on, you're setting yourself up for failure. Especially, when there was no need to make that decision this early. To understand the root cause of this kind of problem, you need to understand
- Who makes which decision when,
- what kind of decision you are making, and
- whether you need to converge just now
Context for decisions
This section could probably be a post on its own. We need to clarify who makes which decision when.
Who makes the decisions
I think the assumption that people in management positions or with the word "Manager" in their job title are the only ones capable of making decisions is wrong. At least they shouldn't be the ones who make all the decisions. Building software is a complex task. We hire different people to fulfill different roles, so the people who have the most profound knowledge can make the best decisions.
What is important is that people need to be aware of their abilities. You can and should always reach out to other people to decide which decision is the best. Assuming that other people also do this helps as well. It prevents you from over-defining when to involve which people. When you create an environment where collaboration is valued, then you can trust people to involve whoever is necessary whenever they are necessary.
This paragraph is for all product managers out there. I would bet a couple of bucks that people have told you that your job is "to make decisions." Don't fall into this trap! Your job is to ensure "that decisions are being made" which is a completely different and vastly more complicated task. It prevents the development process from stalling. You can do that by:
- connecting developers to customers,
- arranging sessions with other departments or stakeholders,
- asking, "what do you need to make this call?"
And many more things. Don't let others pressure you into making decisions out of thin air.
Which decisions are there to make
Let's start with what kind of decisions you usually have to make when you're building software.
- Should we build the new feature at all?
- How big does the feature need to be to solve a given problem?
- Does everyone understand the problem?
- Who is going to build the feature?
- Do we need to solve the problem with code?
- Who decides whether a proposed solution solves the problem?
These are just a couple of questions that ultimately lead to decisions being made. You can already be happy if the answers to these questions are accessible and all stakeholders are aware of them. I've seen that many people make assumptions and then base their actions on these assumptions without even clarifying them. That will ultimately lead to chaos because people do not share a common understanding of the desired outcome.
What I would try to do is to be very clear about which decisions you want to take at which point in time. This can drive a discussion around the importance of different decisions. It can also calm other stakeholders who could otherwise confuse deferring a decision with not being aware of it.
When are decisions made
The short answer is: When they become relevant.
For instance, you don't need to decide how to implement a feature when you don't even know whether you're going to build it. I would go even further and say you must not decide this too early on. When you converge too early on in the process, then bad things can happen:
- You might get tricked into making false promises based on the wrong assumption
- It becomes harder to incorporate new insights because you've already settled on a solution
- For the same reason, it can get harder to reduce scope later one because that could invalidate any of these decisions
On the other hand, you don't want to find out that the feature you're building is useless after you spent six months developing it. So the "should we build this or not" decision should be made pretty early on, and it needs to be backed up with good research.
Decision categories
When I think about a decision I mainly think about two aspects:
- Impact: How many people and products are affected, and how much does it cost?
- Reversibility: How hard is it to undo the decision?
Low impact / High reversibility
If the decision's impact is low and you can easily undo it, there is little harm to be done. You probably shouldn't get hung up on it for too long because discussions might take longer than trying something out. These decisions usually are good for experimenting. Run with something for a couple of weeks and see how it goes.
Low impact / Low reversibility
When you make this kind of decision, it makes a part of your system harder to change. However, since the impact is so low, that might not matter this much. It might make sense to defer the decision until you have more context. You should probably at least have some discourse with people about it, but that should be time-boxed.
High impact / High reversibility
Probably try to make this decision as soon as possible. Given that the impact is high, people might want to have some guidelines on how to proceed. It also helps to not work in opposite directions. Should anyone figure out that the decision wasn't optimal, the high reversibility is your friend, and you can easily course correct.
High impact / Low reversibility
Be very careful with this kind of decision. People will probably want a decision, but given that you have a small margin for error, you need to make sure that you have everything you need to make the call. At this point, you might want to think about whether you can turn the big decision into smaller ones with better attributes for impact and reversibility.
Defer decisions if possible
A thing I had to learn is that you can take your time with most decisions. There are not so many things that you need to decide on day one. What is more likely is that other stakeholders want you to make decisions early because it helps them. They will claim that early convergence helps you to plan better. However, I don't want to create a process designed to deliver the best plan to stakeholders but to provide the best value to customers.
Incremental development is key. Because when we deliver software in small increments, the amount of decisions we need to make for each increment is also tiny. This approach makes it also easier to come up with more easily revertible decisions and fewer ones that need to stay forever.
How do you make decisions? Tell me on Twitter: @philgiese.