Leading
Three Stages of Decision-making
The last thing you want in a fast-growing company is for decision-making to slow down the pace of progress. However, if you aren’t clear about how decisions are made, who gets to make them, and who else is involved, that’s exactly what will happen.
So how do you avoid decision (or indecision) issues? I recommend thinking of it in three stages. Every company should adopt the first one. Subsequent stages should only be adopted as the company grows and requires more sophisticated guardrails.
Stage 1: Decision Records
In the early stages of a company, up to 10-20 people, decision-making is intuitive. Everyone is aware of key strategic decisions being made by various people, but it won’t always be that way. As a gift to yourselves and your future teammates, I encourage every company to start creating Decision Records.
A Decision Record is a document that explains why a decision was made, who made it, who else was involved, and what context informed the decision.
The lightbulb went off several years ago, when an engineer on our team introduced me to the concept of ARDs, or Architecture Decision Records. Immediately, it seemed ARDs would be valuable for company-wide decisions, so we merely removed Architecture from the name.
Decision Records are necessary because, as time goes on, it’s often unclear why certain decisions were made. Maybe the person who made it is no longer in the company. Maybe the underlying reason for the decision is no longer valid. Or maybe you just forgot. With Decision Records, it’s easy for you and anyone else in the company to get the facts.
To take things a step further, you can share Decision Records with the team. At Help Scout, every time a Decision Record is published, it goes to a public Slack channel everyone can follow. It’s one of the many things we do to ensure our remote team stays connected to the pulse of the business.
Stage 2: Creating ARPAs
As more people join the company, it’s more complicated to figure out who makes what decisions. At that point, it’s important to start writing it down. We created a framework called ARPA at Help Scout, which is derived from the RACI matrix. We basically modified the terms and definitions to better align with how we wanted to operate.
| Role | Description |
|---|---|
| Accountable | The person who is accountable to the business for success. Strategic decisions related to the project or initiative are made by this person. |
| Responsible | One or two people who are responsible for day-to-day execution, making sure the work gets done within project constraints and meets our standards of excellence. Tactical decisions related to the project or initiative are made by these folks. |
| Participant | People who allocate time and resources to support the project’s delivery, but for whom the project is not a primary role or responsibility. They make decisions related to the quality of the work, but they otherwise look to the Responsible or Accountable party for direction. |
| Advisor | People who are consulted on one or more aspects, but they have no decision-making authority. |
Every time you kick off a product feature, make a new hire, invest in a marketing tactic, or need to make a host of other important decisions, write out an ARPA. Ensure everyone involved in the initiative is clear about who makes what decisions.
This is also a helpful tool to remind executives of their role. If an executive is an Advisor, they can’t make any decisions, no matter what the org chart looks like.
Consensus is lovely, but it’s often the enemy of progress. If decisions start getting made by committee, or require several sign-offs to happen, it starts to impact velocity. An ARPA is not only a subtle reminder that consensus is not necessary, but hopefully it encourages more discussion and debate amongst the group.
Stage 3: Decision Tree
We didn’t introduce this stage until the 130-150 employee range, and I suspect it would work well up to several hundred employees. The Decision Tree isn’t a big logic tree — it’s a metaphor. If you imagine the company as a tree, it has four components:
- Roots: Everything is built on top of the roots. It’s the foundation, representing the mission, vision, and values of the company.
- Trunk: It knows about every little branch and distributes resources to help the tree survive, representing the company strategy.
- Branches: Each branch represents an initiative funded by the company and the teams who contribute to them.
- Leafs: Each leaf represents a person who contributes to the execution of an initiative.
Each part of the tree is a decision-making layer, which should indicate who the decision-maker should be. An executive shouldn’t be making leaf decisions in most cases, for example. People make all sorts of assumptions about what type of decision something is without expressly naming it, which causes problems.
For example, let’s say a customer reports a bug in your product. Is fixing it a trunk, branch, or leaf decision? If you asked five people, chances are you’d hear all three answers. And there are no wrong answers, by the way. The Decision Tree is all about surfacing the conversation so everyone can align on the type of decision it is and why.
Once you identify what type of decision it is, filling out the ARPA becomes straightforward. It’s just one additional tool that helps people on the team stay in sync.
I’m sure there’s a stage four, but we always have to be careful about adding layers of process and/or beaurocracy — they all have a tax on the company’s velocity.
Conclusion
These tools are powerful because they reinforce a culture of accountability. They also keep leaders in check — distributing authority across every level of the org chart. I can think of many times that, as CEO, these tools forced me not to overstep my authority and to offer teammates support instead.