Design Authority: Game Maker or Referee
- Raymond Althof

- Sep 1, 2025
- 3 min read
When people hear “governance,” they often picture heavy committees and strict rulebooks. The Design Authority is sometimes put in that same box: seen as a referee whose only role is to blow the whistle when someone breaks the rules.
But that view sells the role short. A good Design Authority is much more than a referee. It is also the game maker: the one who sets the rules of play, distributes the ball, and ensures the game flows smoothly.
“An operating model is only as strong as the way it is guarded and evolved.”
The Game Maker
As game maker the Design Authority:
Provides overview of the entire operating model.
Facilitates collaboration across functions and building blocks.
Explains the guiding principles that keep the model coherent.
Helps leaders and teams make choices that fit together.
Practical examples of the game maker role
Coordinating changes across business and IT so that new systems and processes reinforce each other instead of drifting apart.
Setting up design workshops where HR, IT, and business leaders jointly decide how AI should be embedded into both processes and roles.
Showing how a local optimisation might undermine overall flow and guiding towards an alternative that works for all.
In my own experience, the Design Authority played a crucial role as Game Maker during a large transition. The organisation had never really given importance to the Operating Model. But this change involved a new way of working, adjustments to organisational structures, and the introduction of new roles. The Design Authority ensured that all these changes were consistently captured, and that important decisions were brought to the management team for awareness and approval.
The Referee
Still, there are moments where the Design Authority must step into the role of referee. When changes drift too far from guiding principles, or when local optimisations threaten to break coherence, someone needs to step in and say: “This doesn’t fit, we need to adjust.”

Practical examples of the referee role
Rejecting a proposal to introduce yet another project management tool that duplicates functionality and fragments collaboration.
Stopping a process redesign that would optimise one function but create bottlenecks for value streams elsewhere.
Enforcing compliance with mandatory policies (e.g. data privacy, financial controls) even when teams push for shortcuts.
There is a thin line between giving teams autonomy and guarding overall interests. In the operating model we designed, portfolios played a crucial role in translating strategy into work. While I fully support that such concepts are not about tooling, implementation becomes much easier when all teams in a portfolio use the same backlog management tool. This ensures a clear, traceable correlation between portfolio decisions and the work executed by teams. In order to guard this overall interest the Design Authority had to use its referee role to block the usage of just another backlog management tool that made the portfolio management activities more cumbersome.
These interventions are not about control for the sake of control. They are about protecting the integrity of the operating model so it remains a living system rather than a patchwork of inconsistent parts.
Finding the Balance
The real strength of a Design Authority lies in its ability to balance both roles.
Mostly game maker, enabling, connecting, facilitating.
Occasionally referee, enforcing boundaries when the model is at risk.
For leaders, this means accepting that governance is not bureaucracy. Done well, it is a safeguard and an enabler at the same time.
Final Thought
A Design Authority is not the police of your operating model. It is the guardian that keeps the model coherent, ethical, and alive. Sometimes that means playing referee. But most of the time, it is the game maker enabling the organisation to play together and win together.
“Good governance doesn’t slow you down, it helps you play the game better.”
We always welcome your experiences and feedback.




Comments