Having founded a startup before and being now a manager of a small engineering team in another fast-growing startup, I’ve been leveraging the opportunity to experiment with a decision-making framework designed to be scalable, in the hope that the learnings we get will help our engineering organization scale on those learnings in the long run.
What I mean by “scalable”: ensuring things keep working well (better?) after growth that’s already been achieved, and also precipitates future growth not yet achieved.
Obviously, my personal values about scale took a big role in designing this:
• From my time at Apple, I came out a strong believer that decision-making only scales with tight ownership at the leaves of the org chart, and that this has to be built as part of the culture. In short: an ounce of micro-management today is a megaton of organizational friction at a later scale, and no manager should be a bottleneck. (See more about Apple’s DRI approach.)
• I believe the innovation in tech companies only happens when engineers have sufficient ownership, but with the right checks and balances (more about it here).
• Also from my time at Apple, but also from other places that were negative examples of it, I believe in lean organizations, and that resorting to processes to solve problems as anything else than a last resort has major downsides down the line (more here).
First, naive team decision models
Consensus model: everyone is expected to agree, or at least have some degree of agreement over a decision, before it’s enacted. Obviously, the main downside is that while this can work very well for small groups who tend to agree, it obviously leads to deadlocks and frustrations even at a small scale, even within a team.
Single-owner “visionary” model: a given individual on the team (for instance hierarchically empowered, such as the manager or a lead) owns all decisions. Since this model is found a lot in the wild, we’ll compare to it extensively.
Our “messy opinions, neat ownership” model
Neat ownership = neat decision
• Each decision is owned by someone. • Who owns it is explicit and clear to everyone. (In our case, we go as far as creating a “spike” Jira ticket and assign it the owner, even if the decision is made quickly and the ticket doesn’t live long.) • It doesn’t matter who owns the decision. • As much as possible, decision are seldom owned by managers (exceptions ok, as long as they’re exceptional). • Everybody owns something. Anyone can take up a spike, and everyone should be motivated to do so, no matter what seniority level. • If the decision has overlapping ownership (for instance, an infrastructure change is needed that the infrastructure team would have to own and maintain long-term), all owning teams agree that the part they each will own moving forward is satisfactory. • The most counter-intuitive part: to the rest of the team, it does not matter if the decision is wrong.
Messy opinions
• During the spike, everyone is entitled and encouraged to raise concerns and considerations, which may be opposite across people, that is fine. • Even if they don’t own the spike, people are expected to come up with potential solution ideas (group ideation, always). • As is always expected of everyone, concerns and considerations are meant to be constructive. Opinions are messy because people will disagree, but each separate take needs to be well-argued and clear, including benefits and trade offs.
Neat ownership = neat listening / accountability
The hardest roles of the owner beyond deciding is to listen, and explain.
Listening to all takes completely is crucial, because the owner should ensure that their information is complete in order to make the best decision they can (this part is often surprisingly quick and informal).
And then, importantly, when the owner decides to disregard some concerns in a decision (which is totally fine), they are never allowed to dismiss those concerns as unimportant, but must explain what other concerns took priority in the decision, or to what tentative value the decision to disregard them was made. This level of communication is important to ensure team alignment, so people can not only commit to the decision regardless of agreeing, but also so they can understand and later apply the rationale behind it. Sometimes the explanation is “both choices seem equal to me, so I just picked one”, which is very acceptable.
(For my team’s case, when a first tentative decision is reached, we move that “spike” ticket to our QA status for everyone on the team to have a few days to raise concerns, and for the owner to react by either including those concerns in the decision, or explaining their dismissal. Once all of that’s done, we close the ticket. Conversations requiring the whole team around the lifecycle of the spike are extremely cheap and can easily occur at standup. “Everybody read the decision? All concerns were raised? All were addressed? Ok, decision enacted, closing.”)
Worth noting: I’ve found that it’s better when the owner doesn’t initially feel strongly about the issue in order for all of the concerns to be equally considered, and also to get team commitment more easily. Certainly their objectivity may increase the quality of the decision, but I’ve found that it also fosters trust from the rest of the team on that decision.
It doesn’t matter who owns the decision, and it doesn’t matter if the decision is wrong.
Why it works well for engineering work
First, the variance of software work in different careers is so great, that it’s impossible for a single individual to be most right all the time for all pieces of new work. This is one reason that it doesn’t matter if you believe that an initial decision is wrong: no matter at what level of experience you are, if the owner still maintains their decision after listening to your concerns, the decision is likely less wrong than you think, whoever you are. Overall decisions are therefore less tied to a given person’s backstory, unlike for the single-owner model, which is optimized around one single person being most right all the time.
Another reason that it matters less if an initial decision is later found to have been wrong, is that software engineering is iterative in nature. As long as the business value is clear enough from the start, and that people make sure to constantly reassess where a project is going in order to course-correct, the cost of inaction is often greater than the cost of a wrong implementation, if only because: • it’s often easy to iterate correctly on top of a wrong engineering implementation, in order to fix it after the fact; • and there is often a lot for the organization to learn and reuse quickly from a wrong implementation (the team needs the be very focused then at what the learnings were from that failure).
There is also a serendipitous aspect in doing things wrong for a limited amount of time, and then adjusting. The owner, after correcting their initial mistake, will then need to come up with a solution that keeps solving their initial concerns but also the new ones, and therefore satisfies even more world views, which is a typical way innovation stories start. Obviously, with software mistakes tending to be easier to fix up later than most disciplines, this only works if the mistake lasted a short enough amount of time that its cost was worth it; but the model ensures the owner is aware of all concerns from the start, so we’ve found that they will naturally keep proactive eyes on the things they’ve been told could go wrong.
Another aspect of software is that it can be made of hyper-focused work, which tends to encourage people to work in silos, even more so in the single-owner model if the individual builds and owns all decisions simultaneously. Silos are problematic because they lead to poor alignment, poor maintenance ability, and unequal personal growth across the team. Our model discourages silos, because it requires the individual to consider a variety of other angles, but also to invite the rest of team to hold them accountable in their decisions.
Also, I strongly believe the main innovation value brought by junior engineers is their lack of expert bias. Making juniors own, but also making sure that their concerns are always responded to, allows to be sure that their are empowered to bring that value. It’s particularly relevant considering juniors may not always feel confident about the legitimacy of their opinions, and therefore may not be proactive in getting listened to without being explicitly empowered with it.
Why it is likely to scale better
It’s probably obvious that the more a leader builds an organization that takes care of itself, the easier it is for them to transition from leading 5 people to 500 people as the company grows. The key here is to make sure that management costs remain low over time, and things happen as much at the leaf of the org chart as possible.
This model motivates each team member to be accountable to each other equally (not just their manager / single-owner), which makes alignment more organic with very low cost, even at scale. Successful contributors will organically acquire further influence on things thanks to the trust they got from the team, with also barely any management costs. Contributors who are delivering unsatisfactorily for team goals will receive faster and more organic feedback from the team, which is more compelling and helpful to their growth than one person’s feedback such as the manager, again with low management cost.
Also, one thing that notoriously doesn’t scale well is emotions / conflict management. More headcount typically means more natural conflicts around decisions; which is not a bad thing per se, as it’s likely the reflect of people caring for your product and organization. I’ve found that this model actually allows for less emotional conflicts, as the guarantee for a dialogue to happen throughout disagreements enforces that people feel respected even when their concerns are chosen not to get addressed; and because it’s easier to commit to a decision one doesn’t agree with if they know that they’ll be trusted with owning the next one.
Also, worth nothing that the more painful the conflict becomes, the more likely it is that the decision is not obvious, and therefore the more it makes sense to want to make a fast decision with a clear owner before the conversation runs in circles and generate yet more frustration, as would happen even more with a consensus model. One person is empowered to stop the debate and make a decision as soon as they feel it’s gone on enough.
As you may have noticed, this model is a lot about alignment too, because weak alignment is a debt that grows with scale, as people have more communication breakdowns and opportunities to misunderstand each other. It ensures that people listen for the right reasons (to meet the team accountability of making the best decision they can), and explain for the right reasons (for alignment, to give the team the keys of the right way to commit).
There is also a growth alignment opportunity here, between the company and the individuals. If people are empowered to own, since the company always has challenges to solve and ways to grow, the hope is that they will find something to align their growth to, and therefore will grow the company faster with themselves, which we hope will be noticeable at scale. I also expect it to have significant employee retention outcomes as people find ways to grow more easily, as long as they’re in line with the genuine company goals. Obviously, with a single-owner model, nobody grows but that individual, which we believe limits the company’s growth as well.
Another personal growth positive comes with the expectation of people to explain their concerns and their decisions well. If they joined struggling with communication, this is a continuous communication training at scale, with healthy incentives to improve.
Finally, you’ll notice that this model is very cheap to enable, it costs only as much as the effort to make a problem and its ownership clear, and make sure the conversations happen (which they typically do by themselves). It makes it extremely easy, if unexpected disagreements occur that were not yet identified, to name a team member as the owner of the decision right on the spot.
So then, what’s the role of being senior / manager?
Since a senior engineer won’t particularly own more decisions than more junior engineers, what are the perks of being one then? I’ve found that the only difference is that people will organically lend more attention to an team mate’s concerns as they have a more senior title. While a bit artificial, this is certainly not a bad thing, even more so if the less-senior owner feels empowered to disregard anyway. Not having more decision power could be uncomfortable to some senior engineers, but the positive here is that if a senior engineer with more experience expresses accurate warnings that get disregarded and regretted, they will gain a lot of genuine legitimacy, respect, and increased future influence on the team for it. Of course, this is equally true of less senior members who tend to also raise accurate concerns, and will also grow their influence, which makes the model quite fair in that way.
As a manager, you’re not getting a much better role within the decision process than any other team mate (have you not heard that moving to management is a lot about letting go?), but you are the only person whose responsibility it is to ensure that the decision-making process is being respected, for the right reasons. Obviously, since this is about constant individual readjustments, this bit doesn’t scale, but the hope is that people get used to it enough that the cost is gradually lower and lower on a given team, and therefore lower for the organization.
Namely, you are the one tasked with: • On a given decision, stabilizing the list of questions that people express needing answers for, moderating the in-flight changes to that list if needed in long spikes as things get discovered. • Naming and communicating owners for those decisions, in a smart way (personally, I’m basing it a lot on people’s interest as much as possible, sometimes overruled by the need to spread ownership fairly). • Pulling in the teams whose ownership overlaps so they can approve their bit; pulling in relevant other people beyond the other team members if their concerns and input are likely to be insightful to the owner. It makes sense for the manager to own that bit, since they own communication and cross-team alignment, although the owner can feel free to pull people in too. • Ensuring that all concerns are heard and appropriately responded to, whether they’re used or disregarded. • Ensuring that the decision is tracked in writing, to ensure group mutual understanding, but also to be able to get back to that deliverable (which can very well be just a Jira comment) later if people were to want to reopen the debate later. The point of a neat decision being made is to terminate debates in favor of forward progress. • After the decision is made and well communicated, ensuring ongoing commitment from all parties to respect the decision, regardless of agreeing.
Note than none of the above responsibilities have any bearing on the decision itself.
Note also that none of the above requires advanced technical skills beyond understanding and communicating technical concerns and decisions as needed, if the owner needs help with that. There’s a point of scale (that we haven’t yet hit) at which an organization may want to include less technical engineering managers, and I believe it is likely the model could help their success tremendously.
Worth noting also that this ownership model applies well to engineering decisions and things that pertain to what the team is tasked to deliver, but not necessary to management topics, that often don’t have the same iterative and scalable nature. Also, a manager’s main responsibilities are to manage the communications with and from the rest of the org so contributors don’t have to, but also to own people’s growth and careers, so it’s only fair that managers would own those topics to ensure they can deliver as is expected of them.
Caveats
Compared to the single-owner model, while this model is cheap in process, it has some overhead in team communication time, notably when disregarding concerns. We accept this caveat because we believe the added alignment (which can’t happen without communication), individual growth, company growth, and potential for innovation comfortably make up for that overhead.
Another caveat is that this approach is likely to be unsettling for newcomers on the team. If they come from a consensus model, people may find themselves missing the art of endless debates, because they can be pleasant to individuals no matter how non-constructive for the organization and others. If they come from a single-owner model, people may not be used to be made accountable by peers if they were the owner, or to be trusted with risky decisions if they were not. Ultimately though, a scaling organization thrives on individuals who won’t appreciate debates past the point where they’re constructive, who enjoy being made accountable, and who are up to the task of being trusted and taking risks; so this is likely all for the best.
It can also be unsettling for external stakeholders looking at it from the outside, who may take it for a form of democracy when one could consider it the opposite of it (the owner of a given decision is a single person with a lot of power in this model). It’s particularly difficult for people who aren’t following the team closely enough to have witnessed the positive outcomes, and/or if they’re not well-versed in the software building cycle, and the challenges and opportunities that come with it.
But the biggest caveat is that from time to time, while I’ve found it rare, this model just doesn’t work for a given decision. It is based on the trust for contributors to understand well the company goals, but sometimes it won’t be possible, for instance because the company goals are contradictory or unclear. Or sometimes, a technical leader identifies a clear mistake that it would be too costly to undo later. In which case, it is also part of a manager’s role to enforce alignment and cost mitigation, so they may have to overrule the contributor’s decision.
Obviously, this needs to be extremely rare, unavoidable, and the motivations to use it should be absolutely certain. Every time this is used, trust erodes, people lose their empowerment and ownership, and a ton of long-term value gets flushed away. Please only use if absolutely necessary.
What now?
Our adventure with this model is just getting started, and as it’s experimental, we would love to hear some thoughts about things to keep our eyes on, and ideas to improve it.