Manifold’s Decision Making Process
One of the ways that we work to build velocity and agility at Manifold is to make it possible for people to make autonomous decisions — without having to convince a committee — while still aligning organizationally. The balance we strike is to require every decision maker to get advice, and then empower them to make their own decision.
How much advice, from whom? Consider this chart.
If a decision will be cheap to reverse and have a low impact on its intended audience, just get some advice from a peer, as shown in the bottom left quadrant.
If it will be expensive to reverse, or have a high audience impact, ask two or three stakeholders for advice, as shown in the top left and bottom right quadrants. In engineering, good stakeholder candidates to consider are a known subject matter expert, your squad’s tech lead or product engineer, or a pertinent source in Marketing or Product.
Finally, if it’s both expensive to reverse and highly impactful, gather some data with rigor and present your proposal to some key stakeholders, as shown in the top right. Your proposal might be in the form of an RFC, a slide deck, or some analytics and a voiceover. Your stakeholders might include the previous group plus some more senior company leaders.
As shown in several quadrants, not everyone has to agree. A key point is that the decision maker is the one with a choice. Everyone else gives advice. If it turns into a committee instead, we’ve lost agility and velocity. And if someone else takes over the decision, not the original decision maker, then we’ve lost trust and autonomy, and thereby agility and velocity.
To really emphasize that last point, if you’re in a position of authority (and at Manifold, many of us are, in different contexts) and you’re giving advice to someone who owns a decision, be very careful. Particularly if you disagree with the decision maker, work hard to let go. If at all possible, find a way to discuss how to mitigate risk or assist on a path forward. Don’t block action (hindering velocity) or transfer decision ownership and authority away from the other person (hurting trust, autonomy and velocity). If you believe that you must transfer ownership, this is a weighty decision, and can represent a deep organizational error. In that situation, you have a responsibility to give clear, constructive feedback, and to assist the person to grow.
If flowcharts speak to you more, here’s another view of the same process. The three horizontally aligned rectangles towards the bottom are equivalent to the quadrants in the graph above.
The advice process leads to three corollary points.
First, if necessary, disagree and commit. Once a decision has been made by the responsible party, support it. Whether you agree or not, and whether you were asked for an opinion or not, don’t undermine it; try to make it a success. If you think you should have been asked for an opinion, make sure to give that feedback, to improve future iterations of the process.
Second, once you have made your decision, strongly consider documenting it, especially if you gathered data to support your position. For engineering decisions, that might look something like an Architecture Decision Record, for instance.
Finally, failure is valuable. We are challenging each other to grow, and so therefore we will delegate responsibility to people who haven’t had it before. With that novelty will come mistakes. Allowing the possibility of mistakes enables autonomy and agility. Work to fail fast, and not too hard, when it happens; and learn! Do not blame.
The advice process is about helping people make decisions with velocity. For it to have space to work, people must have meaningful decisions to make! When you are leading a group, as a product engineer, tech lead, agile coach, people manager, guild facilitator, or otherwise, you have to set your expectations in a way that allow people to make decisions. In fact, setting expectations is a variation of the decision making process itself, with four additional constraints.
Define expectations broadly. Communicate a few key desired outcomes while leaving significant autonomy and decision making.
During the advice process, include the colleagues whom you are leading by this decision as stakeholders.
Track or measure the expectations that you set. If you can’t, or won’t, you shouldn’t bother to set them. They’re just advice.
Share your expectations clearly, making sure that everyone understands your rationales.
Leaders have a responsibility to model the advice process, if we want it to succeed. Setting expectations is a key way to do so.
Again, here’s a flowchart, if that visualization helps.
Our decision making framework is really a simple idea that you probably have followed many times. We’re simply documenting and embracing it. In closing, here are a few concrete examples of how it has worked for us.
An engineer needed to implement a new API for the front-end. It would only be used internally, not by customers, so it was easy to reverse or change; and it would only impact other front- and back-end engineers. The engineer made an API design, got some input from a couple of peers, implemented it, got a review, and landed it.
Our Chief of Staff wanted to choose a wiki for internal usage. It was easy to reverse (he made sure every tool could import and export Markdown) but arguably impactful to the employees, who would read and edit it semi-regularly for employee handbook content. He asked for some feedback from the stakeholders — all of the employees, in this case. It was reasonably positive, with some dissent. He chose to proceed. The folks who had dissented committed to the decision without rancor.
An engineer volunteered to help us improve our front-end testing approaches in a fast, expedient, and effective way. The testing didn’t directly affect our customers, but it would be somewhat expensive to reverse once we settled on an approach. She did some research, proposed an approach in a pull request that had documentation and examples, and got comments from the front-end engineers and a tech lead. A key company leader expressed some concerns that the process might be too heavyweight. However, the engineer felt that those concerns would not end up materializing — our velocity would be as good or better — and proceeded. The company leader supported the decision despite disagreeing (and was ultimately happy with the result).
An engineer needed to design the functionality and architecture of a key new feature. It was going to significantly impact how our customers paid for our product. Moreover, reversing the decision would be difficult because integrators would rely on our functionality and API. The engineer assembled a detailed document and got several rounds of feedback from the product manager, the company tech lead, the partnership lead, the head of engineering, other engineers on his squad, and representative integrators. Ultimately, after a few revisions, he decided he had a reasonable solution — not perfect, but balanced — and proceeded to implementation.
The chart at the beginning and the core ideas behind it are adapted from similar thoughts deep in an article about Stripe’s COO. To read more about advice processes like ours, you might enjoy reading Reinventing Organizations.