How to Build a Decision Governance Framework

A decision governance framework is a short set of rules that says who decides what, how each kind of decision gets made, where the result is written down, and when it is reviewed. It turns decision making from a set of habits that live in a few people's heads into something the whole team can see and follow.

The word "governance" makes it sound heavy. It does not need to be. For most teams the whole framework fits on two pages, and most of what it holds already exists in pieces. The job is to put the pieces together and agree on them.

The four parts

Part	Question it answers	The artifact
Authority	Who may decide each kind of decision?	A decision authority map
Process	How is each kind of decision made?	A few rules by decision type
Record	Where is the result kept?	A decision log, plus records for big calls
Review	When do we look again?	A review date on each decision and a quarterly pass

Authority

Authority is the foundation. Every recurring kind of decision gets one named owner, and a stand-in for when that owner is away. Without this, the other three parts have nothing to stand on. The decision authority map shows how to build one from your team's recent decisions.

Process

Different decisions deserve different processes. A cheap, reversible decision should be made by the person closest to the work, today. A costly or permanent one should go through a written proposal, a review window, and a named decider. Write down two or three tiers and which decisions fall into each. The guide to reversible vs irreversible decisions gives a simple test for sorting them.

Record

Every decision, once made, is written down in one agreed place. Most decisions need a single line in a decision log. The few that matter most get a fuller written record. The rule that makes this work: a decision is not final until it is recorded.

Review

Decisions age. A vendor choice made for this year, a process tried for a quarter, a policy set before the team doubled: each needs a date when someone looks again. Once a quarter, the owner of the log lists decisions past their review date, and the team keeps, changes or retires each one.

How to build one in seven steps

1. List the decisions your team made in the last three months.
2. Group them into eight to twelve kinds, such as "add a dependency," "change a public API," "hire into an open role."
3. Name the owner and a stand-in for each kind.
4. Sort the kinds into process tiers: decide now, decide with input, decide through a written proposal.
5. Pick one place for the record, and one person to own it.
6. Agree the review rhythm: a review date on each big decision, and one quarterly pass.
7. Write all of it on one page, share it, and run it for a month before changing anything.

Roles and rhythm

Three roles keep the framework alive. The framework owner, often an engineering manager, head of operations or chief of staff, keeps the authority map current and runs the quarterly review. Decision owners make the calls in their area and make sure each one is recorded. Everyone else checks the record before reopening a question.

The rhythm is light: a weekly two-minute check that last week's decisions are in the log, and a quarterly half hour to review old ones.

Accountability for decisions

A framework is only as strong as the accountability behind it. Every recorded decision should name the person who made it, not "the team" or "leadership." The point is having someone to ask, not someone to blame. When a decision turns out wrong, the owner explains the reasoning, the team learns from it, and the record shows what changed. On distributed teams, where the owner may be asleep when the question comes up, a named owner plus a written record is what lets the question get answered at all.

How it differs from project management

Project management plans and schedules the work: tasks, owners, dates and status. Decision governance settles the choices the work depends on: which approach, which vendor, which trade-off. Your project tool can tell you a migration is half done. It cannot tell you why the team chose that database, who chose it, or whether it can still be changed. Most teams have a mature project management habit and almost no decision habit, which is why the same choices keep coming back.

Common mistakes

• Starting with a tool. Pick the rules first. A spreadsheet is enough to start.
• Making every decision go through the heavy process. Most decisions should be fast.
• Writing the framework and never reviewing it. Roles change, and the map goes out of date within a quarter.
• Naming groups as owners. "The platform team" cannot be asked a question. A person can.

For how the framework fits with logs, records and audit trails, start with the guide to a system of record for decisions. Regulated teams will also want a decision audit trail.

Where StandIn fits

When a team runs on StandIn, anyone can ask what was decided and who owns the call, and get an answer sourced to the person who did the work. Owners do not have to be online for the record to be useful: their StandIn answers from what they wrote down while they are away. When the answer is not in the record, it never guesses. See how this works for leadership teams.