Why engineering teams keep burning out on cycles their boards can't see

Every engineering manager I've worked with over the past decade has run into the same pattern, usually more than once. The team adopts Scrum or Kanban properly, the board is clean, stand-ups happen, velocity is tracked. And still, every quarter or so, the same sequence plays out: a stretch of crunch, a wave of quiet burnout, a tense conversation with stakeholders about missed dates, and a reset that lasts until the next cycle starts.
When this happens once, it looks like a staffing problem. When it happens on three different teams across two companies, it starts to look like the framework is missing something.

I spent a long time assuming the missing piece was discipline, that teams just weren't following their chosen method strictly enough. After auditing enough teams that were following it strictly, I stopped believing that. The methods themselves are incomplete: they give you one feedback loop (work in progress, visualised on a board) and treat that as the whole system, but it isn't.
The clearest example I have of this came from a payments platform rollout I was brought in to audit last year. Twenty-two engineers across four squads, eighteen-month timeline, integrations with three external acquirers and a regulatory deadline that wasn't going to move. The team was running Scrum-of-Scrums, the boards were immaculate, velocity was being tracked across all four squads. By month four they were six weeks behind, two engineers had quit, and nobody on the team could point to the moment things had gone wrong. There was no single bad decision. The system was failing across several axes at once, and the board didn't show any of it. That's when the head of engineering asked an outside pair of eyes to look at what was actually happening underneath the workflow.

Most discussions of team productivity focus on what's visible: cycle time, throughput, WIP, lead time. These are useful, but they describe symptoms.
The reason teams overload predictably is that there are at least three control loops governing how engineering work flows, and most teams only run one of them explicitly. The other two run implicitly, through hallway conversations, intuition, the lead's gut feeling about whether people are okay this week. When those informal channels fail, when the lead is on vacation, when the team grows past the size where one person can hold all the context, when a reorg breaks the relationships, the implicit loops break, and the team starts cycling between overload and recovery without anyone naming what's happening.
A few researchers and practitioners have tried to make these missing loops explicit. The framing I've found most useful comes from a paper by Yuri Yurkov, which lays out a three-loop model of flow management (The 3-Loop Flow Method As A New Operational Model For Knowledge Work Management: A Multi-Loop Control System Approach). I don't agree with every parameter Yurkov proposes, and I'll get to that, but the structure of his model is the clearest articulation I've seen of what conventional methods leave out. On the payments audit I used it as a diagnostic checklist first, and as the basis for the recommendations I brought back to the engineering leadership second.

The first loop governs what the team commits to. It runs weekly, and the commitment budget is supposed to be calculated from what the team has actually completed over the previous several cycles. This sounds obvious. In practice almost no team does it. Commitments get set by external pressure — a stakeholder pushing for a date, a roadmap promise made two quarters ago, a velocity figure that hasn't been recalibrated since the team composition changed. The result is a structural mismatch between the work being pulled in and the work the team can sustainably finish.
When I pulled the payments team's intake history out of their tracker, the mismatch was stark. The squads were committing to roughly 140% of their six-week rolling average, every sprint, for three months running. Nobody had sat down and done the arithmetic; the commitments were being set in planning meetings where the question was "can we get this in?" rather than "what does our actual completion rate say?" The 40% gap was being absorbed by overtime, dropped code review, and skipped testing, which is exactly what you'd expect.
The fix is mechanical: pick a window (I use the last six weeks), look at what actually closed, and use that as the ceiling for what gets committed next week. Anything above the ceiling goes into a holding queue. Stakeholders see the ceiling and the queue. After the payments team adopted this, it took them about a sprint of pushback before the rule held, commitment-to-completion ratio moved from about 0.7 to a steady 0.95 within four sprints.

The second loop is execution. From a distance it looks like standard Kanban: pull-based work, WIP limits, cycle time tracking. The piece that conventional Kanban deliberately doesn't address is what happens when the system goes off the rails.
Yurkov's contribution here is to make the team's operating mode explicit. At any point, the team is in one of three states: Normal, Overload, or Recovery. The transition rules are agreed in advance. If WIP exceeds a threshold, or if cycle time drifts past a defined limit for some number of items in a row, the team enters Overload: no new work pulled until the queue drains. Once it drains, the team enters Recovery, with a reduced intake cap, until throughput stabilises for an agreed window.
On the payments team, the moment one of the squads was formally declared in Overload (cycle time on stories over eight points had drifted from a seven-day median to nineteen days over the prior month) was politically uncomfortable. The product manager had three features queued for that squad. But the rule had been agreed in advance, which meant the conversation was about the rule, not about the squad's commitment. The squad spent eleven days in Overload, drained the queue, spent another two weeks in Recovery, and came out with cycle time back at eight days. They did not have to repeat that ritual on that squad.

This is the loop that most frameworks ignore entirely, and the one that, in my experience, accounts for most of the productivity that disappears in mid-sized engineering organisations.
Every work item belongs to some cognitive domain, like a service, a subsystem, a problem area. Yurkov calls these Context IDs. A person's active contexts is the count of distinct domains they currently own work in. When that number crosses a threshold, no further assignments go to them until something closes. The reason this matter is that mental context-switching is not free, and it does not scale linearly, but because cognitive load doesn't show up on a board, it's the first thing to get sacrificed.
When I ran a context audit on the payments team as part of the engagement, the numbers were worse than I'd expected. The median engineer was carrying 4.2 active contexts. Two of the senior engineers were at seven. Both of them were also the ones being pulled into every architectural conversation, every incident, every onboarding, because they had the most context, which was exactly the problem. The board showed each of them owning two or three tickets. It did not show that those tickets sat across six different services, plus an active incident channel, plus a hiring loop.
Tracking active contexts is the most useful instrumentation change I've recommended on teams I've audited. It surfaces the real cost of cross-cutting work, and it gives the team a defensible reason to push back on assignments that look small in isolation but break someone's focus on something larger.

Yurkov's paper proposes a context threshold of one to three active domains. For individual contributors that range is roughly right, three is usually the upper edge of where focused work survives.
The cap I recommended on the payments engagement was three for ICs and five for leads. Five was probably one too high, by the end of the project the leads were visibly stretched, and one of them told me in an interview that he hadn't done any real architectural thinking in two months because his context budget was being consumed by coordination, but three would have made the role unworkable. The honest answer is that the threshold scales with role and probably with seniority, and any team adopting the model needs to calibrate it on their own data rather than copying numbers out of a paper.

The payments platform shipped on time, which after the month-four audit I had stopped expecting. The cost was real: six weeks of explicit Overload across two of the four squads, a renegotiation with the product side about which features were going into the regulatory release versus the follow-up, and several weeks of work to rebuild the intake and context-tracking instrumentation in the team's existing tooling.  The thing I took from the engagement is that the visible workflow is the smallest part of what makes engineering teams function. The actual machine is the set of feedback loops underneath, and most teams are running that machine with two of the three loops disconnected.
If your team is running Scrum or Kanban cleanly and still cycling between overload and burnout, the framework isn't the problem. The problem is that the framework only addresses one of the loops governing how work flows, and the other two are running on informal channels that break under load.