You'd have decided better? Prove it.

Decision trade-offs, made visible: a simple framework for decisions people don't resent

Most decisions in large organizations get made without a comprehensive and transparent, holistic view of the trade-offs involved, and that's the root cause of a lot of friction among people and teams. The fix is simple: a structured decision document (template-based to be used consistently), open for comments from anyone affected for a reasonable period of time, so the trade-offs and reasoning behind a decision stay visible and accessible for all involved parties going forward (and backwards for new joiners).

The bias to see the downside in others' choices

Have you joined a project or a team and wondered why things are the way they are? Who made this decision, and why? Thinking it could have been done better? That may well be true, but more often than not you're biased to notice what doesn't work (what works is taken for granted). This creates noticeable resistance and friction in daily work and communication among team members and departments in organizations of all sizes, especially those impacted by the downsides of a decision. And more often than not, those decisions were never documented or accessible in a format that could have alleviated the friction in the first place, or justified it retrospectively.

The root cause is the absence of a transparent, holistic overview of decisions and their tradeoffs and reasoning. Decision makers picked one option out of many, and each option had its own downside. It's always a game of trade-offs. Making those trade-offs visible relieves the issue, simply by making them accessible to future stakeholders and impacted parties.

(open full size in a new tab)

Why this happens everywhere

I've experienced this first hand, and after talking to many professionals across departments, agencies and companies over the years, I've realized how common this challenge is. That's why I believe it's worth investing more time bringing structure to decision making at the operational level of knowledge workers (more structured methodologies tend to already exist at higher executive levels). But it is an increasing reality that it is exactly at the operational level where most decisions are made, many of them contributing to mission-critical processes and long-term company success and projects. This matters even more in modern working environments, where there's less hierarchy and more autonomous decision making within teams.

Additionally, the complexity of decisions which are being made in large organizations run by multi-disciplinary teams is increasing, and goes often without integrating useful perspectives from relevant stakeholders, and not having those decisions accessible during the making process is a huge loss of opportunity to improve their quality and the positive impact they could have on business. It's probably not for lack of trying or interest, it's because putting a process together feels complex. In reality, it can be handled with a few simple tools.

Let's look at the common problems with how decisions get made in organizations, and how each can be fixed or drastically mitigated by simple tools. By the end, we'll have put those tools together into a simple framework for managing decisions across teams.

Three common problems, and how to fix them

1. Stakeholder involvement: who to involve?

Problem: it's tempting to keep the decision-makers' circle as small as possible, to avoid back-and-forth communication and close things efficiently. But a small, concentrated group often can't account for every aspect that matters.

Solution: open the decision for comments from all relevant stakeholders (request for comments - RFC). With the explicit intention that not everyone is a decision maker, it just means all relevant parties can share their perspective, which gives the actual decision makers (who can stay a small, concentrated group) visibility into the decision's potential implications.

(open full size in a new tab)

2. Decisions aren't accepted, whether through explicit protest or quiet resentment

Problem: at some point after a decision is made, someone protests, but it's too late to easily change course. Reverting the decision creates communication issues and raises trust issues in the decision makers. So more often, the protester swallows it and moves on, but carries resentment toward the project and its decision makers, resentment that tends to resurface, unintentionally, in future collaboration.

Solution: same as #1, involve people before the decision is made, not after. This makes everyone involved feel heard, and allows raising critical comments that could be addressed before a decision is made.

3. Decisions aren't accessible and tradeoffs are hidden

Problem: team members can't see the trade-offs, so they don't understand the complexity behind a decision, or why the chosen option was the best fit given the circumstances at the time.

Solution: make the decisions accessible in such a way that all options list their tradeoffs (pros and cons) in a simple way for comparison, allowing everyone to see the various options, the one picked and the consequences of that.

Sometimes the request for comments phase ends up with a unanimous agreement on a decision, in such cases, the decision can simply be made / closed asynchronously (without needing a separate meeting to make it), however, in some cases, the process could end up in strong conflict of opinion, even among the decision makers, in such cases, it's recommended to have an interactive session where participants can come to a conclusion (if necessary involving a higher authority for the decision).

A proposed framework for decision making management

The overall solution framework would look something like this:

(open full size in a new tab)

1. Decisions should be made accessible early enough for all relevant stakeholders to have a chance to comment within a reasonable period of time. This could be done via Confluence tools, GitHub, or document sharing software ..etc.
2. There needs to be a collaborative way to provide input (comments) on a decision, ideally the document sharing tool you use offers such a possibility, otherwise comments need to be collected in some way that is visible to everyone (and maybe votable).
3. Decision participants (and decision makers) must be clearly known and engaged, with a proposal available from the moment the decision document is published for comments
4. Decisions need a consistent structure of fields that fits the organization: participants, options, pros and cons for each, the template can be defined in a flexible way depending on your needs, however for inspiration, the Arc42 framework offers good templates (especially for software architecture decisions).
5. Decisions must be closed on time and stay accessible for future reference
6. Invest time in a meeting only in case of conflict during the request for comments phase, otherwise decisions can be closed asynchronously.
7. Communication about decisions, their updates and closure could happen in any communication tool your team uses incl. emails, Slack, MS Teams ..etc.

Conclusion

So to summarize, decision making at the operational level breaks down for three reasons: too few stakeholders involved, decisions that aren't truly accepted, and decisions that aren't accessible later. A structured, open-for-comments decision document fixes all three: it makes trade-offs visible, gives affected people a voice before the decision is final, and leaves a record that holds up over time. Additionally, having decisions available in such an open and standardized format provides a great deal of advantage for a company to onboard new members quickly with higher quality content. And those decision documents which are rich in valuable knowledge can be integrated into various tools for analytics and knowledge sharing in other processes.