“Design authority: governance or bottleneck? Are we getting it wrong?

I recently reviewed a process for escalation to Design Authority, and it raised a big question for me: are we designing governance to enable success, or to slow it down?

The process involves multiple layers—local teams, deployment teams, template teams, business leaders, and even executive committees—before a solution can be approved as “fit to template.” While this structure ensures compliance and global consistency, it often creates delays, frustration, and a perception that IT is rigid and slow.

Here’s my personal experience:

• Position papers, steering committees, and gap analysis take weeks, sometimes months.
• Business teams expect agility, but the process feels like a marathon.
• As project managers, we spend more time managing escalation politics than delivering value.

So, let’s make this controversial:

• Is Design Authority truly adding value, or is it just a safety net for decision-makers?
• Should Design Authority be centralized, or distributed closer to the business for faster decisions?
• How do we balance governance with agility without sacrificing compliance?
• Would you ever bypass escalation for speed? If yes, under what conditions?
• What does a “good” Design Authority look like in your experience—lean and adaptive, or strict and layered?

I believe the real challenge is how to design and handle a Design Authority that protects standards but doesn’t kill innovation. What’s your take? How would you redesign this process to make it work for both IT and the business?