Burnout as a bottleneck

Day 22: You Are the Bottleneck Node. Burnout as an Architecture Problem

If your team can't ship while you're asleep, you don't have a team. You have a queue, and you're the server. Once you become the person who knows everything, your team can only move as fast as you do, and your health depends on nobody ever testing that limit. At this stage burnout usually isn't about how many hours you work. It comes from how the team is built. A structural problem needs a structural fix.

The 1am moment, and the same failure in an agent

When I was founder-CTO, I opened Slack one night around 1am and counted the threads waiting on me. A schema change needed my approval. A customer escalation needed my call. Someone wanted to know if a deploy could go out. Someone else needed the history of a strange integration that only I remembered. None of them were stuck on a hard problem. They were all stuck on me. That night I understood I'd become the system's single point of failure.

Years later, during my PhD research on multi-agent systems, I watched an orchestrator agent make the same mistake. Every sub-agent reported back to it, and every decision went through it. As its context window filled up, its decisions got worse. It started forgetting constraints it had set itself. In the end, everything downstream sat idle waiting for its next turn. I recognised myself in that trace. The model was fine and so was the compute. The design had put all the context and all the decision authority in one node.

The trap: career growth rewards you for collecting context

Early on, knowing more is all upside. You fix things faster, you get pulled into the interesting problems, and people start saying "ask Cong, he knows." That reputation is what gets you promoted. Then every promotion sends more traffic your way: more systems, more people, more decisions. Nobody warns you about the point where all that context stops helping you and starts hurting you. Most people find it late at night.

Earlier in this series we covered influence and ownership. This lesson is the flip side of both. If you never hand ownership on, it turns into a bottleneck.

What actually broke

Here's what broke. There are no heroics in this list:

• ▹Decisions slowed down for the whole team. Anything that touched more than one area waited for me. A five-minute question took a day, because I was in a meeting, or asleep, or working through three other questions just like it.
• ▹My judgment got worse at night. The calls I made at 1am were clearly worse than the ones I made at 10am. I could tell because I kept reversing them the following week. The team got my worst thinking at exactly the moments that mattered most.
• ▹People learned to wait instead of deciding. This did the most damage. Capable engineers stopped making calls they were fully able to make, because the system had taught them that asking was safer. I'd trained my own team to depend on me.
• ▹Willpower didn't fix it. My first move was to try harder, and that made all three problems worse.

The multi-agent lens, in plain terms

A multi-agent system is a group of AI agents, each usually built on a large language model (LLM), working together on one goal. A common design puts a single "orchestrator" agent in charge. It splits up the work, hands the pieces to worker agents, collects what they send back, and decides what happens next. It's easy to build and easy to reason about. It also fails in three predictable ways.

The first is context overflow. An LLM can only look at a limited amount of text at once, called its context window. If every worker reports everything back to the orchestrator, that window fills up with detail. Quality often drops well before the hard limit: important instructions get buried, and earlier decisions get forgotten or contradicted. The human version is carrying every project's details in your head until you start dropping things, mixing them up, and losing track of what you already decided.

The second is queuing. If every step needs a decision from the orchestrator, workers sit idle waiting for one. The run takes as long as the orchestrator makes it take, no matter how much the workers could do in parallel. For people, that's decision latency: you have five capable engineers, and they all move at the speed of your inbox. The third is that nothing degrades gracefully. If the orchestrator stalls, times out, or goes off track, the whole run stops, because no other agent has the authority or the context to carry on. For people: you take a week off, or you burn out, and the team stops shipping.

Agent builders fix this by changing the structure. Each sub-agent gets its own context and the authority to finish its part of the work. It sends back a condensed result, not a raw transcript. Shared state lives in external memory such as files, a data store, or a task board, so it doesn't pile up in the orchestrator's window. The orchestrator sets goals and boundaries and leaves the individual steps alone. Every one of these fixes applies to you as well.

Why the obvious fixes don't work

• ▹Working harder is the same as adding compute. A bigger machine gives the orchestrator a bit more throughput, but everything still goes through one node. Longer hours buy you a few weeks. Then the traffic grows to fill the extra capacity, and you're back at 1am with less sleep.
• ▹Hiring a 'right hand' who still sends everything through you gives you two bottlenecks in a row. In agent terms, you've put a second orchestrator in front of the first. Every decision now makes two hops, and your deputy is working from an incomplete copy of what's in your head.
• ▹More meetings to keep everyone aligned just adds coordination overhead. In multi-agent systems, extra rounds of agents messaging each other cost tokens and time, and they often add very little. With people, a daily sync where you approve everything is the same bottleneck, just processed in batches.
• ▹All three keep the design and try to make it run faster. It's the design that has to change.

Fix part 1: delegate authority, not just tasks

If you hand someone a task and keep the decision, you haven't delegated anything. The request still comes back to you. In agent terms, it's a worker that has to ask the orchestrator before every decision. Real delegation moves the right to decide. The other person makes the call, owns the result, and tells you about it after it's done instead of asking first.

Practice: write down 3 to 5 types of decision you're going to stop making. For each one, name the owner, the boundary they work inside, and the point where they should bring it back to you. Publish the list somewhere the team can see it. It works a lot like setting an agent's tool permissions: explicit, scoped, and checkable.

# decision-ownership.yaml: published in the team repo, reviewed quarterly
decisions_i_no_longer_make:
  - type: "Library / dependency choices within a service"
    owner: "Service tech owner"
    boundary: "Licence is approved; no new infra cost"
    escalate_if: "Touches auth, billing, or data residency"

  - type: "Release go / no-go for routine deploys"
    owner: "On-call engineer"
    boundary: "CI green, rollback tested"
    escalate_if: "Customer-facing migration or contract SLA at risk"

  - type: "Prompt / model config changes for internal agents"
    owner: "AI platform owner"
    boundary: "Eval suite passes; cost per task within budget"
    escalate_if: "Model provider change or new data leaves our boundary"

  - type: "Sprint scope trade-offs"
    owner: "Squad lead"
    boundary: "Quarter goals unchanged"
    escalate_if: "A committed customer date moves"

Pitfall: overruling a delegated decision because you'd have done it differently. Do it once and the team learns the delegation was never real, and all the traffic comes straight back to you. Only step in when an escalation trigger fires. Give feedback afterwards, and in private.

Fix part 2: keep context close to the work

Authority without context leads to bad decisions, so the context has to move too. It belongs in documents, architecture decision records (ADRs), runbooks, and the heads of the people doing the work, not just in yours. This is the human version of giving agents external memory and retrieval instead of cramming everything into one context window. It matters even more now that AI agents write a growing share of our code. An agent can read an ADR. It can't read your memory. When a team's context lives only in people's heads, its coding agents produce worse output too.

Practice, for one week: every time someone asks you something, put the answer where they could have found it on their own. Write it in the docs, an ADR, the README, or the team channel, then reply with a link. Don't answer in a DM. By Friday you'll have written down the context people need most, and the team will have learned to look before they ask.

• ▹A question in a DM gets answered in the public channel or the docs, and you reply with the link.
• ▹"Why did we build it this way?" gets a short ADR covering context, decision, and consequences.
• ▹"How do I deploy X?" gets a runbook that a new hire, or a coding agent, could follow.
• ▹Pitfall: writing a giant wiki nobody reads. Only write down what someone actually asked about, and let demand decide what gets documented.

Fix part 3: design for graceful degradation

A well-designed system keeps running, maybe at reduced capacity, when one part fails. Your team should keep running when you're not there. Try the two-week disappearance test. Imagine that starting tomorrow, nobody can reach you for two weeks. No Slack, no phone. List everything that would stall, and be honest about it. Include approvals, credentials, customer relationships, knowing how deploys actually work, and code reviews that only you can do.

That list is your burnout risk register. Every item on it is a place where the team can only move if you're available. Clear one or two items per sprint: hand over the authority (part 1), write down the context (part 2), or train a second person. Then test it. A planned week of PTO where you actually disconnect is a chaos test for your team.

| Would stall without me      | Why                          | Fix                              | Owner after | Done by |
|-----------------------------|------------------------------|----------------------------------|-------------|---------|
| Prod DB migrations          | Only I approve               | Delegate + migration runbook     | Platform TO | Sprint 2 |
| Key customer escalations    | Relationship lives with me   | Joint calls x3, then hand over   | Account EM  | Sprint 3 |
| Agent eval thresholds       | Rationale undocumented       | ADR + eval README                | AI owner    | Sprint 1 |
| Reviews on payments service | Only qualified reviewer      | Pair-review until 2nd reviewer   | Senior dev  | Sprint 4 |

Self-check: five signs you've become the bottleneck

• ▹People DM you instead of asking in the channel, because they know you're the one who'll answer.
• ▹Your PTO gets scheduled around releases, or releases get scheduled around your PTO.
• ▹You're the only reviewer, or the required one, on critical code paths.
• ▹Decisions you've delegated still come back to you for 'a quick sanity check'.
• ▹You have more unread threads than anyone on the team, and you clear them late at night.

If three or more of these sound like you, longer hours won't help. The team's setup has to change.

What changed at PhoenixDX

When I joined PhoenixDX as an Engineering Manager, I did all of this deliberately, and I did it early. I wrote the decision-ownership list in my first few weeks. I answered questions in docs instead of DMs. I ran the disappearance test and worked through the register. It was uncomfortable at first, because I was choosing to make myself less central. The results were clear. Decisions stopped waiting on my calendar. Engineers made the calls I would have made, sometimes better ones, because they were closer to the work. Our coding agents got better context because it was finally written down. And I slept.

Carry this into the rest of the course. Up to a certain level, you grow by becoming more necessary. Beyond it, you grow by becoming less necessary. You stop being the node that does the work and start designing the system that does it. The next few days build on that: how to scale your impact through other people, once your output is the output of the team you've set up.

Extend your knowledge

• ▹Run the two-week disappearance test this week, then turn the list into a register with owners and target sprints.
• ▹Read Anthropic's engineering posts "Building effective agents" and "How we built our multi-agent research system" to see how agent builders handle delegation, sub-agent context, and orchestrator load.
• ▹Read "Team Topologies" by Matthew Skelton and Manuel Pais, especially the parts on team cognitive load and keeping dependencies between teams small.
• ▹Read Michael Nygard's original description of Architecture Decision Records ("Documenting Architecture Decisions", 2011), then write your first ADR based on a question someone sent you in a DM.