Software engineering decision-making is a stressful and time-consuming process. When the stakes are high, you will be met with opinionated programmers, insurmountable organizational constraints, and unfortunate baggage from old projects. Consensus is difficult.
In a previous post, “Staff Software Engineer Responsibilities“, I mention that the act of “Transforming Competing Opinions Into Decisions” as one of a Staff Engineer’s primary responsibilities. I note that prolonged technical debates are a risk for organizations and that Staff Engineers must “push through friction” in order to arrive at decisions. However, once you feel the friction, it’s never clear how you’re supposed to push through it.
This article presents a generalizable 6-step outline to help engineers drive consensus. This is a set of heuristics, not an algorithm.
Software Engineering Decision-Making
Preliminaries
- Decision-making is unique to every organization. It’s part of the culture.
- Decision-making and consensus-gathering take significant time and energy. Reserve this process for business-impacting problems.
- As long as the desired outcome is achieved, less is more. Ideally, you don’t need any of this.
- Any decision-making process should optimize for good-will amongst your peers.
- Decision-making relies on empathy and communication more so than technical skills and previous experiences.
- These ideas may be relevant for other situations where you hear the words “vision”, “alignment”, or “strategy.”
Step 1 — Assign A Directly Responsible Individual
Ensure a directly responsible individual is assigned to the decision outcome.
Step 2 — Research And Form Your Opinion
To successfully facilitate the journey towards consensus, you must achieve two prerequisites: understand the current state of affairs and form an opinion.
In certain cases, you’re an existing stakeholder and have already established your opinion. In other cases, you’re coordinating a decision outcome with minimal context. The latter often occurs when existing stakeholders are entrenched in their biases and objectivity is needed.
The outcome of this step is to have complete organizational and technical context. You must track stakeholders and listen to their perspectives. You must sift through prior art and read documentation related to the topic. This research will naturally lead you to an opinion. For the veterans, remember that your opinion should form from your newly gathered context more so than your past experiences.
Finally, be clear about who is a key stakeholder and who is an interested observer. If you were to survey the engineering organization, a hundred engineers may want to take part in the process. Unfortunately, it’s not feasible to gain consensus with one hundred people. Be intentional. Who is actually affected by the decision and who just wants some extra time on their soapbox?
Step 3 — Key Stakeholder Empathy
After the research legwork is done, you will have sufficient context to be able to engage with key stakeholders. You may have identified one or two acute areas of conflict. Software developers are opinionated; just one unresolved issue is enough to stall a company.
Meet with the individuals who hold the strongest opinions. Understand their philosophies—do they prefer generalized solutions or specific solutions? Talk to them about their previous experiences—are they avoiding the pitfalls of a failed project or a failed company?
Do not try to achieve consensus or reconcile conflict yet. During this step, your goal is to develop empathy; this is a prerequisite before you moderate broader meetings.
Step 4 — Gather Stakeholders And Moderate
With key stakeholders identified and empathy in hand, it is now time to gather everyone together.
The meetings should be casual. No productive conversations occur in formal councils.
The meeting should be documented. Throughout these meetings, you will arrive at mini-decisions and mini moments of consensus. Document these wins so the group does not repeat itself; talking in circles is tiring and wasteful.
Aggressively scope the meeting. Refrain from adding too many attendees or discussion topics. Answering one or two open questions per meeting is a great outcome.
Finally, the meetings should be moderated. Even casual meetings require structure. Ensure people are staying on topic, high-level goals are reiterated, and the majority of minutes are spent discussing. Constantly remind people about the outcome and its significance.
Step 5 — Timeboxed Arrival At A Decision
Due to the heavy amount of communication required, assume this process is at risk of taking too long. Once discussions begin, the arrival at a decision should be timeboxed. You do not want to spend months or even quarters discussing this topic.
Culture matters. Compromises must be made and stubbornness must be minimized. Explicitly tell everyone upfront that this decision-making process will be timeboxed. If consensus is not gathered in a reasonable timeframe, the team must agree to disagree and commit on moving forward. If a decision is still impossible, you may need to resort to heavier-handed alternatives (see later).
Step 6 — Document, Ratify, and Communicate
Congratulations! A decision has been made. There’s only a few logistical follow-ups left that will put a bow on the entire process.
The final decision must be documented. Other engineers will be interested to hear about the outcome and how the company chose to move forward. The problem must be clear, the solution must be laid out, and the trade-offs must be acknowledged.
Explicit stakeholder signatures go a long way. A ratified document gives the decision outcome weight and the authority to be referenced later.
Don’t be shy—broadcast the results to the company.
Finally, ensure that teams follow through. If an architecture decision was made, is the software actually being built to reflect the architecture? If an organizational process was changed, did it actually happen?
3 Heavier-Handed Alternatives
If consensus-gathering strategies are not effective, you may need to resort to heavier-handed alternatives. One method is to defer the decision to a higher authority. This may be the resident Staff Engineer, a select Principal Engineer, or perhaps even the CTO. This method is decisive, but it is not optimized for goodwill amongst your colleagues.
Another alternative is to align engineers by utilizing non-engineers. If engineers can’t align on a technical decision, it’s likely that they’re rooted in different product and business goals. In practice, I have seen that enlisting the help of a high-ranking product manager to reaffirm company goals may help with engineering alignment.
Another medium-handed approach is to utilize the wedding ceremony rule of, “Speak Now Or Forever Hold Your Peace.” This is a method to keep the process moving when people are lagging; this is not an excuse to skip communication. This is a risky strategy for significant decisions and is also not optimized for goodwill.
Conclusion
Software engineering decision-making can be exhausting and is never a simple sequence of steps. Consensus relies heavily on communication and empathy; it relies less on technical expertise and previous experiences.
Throughout the process, remain firm, but never offensive. Engage the right engineers and hold them accountable to their stake in the decision.
Finally, don’t stress too much. Significant decisions have significant expectations. If you need help, ask for help. If the process isn’t going anywhere and needs to be reframed, make the call and have a reset. The fact that you have taken on this massive responsibility deserves to be applauded!
Best of luck.