Every governance process exists because someone was trying to solve a legitimate problem.

Several years ago, I helped introduce a governance process for enterprise architecture inside a business unit that borrowed an idea from the construction industry. Projects received a “Permit to Build” before development began and a “Permit to Operate” before moving into production.

The review wasn’t intended to determine if every implementation detail matched the original design. It existed to understand where the architecture had evolved, document the decisions that had been made, and ensure that the intent of the architecture remained.

The process worked because it balanced guidance with autonomy. Project teams understood the architectural intent, had room to make decisions as new information emerged, and remained accountable for explaining where they departed from the original design. Governance wasn’t a gate that prevented progress. It was a mechanism for preserving clarity while allowing teams to move.

Leadership saw the success of the process within the business unit and wanted the model adopted across the organization. That should have been a success story.

Instead, the larger governance teams wanted more assuarances in the process. Security added a mandatory compliance review. Cloud engineering added a cost review. Quality teams wanted evidence that the required activities had been completed. Each addition was reasonable. Each addressed a legitimate concern. None of them, viewed individually, threatened the effectiveness of the process.

Collectively, they changed what the process was optimized for. It no longer existed to preserve architectural intent; it existed to satisfy every governance function that touched the project.

The original process had made decision ownership clear. The expanded process gradually obscured the ownership. Reviews accumulated until it became difficult to determine who owned the next decision or why work was waiting. A later reorganization left one approval step without a clear owner, and projects simply stopped at that point. Within a few months, work across the organization had slowed dramatically. Not because teams lost capacity; because they were waiting for decisions that no one realized they owned.

No one intended that outcome. It emerged from a series of reasonable decisions made over time.

I’ve seen similar patterns in other organizations. During a merger, I joined a company where developers couldn’t investigate a production issue without first requesting temporary credentials through another system. The intent was understandable: protect production data and satisfy regulatory requirements. The effect was that governance became the prerequisite for helping a customer instead of the mechanism that ensured the work was performed responsibly.

Governance had quietly shifted from enabling good decisions to controlling who could make them. That distinction matters because governance is the primary way an organization expresses trust.

Trust becomes visible through organizational design. It is reflected in who has decision rights, how clearly those rights are understood, and how much authority people have to act within established boundaries. Organizations rarely lose trust because people suddenly become untrustworthy. More often, they lose trust because the operating model gradually begins assuming that people cannot be trusted.

That assumption does not happen overnight. It accumulates through additional approvals, mandatory reviews, expanded oversight, and increasingly narrow decision boundaries. Each change is reasonable when viewed on its own. Together they introduce friction into the decisions that keep the organization moving forward. People spend more time navigating governance than exercising judgment. Decisions wait for the next approval instead of moving to the next action. Eventually, the process begins serving itself rather than the intent that justified it into existence.

I’ve also seen the opposite.

While serving as the convention chair for GameCon Memphis, we had dozens of volunteers responsible for different aspects of the event. No one person could make all the decisions, nor should they. Instead each functional area had a designated leader, a clearly defined objective, and understood decision boundaries. Volunteers were expected to act within those boundaries without waiting for permission. Escalation existed when it was needed, but it was an exception rather than a default. The result wasn’t less governance. It was governance that created clarity, accelerated decisions, and allowed people to focus on delivering a successful event rather than navigating approvals.

That experience reinforced something I have repeatedly observed. Good governance doesn’t eliminate trust; it makes trust operational. It makes clear who decides, who contributes, and who is accountable. It removes unnecessary friction while preserving the controls that genuinely reduce risk. Poor governance attempts to eliminate uncertainty by replacing judgment with permission.

The next time someone proposes another approval, pause before adding it.

Will this help people make better decisions, or will it simply create another place for decisions to wait?