The Fifth Team Type Team Topologies Never Drew — and Why It's Probably You

Day 8 — The Fifth Team Type Nobody Diagrams

Here's the failure mode that actually kills a Team Topologies rollout, and it's not in the book: you draw the four team types, assign the three interaction modes, hand off the domain — and months later you're still the one who has to say go. Nobody voted for that. Nobody even noticed it happening. That's the fifth team type: the founder or ex-CTO who stepped back on paper but never renegotiated how they interact with the teams, so everyone quietly keeps routing decisions through them anyway.

The hook

Months after I'd handed a domain fully to a team — new lead, clear charter, topology diagram drawn and shared — I was still getting tagged into a Slack thread about a schema change. Not looped in for visibility. Tagged as the person who had to say go. The diagram said that team consumed my old platform team as-a-service: clean interface, no synchronous back-and-forth needed. The actual behavior said collaboration-with-everyone, and I was the everyone. Nobody had done anything wrong. Nobody had even decided this. It was just habit — the same habit that existed when I was CTO writing half that codebase myself.

Name the pattern: founder-in-the-loop

Team Topologies gives you four team types — stream-aligned, platform, enabling, complicated-subsystem — and three interaction modes to connect them: collaboration, x-as-a-service, facilitating. What it doesn't give you is a slot for a person who used to be load-bearing across every team and never got formally reassigned an interaction mode when their role changed. That person doesn't show up as a team on the diagram. They show up as an invisible edge into every team's graph, inherited from history rather than assigned by design. Call it founder-in-the-loop: a fifth, unwritten team-of-one whose default mode with everyone is collaboration, because nobody — including them — ever explicitly set it to anything else.

Why the four types can't catch this

Team Topologies treats the team as the unit of redesign. Redraw the boundaries, assign the modes, and the theory says behavior follows structure. Fine, when the friction is between teams. It falls apart when the friction is one individual sitting inside every team's shadow interaction graph — the pattern of who actually gets consulted, not who's on the org chart. Redraw team boundaries all day; if one person's implicit authority crosses all of them, the new diagram is decoration over the old behavior.

This is the exact bug I study in multi-agent systems, and it's not a metaphor — it's the identical structure. You design a supervisor-worker graph: sub-agents call a shared tool-use or retrieval agent as-a-service, clean interface, no chatter needed. Then you check the trace logs and one agent — usually the first one you hand-tuned, the one with the most detailed system prompt — is getting invoked directly by every other agent for edge cases, because its prompt implicitly signals it can be trusted with exceptions and nobody ever revoked that trust. The orchestration diagram says clean handoffs. The trace says otherwise. Same failure, and it also shows up as a latency tax: every path that quietly routes through the 'trusted' node adds a synchronous hop — which is exactly how tail latency creeps into a multi-agent call, not from a slow model, but from the one node everything detours through out of habit.

The tell: look at who gets tagged, not who's on the chart

The org chart and the topology diagram will tell you nothing, because both describe intent. The tell lives in the audit trail of actual unblock decisions: who gets @-mentioned when something is stuck, who approves the PR that unsticks it, whose message in the thread ends the debate. Run this over two weeks, not one day — you want decisions, not activity.

• ▹Pull every Slack thread from the last 2 weeks tagged with decision language: 'unblock', 'final call', 'let's ship', 'go with'.
• ▹Pull PR review-requests and approvals for the same window across every team, not just your own.
• ▹Count @-mentions per person only on threads that end in a decision, not ones where someone just participated.
• ▹Cross-reference that name list against who the topology diagram says owns the decision for that team.
• ▹If one name outside the team's own roster shows up on unblock threads for 3+ different teams, that's your fifth team type — and it's probably you.

# crude version of the audit trail exercise
# 1) Slack export: who gets tagged on decision-shaped threads
grep -riE '@founder_handle' slack-export/*.json \
  | grep -iE '(unblock|final call|let.?s go with|shipping|approved)' \
  | wc -l

# 2) GitHub: who's being pulled into review across teams they don't own
gh pr list --state all \
  --search "review-requested:founder_handle created:>2026-08-29" \
  --json number,title,repository | jq length

The fix that actually worked

Deciding to delegate isn't the fix — it's the intention. The fix was making the new interaction mode visible, not just declared. With two teams specifically, I had to explicitly kill collaboration mode and force myself into x-as-a-service: I stopped answering in threads I used to answer in, on the record, in front of the team, even when I had the answer sitting right there. Saying nothing was the point. Quietly keep helping 'just this once' and the diagram stays a lie. The team needed to see me decline before they'd believe the mode had actually changed — and before they'd build the muscle to make that call themselves.

The harder fix: the load doesn't vanish, it moves

Here's the part that's easy to miss: when a founder steps back, the cognitive load of the decisions they used to make doesn't disappear. It moves. Do it intentionally, and it moves to the team — new decision-makers get the context and the authority together, which is the whole point of the redesign. Don't, and it moves right back to the founder through side channels: DMs instead of the team channel, a 'quick sync' instead of the documented process, a habit nobody scheduled. That's the default failure, and it's silent, because it doesn't look like a process problem — it looks like people being helpful. Same thing happens in agent fleets: scale from one hand-tuned agent to a fleet without explicitly redistributing the judgment calls that agent used to make into the new agents' prompts and tools, and the load doesn't disappear — either well-scoped new agents absorb it, or every agent quietly keeps escalating to the one you already trust, and you've just rebuilt the bottleneck with more infrastructure around it.

Close

Run this test today: whose name is on the last five decisions your team made? Mostly your team's own names, your topology is real. Mostly yours, you still have a fifth team type, no matter what the diagram says. Tomorrow we go one level down into the three interaction modes themselves — collaboration, x-as-a-service, facilitating — and how to choose deliberately between them instead of inheriting one by accident.

Extend your knowledge

• ▹Re-read the interaction modes chapter of Team Topologies (Skelton & Pais) and ask specifically: who outside my four official types is silently in collaboration mode with us?
• ▹Run the 2-week Slack/PR audit trail exercise from this lesson on your own team before tomorrow's lesson on interaction modes.
• ▹If you run any multi-agent or LLM orchestration systems, check your traces for the same pattern: an agent or service every other agent quietly calls directly instead of through the declared interface — it's the same bottleneck with different infrastructure.
• ▹Tomorrow (Day 9): the three interaction modes themselves — collaboration, x-as-a-service, facilitating — and how to choose between them deliberately instead of inheriting one by accident.