Governance

The rider app team needs a "swipe to confirm delivery" control, and Thali does not have one. Should they build it themselves? Ask the Thali team and wait? And if they build it, does it become part of Thali for everyone? Without clear answers, teams either give up on the system or quietly work around it.

The rule

Governance decides who can add, change or remove things, and how.

Governance is the agreed process, and the decision rights, behind every change to the system. It covers five moments:

• Request: where teams ask for something new or report a problem, such as one form or one channel.
• Decide: the criteria for accepting a change. Do several teams need it? Does it fit the principles? Is it accessible?
• Build and review: who builds it, and who checks it before it is released.
• Release: how changes are versioned and announced, especially changes that could break existing screens.
• Retire: how an old part is deprecated, with warning and a way to move off it.

Teams organise this in different ways. In a centralised model, a dedicated team builds everything and product teams consume it. In a federated model, people from product teams contribute, and a small core group curates. Many companies mix the two.

Both extremes fail. With no process, anyone adds anything and the system fills with near-duplicates. With too much process, nothing gets in, and teams build around the system instead.

The shortcut

Local first, shared when proven. A new need is built inside the team that has it, using the system's tokens. When a second team needs the same thing, it is proposed, reviewed and promoted into the system.

Drills

Answer fast — trust the rule.

Remember

• Governance decides who can add, change or remove things, and how: request, decide, build, release, retire.
• Shortcut: local first, shared when proven.
• Trap: either extreme. No process fills the system with copies; too much process pushes teams away from it.