Who should decide?

I’ve come to like the saying “don’t ask for permission, ask for forgiveness”¹. It reflects the reality that most decisions don’t need approval, and waiting for blessing only causes delays, overburdens approvers (usually managers or senior colleagues), and most importantly, doesn’t support the freedom and independence of team members.

What does this actually mean in practice? That I don’t need to ask about anything, consult with anyone, or request permission?

Reversible and irreversible changes

Some changes/decisions are irreversible or nearly irreversible—like one-way doors². Once we go through them, they close and we can’t go back. Such decisions deserve careful, methodical, and “slow” decision-making. Most decisions, however, aren’t like this, even if they might seem so at first glance. Most decisions are changeable—they’re normal two-way doors. In other words, if our decision proves sub-optimal, we can change it, improve it, or even reverse it. Simply open the door again and go back. Such decisions can be made by individuals or small teams.

Many teams and organizations, especially as they grow, tend to treat more and more decisions as one-way doors requiring lengthy decision processes. This leads to significant slowdowns in implementing changes, unnecessarily avoiding experiments, and thus suppressing innovation.

Ask for rejection of change

Instead of requesting approval for a change, offer the possibility to say no, but with a clearly defined timeframe.

In reality, it might look like this: I want to change the somewhat illogical navigation structure on the company website. I have the change prepared, it makes sense to me, but maybe I’m missing something—I don’t know the entire company history, I don’t know why the navigation looks exactly this way. I’d like to get approval from my boss.

I could write to him: Hey boss, I want to change the website navigation to X. I think it will increase visitor conversion. What do you think? Can I do it?

If your boss has a full calendar, it can easily happen that you’ll get an answer after several days, or never… To answer “yes,” he probably needs to verify several things. Remember historical decisions, conduct experiments, etc.

But we can modify the query slightly:

Hey boss, I want to change the website navigation to X. I think it will increase visitor conversion. I’ve already tested it locally. If you don’t have any objections, I’ll deploy the change on Monday.

What have we achieved?

• We’re not blocked in our work, we assume approval and continue.
• We’ve set a deadline for when the change will happen³.
• We’ve informed about the planned change.
• We’ve provided space for feedback, if needed or if the person asked has time to share extra information.
• We’re also signaling (without needing to explicitly boast) that we have a plan and know what should happen next.

When to seek consent?

For changes that are closer to irreversible⁴, it’s clear that it will be appropriate to get consent. Perhaps through an RFC process, written narratives, etc. However, there are other situations where it’s good to ask for explicit consent:

• Is now a good time to start asking about the details of your proposal?
• May I interrupt you now?
• Would you be okay if we try to start this conversation again from a completely different angle?
• Can we return to topic X and go more in-depth?

All examples aim to gain the other party’s consent to express a different opinion, potentially a completely opposite one. They allow for refusal. We then know that the other party isn’t ready to discuss, to hear feedback. We’re creating a safe environment [safe-harbor] without which constructive discussion⁵ isn’t possible.

Who decides?

In many organizations, it’s simple—my manager/superior. If we’re striving for an exceptional company, this shouldn’t be enough for us. One of the building blocks of an exceptional company is responsible and autonomous people (responsible, autonomous, having ownership). Can we ask an individual to be responsible at work while simultaneously not being responsible for (some) decisions?

If you’re not failing, you’re not pushing your limits, and if you’re not pushing your limits, you’re not maximizing your potential

— Ray Dalio, Principles

Who should make decisions?

Every individual should be able to make decisions on certain issues. How do we recognize who is suitable for making a decision on a given question? Key criteria are:

• Proximity to the question—Who is closest to the issue? Who best understands the context of the problem, the operational details? Someone who is both in the details but also capable of perspective.
• Perspective—being close to the problem is important, but sometimes it’s even more important to be able to step back and look at the problem from a higher level/different perspective.
• Experience and Expertise—Someone who has already solved similar problems. What did their decisions lead to?
• Wisdom and Breadth—What decisions have they already made in other areas? Do they have sufficient overlap with other activities or teams? Do they understand the impact on these teams?

The role of the team leader

In many organizations, the team leader is overwhelmed with requests to make decisions about (for) team members’ proposals. Yet one of the main tasks of a leader is to select the right person who should be responsible for the decision. Part of the role of all leaders in an organization is to enable decisions to be made at the right levels and by the right people. Not to decide for “everyone.” They enable this by focusing on building a safe environment (safe-harbor), supporting and reinforcing appropriate procedures, tools, and processes (e.g., selecting the right person to whom the decision can be delegated).

Gathering feedback

In a decision-maker culture, the decision-maker makes the final call but must ask for advice. Deciding who to get advice from can influence a successful outcome.

— Dennis Bakke, The Decision Maker

For more important decisions, use slightly more formal tools, such as written narratives, RFCs, etc. But even for simpler decisions, it pays to write what is actually being decided, why, and how it was decided⁶. The duration of the review process and the number of people involved again depends on the complexity and impact of the decision (is it a one-way door?).

The decision-maker doesn’t decide in an information vacuum, but rather must request input from people who have:

• experience—naturally, I’m interested in the opinion of someone who has already solved a similar problem.
• different positions—people in different positions have different views on the same problem. Therefore, it’s useful to get the perspective of someone from management, as well as colleagues in the team and other departments⁷. Maybe I’ll need to look outside the company.
• ownership—if we involve more people in the review process, they naturally start to feel co-responsible and will be more engaged. The review process isn’t just about making “right” decisions. It’s also a tool for building a stronger organization, supporting inter-team collaboration, and transferring information across the company.

Every decision has an impact on other people. The person who made it is responsible for it. But no one is infallible. If the person followed the review process, there’s no reason for any penalty—but room for growth. As already mentioned, the ability to make decisions and learn are important motivational elements.

Completing the decision

An equally important phase of making a decision is its documentation and communication. Decisions that no one knows about are useless. The decision-maker should:

• ensure appropriate documentation or its update⁸ (wiki, project documentation, ticket, …)
• communicate the decision (email, slack/Teams, team or company presentation, poster on the bulletin board, …)
• monitor and ideally measure the impacts of the decision

What if the decision proves to be bad? Evaluating success should be a standard part of the process (see the last point above), so the development shouldn’t be a surprise. The problem isn’t that a potentially bad decision was made; the problem would be ignoring the development and simply letting it be⁹.