Beg for forgiveness, don't ask for permission
GitLab says that decisions are the fuel of high-performing teams. A permission culture characterised by risk-averse processes hampers your decision velocity. To break away from a permission culture, teams must focus on three areas.
- Improve your technical maturity so every software decision is reversible, and so you can shrink the blast radius of your decisions.
- Adopt pragmatic decision hygiene. Make consent based decisions your default. Shrink the size of decisions and devolve decision-making to individuals responsible for work.
- Create a culture of autonomy. The signs of such a culture are simple, asynchronous workflows, clear roles and accountability, a "fail fast" culture and an iterative approach to decision making.
When I joined Thoughtworks 15 years back as a bright-eyed young man, I hung onto almost every word of advice my colleagues gave me. In my initial days, I worked with Patrick Sarnacke, who’s now one of our managing directors. He told me it’s often a better choice to “beg for forgiveness than to ask for permission”. I later learned that Admiral Grace Hopper had popularised this phrase.
“Always remember that it’s much easier to apologise than to get permission. In this world of computers, the best thing to do is to do it.”
That sentiment echoes itself in Amazon’s principle of “bias for action”. In fact, that’s the promise of being async-first in the way you work. And yet, collaboration processes on many teams are often risk averse. Almost everyone’s covering their behinds in the name of following a process. Here are a few symptoms I’ve noticed on development teams.
Developers won’t start building out a user story without a kick-off with a product owner.
QAs won’t test a story without a desk-check with the developers.
Teams default to huddles for small design decisions on user stories, instead of leaving that decision to the developers in charge of the story.
People spend hours, weeks and days to build consensus on minor decisions that eventually slow down progress.
I’m sure you can point out similar dysfunctional behaviour from your experience. Teams of high ability individuals benefit from a high decision velocity. If we assume that most decisions are reversible, then it’s fair to assume that when a team makes more decisions, a few things will happen.
They’ll make a lot of excellent decisions. Hence, they’ll make more progress than a team that has a low decision velocity.
They’ll occasionally be wrong. If they’re building software, then many of these wrong decisions will be reversible.
Oh, but what if they make a wrong decision that’s irreversible? Isn’t that the fear that slows us down? Aren’t all our bloated processes a result of this fear? I say we should fear less. Since I know it’s easier said than done, I want to share with you a few thoughts I have about improving decision velocity.
1. Improve your technical maturity
The world of tech has worked incessantly to afford us this reversibility. Between coding principles like DRY, feature toggles, and server rollbacks, we have a way to reverse almost every software development decision.
In a similar manner, your ability to deliver small increments of functionality to your users helps you lower the risk of a sudden, enormous blow up. Practices such as canary releases allow you to roll out features to a small group of users first, before you hit prime-time. Mature tooling and DevOps capability can give your team the confidence that their decisions won’t break the business.
2. Adopt pragmatic decision hygiene
Too often we improve decisions little by little, seeking everyone’s input. While this is indeed the benefit of diverse teams, this also slows us down. Rarely do we weigh the benefit of waiting for perfection vs the opportunity cost of not settling for “good enough”.
I have a few thoughts about balancing decision hygiene with decision velocity.
Consent based decisions by default
Decider.com defines consent as “the absence of objections”. When you have a culture of writing and reading, you can adopt an async-first workflow for decision making. If there are no objections, you go ahead. Only if there are show-stopping objections, should you slow down for consensus. By default, most decisions on your team should be consent based. In an earlier post, I’ve explained what an async decision workflow can look like.
Define the exceptions that need consensus
In most software development gigs, there are very few decisions that are irreversible. I suggest taking the time to identify the kinds of irreversible decisions for your project. For example, decisions that impact compliance or have regulatory implications can be costly if you get them wrong. Decisions related to money may need consensus. When you define the kinds of decisions that may be irreversible for your project context, you also create the safety so people can default to action on the other decisions. Even when you come across one of these high-stakes decisions, figure out how to lower the stakes. You can decompose them into smaller, lower stakes tasks that don’t need consensus.
Leave micro decisions to the individuals responsible for them
This means that when you’re in charge of a task, take full ownership of it. For example, if you’re a developer implementing a user story, here are a few things you can do.
When you pick up a user story, read it end to end and start with what you already understand. If you have questions, throw them into the discussion area for the story. If the responses you get need you to backtrack a bit, be open to step back. In case the story wasn’t clear, share feedback with your product owner so they make future stories clearer.
By default, make the design decisions you have to, for the story you’re developing. Log an ADR if you have to, with the rationale for the decision. Bring it to everyone’s attention and let them respond asynchronously. Unless there’s an objection, you needn’t backtrack. There’s always scope for improvement. Log that on your task board and move on.
When you complete a story, do your own desk-checks. Record a video of the functionality, and walk through what you’ve created, if necessary. There’s a chance that your QA may have feedback. In which case, you can always backtrack.
3. Create a culture of autonomy
At the risk of repeating what I’ve written about earlier, let me say this. There’s no point hiring smart people and then putting them at the mercy of a risk-averse process. So how do you promote autonomy and maintain a high decision velocity? I have a few suggestions.
Simplify your processes
Remove unnecessary gate checks, especially those that exist to handle rare, exceptional circumstances. Instead, prefer a workflow that optimises throughput. Ask yourself - what’s the fastest way to get a piece of work through the system? Prefer automated, asynchronous workflows. Every manual intervention, every synchronous meeting is a bottleneck. They should be more the exception, than the norm.
Clarify roles and accountability
If everyone is responsible for everything, no one owns anything. Take the time to define people’s roles and who is accountable for certain decisions. Inspired by Apple, GitLab advocates for directly responsible individuals (DRI). The buck stops with them for their scope of responsibility. So when it’s time to move on and decide, you know who to look up to.
Promote a “fail fast and learn from mistakes” culture
If you make a lot of decisions, you’ll inevitably make some mistakes. As long as these mistakes don’t tank your project, they represent a cost of progress. Without the safety to fail, everyone will default to the most risk-averse way of operating. Instead, encourage your colleagues to make small decisions and default to action. Use any consequent mistakes as a trigger for learning and introspection.
Disagree and commit
Sometimes there won’t be consensus about a decision. That’s ok. You can choose to wait indefinitely for consensus, or you can make the most prudent decision in the circumstances. The onus for that decision falls on the DRI. The rest of the team can’t continue to disagree at this point. They must commit to the decision from this point on. While you commit and support the decision, nothing should stop you from building your case for a pivot. This is the disagree, commit and disagree variation from GitLab. All decision making is iterative, but while a decision is in force, the team must commit to it.
Albert Einstein
“A person who never made a mistake never tried anything new.”
A permission culture stifles innovation. The more people and teams fear mistakes, the more rigid and risk-averse processes become. Instead, embrace mistakes as the cost of progress. Recognise that dividing and conquering a problem is also collaboration. Empower each other to decide for your parts of the problem. If things go wrong, be willing to backtrack and learn from mistakes. You have two choices.
Make fewer decisions and fewer mistakes and get slower progress, and slower learning as a result.
Aim for a high decision velocity, take mistakes in your stride and make faster progress and learn from your mistakes.
I’ll choose the latter any day. What about you?