It’s hard enough making decisions by ourselves. Sandwich or salad? Coffee or tea? T-shirt or button-down? Now imagine if your whole team was in your closet, helping to choose your outfit.
The teams we work with represent a wide variety of expertise and experience, and that can cause conflict when a decision needs to be made. Aside from being frustrating on a personal level, the resulting delays actually harm our work. The longer your team deliberates over decisions, the more time you waste. Time that could be used to act.
No team sets out to spend months making a decision, but far too often, that’s exactly what happens.
I lead a development team at Atlassian. We’re responsible for account creation and login across all our products, which is a high-stakes game, both for our customers and our business. So we understand the decision-making struggle all too well.
Because we deal in security issues and personally identifying information, the decisions we make tend to be complex. We’ve spent a lot of energy improving our decision-making process so we don’t get stuck in “analysis paralysis”. Our goal is to make sound decisions without losing momentum on a project. Then act on them, get feedback, and iterate on them as necessary.
Here’s how our team tackles our biggest, hairiest decisions.
We picture it
When a decision starts to get bogged down in circular conversations and you feel like you’re a mindless host in a WestWorld narrative loop, it’s time to step back and try to understand why you’re struggling to make progress. Visualising the uncertainty can be a very useful technique. We do this as soon as we’ve identified a problem or decision as particularly tricky.
We use a problem space graph to visualize our decision and understand the factors that are making it tough.
We consider what we’re hoping to achieve with this decision and why (requirements), as well as how we’ll go about solving for it (solutions). Plotting these two factors against each other on a graph gives us a rough measure of how hairy the decision is, and an indication as to why. Is disagreement on requirements the crux of the issue, or is it mostly uncertainty about how we’ll fulfill them? (Or both in equal parts?!)
Once we see what’s hardest about the decision, we can think through the factors that make it complex and solve for those first.
We break it down
Decisions that are complicated on both the requirements and solution fronts are the hardest to contend with. On our team, we have thorny login and authentication use cases (the how) to solve for that are often discussed alongside philosophical principles about account ownership and privacy (the why).
Whenever possible, our team parse why+how decisions into smaller, digestible chunks. If our dot on the graph shows the problem is a bit more complicated on the requirements side, we’ll set aside the debate over solutions until we agree on requirements. That way, we’re tackling the question of why we’re doing this before getting into how we’ll do it.
In the case of requirements-heavy decisions, the why should inform the how. On our team, these are typically decisions that focus on principles and customer experience.
Let’s say we set out to improve single sign-on across our products. There’s no sense in trying to figure out technical implementation when we’re still debating whether to focus on the admin experience or the end-user experience. Once we’re agreed on that, the remaining decision/s about solutions are more likely to be in “simple” or “complicated” territory.
We own it
Decision ownership is the most vital element of team decision making because it’s what holds up the process more than anything else. Without knowing who is ultimately accountable for making the decision, we procrastinate or assume that someone else is working on it.
While it is true that some simple decisions can be made by team consensus, the hairy ones go smoother when each person involved knows exactly what their role is. On my team, we use a decision-making framework called a DACI to clarify where everyone sits on the ownership continuum. Here’s how DACI breaks it down:
- D = Driver. The person responsible for corralling stakeholders, collating all the necessary information, determining scope of the decision, and getting a decision made by the agreed date.
- A = Approver. The one person (yes: one!) who makes the decision. This turns the approver role from a passive “rubber stamp” into a very active “decision maker” role.
- C = Contributors. People who have subject-area knowledge and can make recommendations – i.e., they have a voice, but not a vote.
- I = Informed. People whose work may be affected by the decision, and should be informed once it’s been made – i.e., no vote, no voice.
While some may bristle at the thought of having only one person make the final decision, the process is still very much team-oriented. Each person has a role to play, and even people from outside our immediate team are occasionally pulled in as contributors.
DACI isn’t something we invented. It’s used by lots of teams at lots of companies. You can google for more info on the basics of setting one up (or just go here), but there are a few pro-tips from my team I want to share.
- If a decision has been classified as complex or chaotic, the approver and the driver should connect early on and plan the decision like a project. Together, they nail down the scope, timeline, and dependencies. Then the driver is responsible for making sure conversations about the decision stay within the agreed-upon scope. Other stuff that comes up should be tabled, so your team can stay focused on the main thing.
- The approver should be an active, engaged participant throughout the course of the decision, reviewing feedback and recommendations from contributors as they come in (as opposed to waiting until the last minute and glancing through it).
- While the driver is the one responsible for making sure the decision-making process moves along, the approver should feel empowered to step in and right the ship if it starts to stray into troubled waters. I.e., if the process becomes dysfunctional in some way. The approver is the one tasked with making a call by a certain date, after all.
- Anyone in the contributor role should back up their recommendations with research, data, and/or first-hand experience as much as possible – insights instead of opinions.
We make it and get on with it
The trick to problem space diagrams and DACIs is not to wallow in them. At some point, you have to make the decision. The sooner you can do that, the sooner you can act on it and get the data you need to determine whether the path you chose was effective. If we spend all our time agonizing over making the best decision, we never get the momentum that comes from acting and iterating on them. That momentum is what eventually leads to success.
You may never get the whole team to feel wonderful about the outcome. But once a decision is made, commit.
On our team, we say “disagree, and commit”. It’s healthy to disagree, offer up your perspective, and support it with data. But at the end of the day, we agree to rally around the decision and work to make it successful, regardless of whether we prefer it or not.
It’s better to make a good decision and act, than to obsess over making a perfect decision. If a perfect decision even exists at all.
Also published on Medium.