Engineered Collaboration: A User Guide to Consent-based Decisions
How to make collective decisions that don’t take all year
I can’t tell you the number of times I’ve heard this particular exasperated plea in a 1-to-1 meeting: “I wish someone would make a decision!”
I find this really interesting, coming as it does from bright engineers who would recoil at the idea of being ruled over by a dictator, benevolent or otherwise.
The fix is not a louder decider, it’s a better culture and a visible process.
Picture this: A team of senior developers was charged with designing a new, mission-critical system. Let’s call it Project Oxbow. There was no lead engineer, no tiebreaker involved. Surely a disaster, inviting the worst sort of design-by-committee outcome imaginable.
Yet in this case, consensus was reached and in a pretty timely manner. What arcane trickery or backhanders did they employ to achieve this impossible feat?
I call it engineered collaboration with consent.
Engineered collaboration means putting structure around decision-making and building a culture that backs the process.
Consent means when there are no unresolved show-stoppers, the team moves forward together. Concerns are heard, and they commit.
Now, I am not saying Oxbow was easy. Quite the opposite. For those team members involved, it demanded huge amounts of emotional energy to navigate the journey. It got harder before getting easier, with two viable designs jostling for position and the clock ticking on this system they really couldn’t afford to get wrong: Behind each design, an invested personality. We’ll explore some of those dynamics below.
But if you get it right, engineered collaboration yields higher quality results, with issues being spotted earlier, and greater engagement later.
Let’s map it out.
Framing
Assign membership. Who’s going to be involved in this engineered collaboration? First things first, throw RACI in the bin.
You just need a core team of 3 engineers. Avoid 2 or 4. Odd numbers reduce deadlocks.
You also need to identify those stakeholders and subject matter experts (SMEs) you’ll be leaning on throughout the process.
And finally, find that champion, the staff engineer who will be a quality gate. They are not a decision-maker, they are not part of the process, but an objective, external perspective.
Articulate the problem. As obvious as it sounds, starting out with a clear objective can help a lot. Write it down. Map it out visually if you like drawing with crayons.
An attempt at clarity avoids early assumptions and mental misalignment. Include gaps in understanding and capture some early risks. Requirements gathering can be parallelised, with different team members consulting different stakeholders/SMEs, then coming together to find overlaps and conflicts.
Transparent timeline. Next, build a visual timeline of your decision-making process. Not the delivery process. You can’t promise to deliver anything until you have decided what to build.
Set clear milestones and make them visible to all interested parties (especially the team themselves!). Milestones might include framing, preparation, exploration, decision, de-risking, just as used in this article. Names are not important. What matters is the process, and the fact it’s transparent.
The time allocated to each milestone (and therefore the whole exercise) is relative to the complexity involved. Consider factors like the permanence of the decision (is it reversible later? If so, then move fast).
In Project Oxbow, we made a mistake. We only added the timeline later when it became clear we needed to focus minds after an initial period of drift. It worked, helping drive us to a conclusion.
Preparation
Arguably the most important phase, and the one where the Engineering Manager has a huge opportunity to affect the outcome of the engineered collaboration.
Did I mention that EMs are really important?
As always, the EM is not the decision-maker, but the one creating the conditions for success. The internet is packed with help on creating psychological safety but I have a few ideas to help build the right collaborative culture:
Expectation management: Coach the team on the engineered collaboration process, to expect an emotional rollercoaster, of the need to remain respectful, to trust that others are always acting with good intent. Expect an energy dip in the middle. That’s normal.
The consent rule: Convey the importance of consent over unanimity. That it might be necessary to disagree and commit. Propose a fast 1 to 5 scale for rapid decision making. 1s block with a concrete risk. 2s and 3s commit anyway.
Explicit empowerment: They are a Team of Leaders, where each member, no matter how junior, can take the initiative and lead when the need arises. It might be setting the direction of travel or just moving a stalled meeting forward. It’s about explicit empowerment. Everyone is expected to act and not wait for others.
Feedback foundation: Encourage regular feedback between team members, building strong foundational relationships which can weather the storms of conflict ahead.
Finally, the practical considerations before beginning to explore ideas:
Lock down the criteria and constraints. Decision-making is quicker with more limitations, as an open-ended blank canvas can be a creativity killer.
Define your test cases. What does good-enough look like?
Ask the team to commit to this culture and checklist. You’ll be referring to it through the process.
Exploration
Now the hard part. Building a view of the different options available. Form a hypothesis and do the leanest thing possible to test it.
Try things. Don’t make assumptions about the proposals. We all understand the value of being data-driven, but a word of caution. Seeking perfect data in a complicated scenario is inviting analysis-paralysis. Evidence is ‘enough’ once the options separate on our criteria and constraints.
Remember, we’re seeking a consent-based decision. That’s one where enough people agree that it’s worth pursuing. Our manifesto rejects perfection (and incidentally, has a chapter about the importance of black pepper in fish and chip shops).
Sometimes it’s hard to get started. How about leveraging my favourite topic, lateral thinking, a process which can lead to solutions not reachable directly from your starting point, or maybe the classic double-diamond to break an impasse.
Another challenge is ambiguity. How do you make decisions when some of the parameters are unknown? For software engineers’ logical brains in particular, this is anathema. It was a problem for Oxbow too. How did they overcome it?
Work with what you do know.
Get started. Let data emerge through the process and the gaps slowly fill. The most important thing is to build momentum.
The EM’s job during this phase is to inject energy, steward the process, and above all, hold the team accountable to the culture and principles they agreed upfront, whether by direct involvement or quiet nudging from the sidelines. Specifically, look out for these anti-patterns:
Scope creep, where the focus expands to more than the absolute minimum. Remedy: keep referring to the Framing to pare down bloat.
Bikeshedding, an easy mistake for engineers who love details. Remedy: check criteria. Does this detail contribute materially? If not, move on.
Unanimity creep, where the bar drifts from consent to everyone must love it. Remedy: restate the consent rule.
Analysis paralysis, when two or more options are good-enough. Remedy: Stop shopping for data and pick the simpler one. Move on.
Endless homework, where the evidence bar is unbounded. Remedy: revisit test cases for the definition of good-enough.
When evaluating concepts, we defined those test cases during the Preparation phase so the battle is half-won. But what about edge cases and failure modes particular to the solution proposed?
Here, a rapid pre-mortem is your friend. Within 10 minutes, the team could probably imagine most critical issues which might arise.
In Oxbow, the evaluation phase is where the friction was felt. Two senior developers, both highly capable, both deeply invested, each convinced their solution was objectively better. Frustration flared. Meetings got tense. Progress stalled.
The breakthrough came not through more data, but more empathy. Each began to see the complementary strengths in the other’s thinking. That softened the dynamic and opened the door to synthesis.
Empathy to the rescue, as always.
The most likely outcome when evaluating a potential solution is rejection. By restarting the Exploration phase, we introduce a vital feedback loop. Our learnings become inputs into a new cycle.
Even with a promising solution in place, introducing some randomness and looping back can sanity check it. You don’t want to have found a local maximum when a better solution exists.
Decision
You’ve found a solution which meets most of your acceptance criteria. Is it perfect? No. Are people unhappy with aspects of it? Certainly. Is it good enough? Probably!
This is where our culture trumps the process. Consent over unanimity. That doesn’t mean concerns are not acknowledged and recorded… They are useful data points. Progress is our goal, not perfection.
Finally, cross-check with our external quality gate for a non-veto review. Those fresh eyes are an important resource.
De-risking
Now the decision is made, celebrate it. Socialise the outcome and rationale with stakeholders.
Create an Architectural Decision Record (ADR). Do not skip this in the excitement to get started on your newly agreed decision. It is a vital way to respect history. Trust me, you do not want someone attempting to reopen the debate, with partial information and low context.
Of course, the exception to this rule is if extra information becomes available. Remember, we’re agile engineers with strong views lightly-held. If something new comes to light, we’ll revisit. We’re not dogmatic.
Stop Wishing, Start Deciding
For the Oxbow team, the decision was made but the personal journey involved was just as gratifying. Two very different engineers learned to appreciate the other, and and now enjoy working together.
Through engineered collaboration, the team stopped wishing “someone would just decide”. They learned to decide together.
If this piece hit close to home, you might like my Engineering Manager OS, a Notion template built to give managers the structure I wish I’d had when I started.