Satire
The Architecture Review Board That Reviews Architecture
You need to change an environment variable. The ARB meets on the third Thursday.
You need to update a configuration value in the production environment. Not the code. Not the schema. A configuration value. One line.
The change requires an ARB submission.
What Actually Happens
The ARB submission requires a completed RFC template, a risk assessment, a rollback plan, a test evidence document, and sign-off from the Security team. The Security team requires a change request ticket before they will review anything. The change request ticket requires ARB approval to open.
The ARB meets on the third Thursday of the month.
Today is the fourth Thursday. The next meeting is in 27 days. The configuration value is causing a production issue. The production issue is classified as P2. The P2 has been open for six days. It is waiting on the ARB.
“I've seen this before. The ARB was built to prevent mistakes. It now prevents everything else too.”
DivineForge Advisory
Recognise this pattern in your organisation? I help teams cut through the governance, make the right technical calls, and actually ship.
Let's talk architecture →How a Builder Should Respond
You distinguish between the governance process and the governance intent — the intent is risk reduction, and you address that intent directly regardless of whether the process requires it. Document the change, the risk, the rollback, and the test evidence now, even for a one-line config update. Then escalate the P2 to the ARB chair directly with the documented evidence already attached, and request an emergency review. Most governance bodies have an out-of-cycle path — it is just never advertised. Separately, you propose a fast-track lane for low-risk changes. Governance that costs more than the risk it prevents has become the risk.
20 articles about enterprise dysfunction. None of it billable. Buy me a coffee.
Buy me a coffee