Satire
The Initiative That Required Five Teams to Move First
Every team was waiting for a different team. The initiative was technically still active.
The initiative is approved. The roadmap shows Q2. Five teams are listed as dependencies.
The initiative is now in Q4.
What Actually Happens
Team A cannot start until Team B delivers the shared authentication service. Team B is waiting on the data model from Team C. Team C needs a platform decision from Team D before they can finalise anything. Team D is blocked on a security review owned by Team E. Team E submitted their intake request to Team A's security coordinator four months ago.
The programme manager holds a weekly sync. Each team reports their blocker. Each blocker points to another team. The weekly sync produces minutes. The minutes are shared on Confluence. No one reads them.
The initiative is in its second year. It still has a Confluence space. The Confluence space has 47 pages.
“I tried to map the deployment order. It forms a cycle. I've been staring at it for three days.”
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 trace the dependency chain looking for the one team that can move without a prerequisite — and you start there, even if it delivers only a partial slice. Circular dependencies in organisations do not resolve through waiting; they resolve through someone deciding to move a boundary. You document the cycle as a formal blocker, name each link explicitly, and present it to the programme sponsor with a proposed resolution path — not as a status update, but as a decision request. Momentum is the only thing that breaks a cycle. Someone has to go first.
20 articles about enterprise dysfunction. None of it billable. Buy me a coffee.
Buy me a coffee