The team is burned out and I still have to ship.

What to do when the team is burned out and you still have to ship

San Francisco, late two thousand and thirteen. Pierre-Olivier Latour and his co-founders have been running Everpix for almost three years — by most measures, one of the best photo-storage products of the early twenty-tens. The conversion rate from free to paid is unusually high. The reviews are warm. The technology — automated organisation of personal photo libraries, before the major platforms have figured out how to do it — is genuinely good.

None of it is enough.

The problem is the aws bill. Everpix is hosting four hundred million photos for its users and the storage cost is growing faster than the revenue. The team works through it for as long as they can. An acquisition deal with Path collapses at the last minute. The founders make a choice almost no team will make. They offer to work for minimum wage — themselves first — for as long as it takes to find a buyer or close another round. The team agrees. They work for months on those terms.

It is still not enough.

A thirty-five thousand dollar aws bill comes due that they cannot pay. The founders shut the company down and post a long, honest goodbye explaining what happened.

The team has absorbed every bit of personal cost it can absorb. The gap between revenue and infrastructure is bigger than any amount of personal sacrifice can close.

When the team is burned out and you still have to ship, the question every manager has to face honestly is whether the gap between what is required and what is possible can actually be closed by the people in the room — or whether asking them to absorb the gap is asking them to break themselves against a problem the size of which has nothing to do with them.

So let's go to the office and work through it.

Ask whether the gap can be closed by the people in the room

"The team is burned out and I still have to ship."

The feeling is torn.

You can see what the team is carrying. You can also see the line you've been asked to deliver. Both of those things are real, and the question is whether the ship can land without breaking the team to do it.

Two choices. The team looks the same in either case. The first move is different.

When they're exhausted from working alone

Choice one: the team is exhausted from being alone. The burnout is shaped like isolation. People are grinding through their individual lists with no sense of being in it together. The energy is gone because each person is shouldering their own weight without anyone alongside.

If that's the read, pair them up to finish the remaining shipping work. Not as a process change. As a shift in the social texture of the last mile.

Johann Hari, working on what causes burnout, has written about connection as the opposite of burnout — not rest. The intuition that the cure for an exhausted team is more time off is half-right; people do need rest. But work that felt impossible alone often becomes possible when it's shared, and the sharing is what restores the energy rather than the help. The second person in the pair is doing less than their hours suggest. They're making the first person's hours bearable, which is a different kind of contribution entirely.

When the visible backlog is doing the damage

Choice two: the team is exhausted from the backlog. They are drowning in the visible length of what's left. Every time they look at the board they lose another day to despair, and the despair is doing more damage than the work.

If that's the read, hide the backlog. Change the interface so they only see the next three tasks. Not forever. Just until they've shipped.

Donald Hoffman's interface theory of perception says we don't act on reality. We act on what reality is showing us. The interface is the thing the team is interacting with, and what the interface shows them determines what they can do next. The backlog isn't motivating anyone; it's paralysing them. Showing them three tasks at a time is showing them a workload that's possible. Showing them the full backlog is showing them a workload that isn't.

Isolated, or backlog-paralysed. Same exhausted team. Two different first moves.

How to guard the energy the team has left

Three tools. The discipline is to protect the team's remaining capacity before you spend it.

Name what you've stopped carrying

The first is

Do Nothing.

Do Nothing as a leadership discipline traces back through the minimum viable management tradition that surfaced in the agile and lean literature of the two-thousands, with deeper roots in the Quaker management writing of Robert Greenleaf — the original servant-leadership material from the nineteen-seventies — and earlier in the Stoic philosophical tradition on what sits inside and outside your control. The contemporary corporate version is closer to J. Keith Murnighan's Do Nothing, published in two thousand and twelve.

The reason Do Nothing matters when a team is burned out is that the manager's instinct under pressure is to add. Add a process, add a check-in, add a tool, add a stand-up. Each addition is meant to help and each addition takes a small amount of capacity from a team that has none left to give.

The unique insight is that deliberate, named pause is a different operation from drift. The team that has dropped a task without saying so produces uncertainty: nobody knows whether it has been deferred, abandoned, or forgotten. The team that has explicitly paused a task produces clarity: everyone knows the task is paused, why, and when it might come back.

What you get is permission to stop carrying the things that aren't essential — and the permission to stop is what makes the permission to continue sustainable. A burnt-out team will not finish what's required if they're also carrying everything that isn't. The Do Nothing discipline is what releases the second pile.

So. How to run it.

Audit. Across one page or whiteboard, list everything the team is currently carrying. All of it. The recurring meetings, the ongoing initiatives, the half-finished work, the commitments to other teams.

Categorise. Three columns. Essential for this ship. Useful but not essential. Carrying out of habit.

Pause. Tell the team. Tell the stakeholders. We are not doing this for the next three weeks. We will revisit when we ship. The naming is doing the work. Drift produces resentment; named pause produces relief.

Revisit. Set a date. The pause is a deferral, not a deletion. The team needs to know it isn't being made permanently responsible for everything that just disappeared.

The discipline of Do Nothing is the discipline of being explicit about what you've stopped doing — which is, often, the only way to stop being secretly responsible for it.

See where the hours are really going

The second is

the Eisenhower Matrix.

The Eisenhower Matrix takes its name from a phrase Dwight D. Eisenhower attributed to an unnamed college president in a nineteen fifty-four speech to the Second Assembly of the World Council of Churches: I have two kinds of problems, the urgent and the important. The urgent are not important, and the important are never urgent. Stephen Covey formalised the four-quadrant grid in The Seven Habits of Highly Effective People in nineteen eighty-nine, and the framework has carried Covey's name as much as Eisenhower's ever since.

The reason the Eisenhower Matrix matters when a team is burned out is that the burnout is almost always concentrated in Quadrant One — urgent and important — and the cause is almost always a starvation in Quadrant Two — important and not urgent. The Quadrant Two work is the work that prevents Quadrant One fires from arriving. When Quadrant Two stops happening, Quadrant One grows, and the team burns out fighting fires that better Quadrant Two work would have prevented.

The unique insight is the four-quadrant discrete-elements diagnostic. Urgent and important — do it now. Important and not urgent — schedule it. Urgent and not important — delegate it or say no. Not urgent and not important — drop it.

What you get is a way to see, structurally, where the team's hours are actually going — and a forcing function for moving hours out of the firefighting quadrant.

So. How to use it.

Map. Take the team's actual recent work — the last fortnight, ideally — and place each item into one of the four quadrants. Be honest about which.

Diagnose. Most burnt-out teams discover that eighty per cent of their work has been Quadrant One — urgent and important — and Quadrant Three — urgent and not important. Quadrant Two has been starved.

Drop. The urgent-but-not-important work is almost always work that's urgent for someone else. It can be delegated, deferred, or refused. Most teams default to absorbing it because saying no feels riskier than saying yes; the matrix makes the cost of yes visible.

Schedule. The important-and-not-urgent work — the architectural simplification, the documentation, the test coverage, the conversation about the broken process — needs explicit calendar time. Without it, Quadrant Two stays starved and Quadrant One keeps growing.

The matrix is doing two things at once. It surfaces where the hours are going. And it provides a structural reason to defend Quadrant Two against the constant pull of Quadrant One.

Refuse work shaped to burn capacity without an outcome

The third is

the invest Model.

Invest was coined by Bill Wake in two thousand and three as a heuristic for what makes a good user story in agile software practice — Independent, Negotiable, Valuable, Estimable, Small, Testable — and the framework has spread from its original software-development context into project management more broadly as a quality test for incoming work.

The reason invest matters when a team is burned out is that some of the burnout isn't about the volume of work. It's about the quality of the work that's being asked of them. Badly defined incoming requests — vague, oversized, dependent on five other things, untestable — eat the team's hours regardless of what the matrix says about urgency. The team is exhausted because they keep getting asked to do work they cannot finish, because the work is shaped wrong.

The unique insight is invest as a rejection filter rather than a creation tool. Most teams use invest after a story has been written, as a quality check. The burnt-out-team use is to flip it round and apply it at intake — any incoming request that fails the test is sent back to origin until it doesn't.

What you get is a structural defence against badly defined work. The team isn't refusing because they don't want to help. They're refusing because the request, in its current shape, will burn hours without producing a result. The framework, not the manager, is doing the refusing.

So. How to use it as a filter.

Independent. Can this work be done without waiting on five other things first? If not, it's a dependency cluster, not a story. Send back.

Negotiable. Is there room to discuss what's in and out of scope? If the request is fixed-scope-fixed-time-fixed-everything, it's not negotiable, and rigid requests in burnt-out teams produce despair. Send back for re-shaping.

Valuable. Can the requester articulate the value to a real user or business outcome? Because Sales asked is not value. Send back until value can be named.

Estimable. Can the team give a meaningful estimate without three weeks of investigation? If not, the request is research-shaped, not delivery-shaped. Send back as a research spike rather than a build commitment.

Small. Could a competent team finish this in a sprint? If the answer is no, this is months of work, the request needs decomposition. Send back to be broken down.

Testable. Will the team know whether they're done? If the request can't be tested against any concrete criterion, done will keep moving. Send back for a definition of done.

Invest as a filter is the discipline of refusing work that is shaped to consume capacity without producing outcomes. The team's hours are finite; the filter protects them.

A precedent: running the team around the work, not harder

That's the toolkit. One more story before we close.

Everpix at the cold open showed a team that absorbed every personal cost it could absorb and still couldn't close the gap, because the gap was structural rather than personal. The story we close with is the inverse — a team under genuinely impossible conditions, in a leader who decided that the team's job was on one side of the wall and the leadership job was to absorb everything on the other.

Berlin, two thousand and fourteen. Lena Reinhard co-founds Neighbourhoodie Software, and her first formal engineering-leadership project lands almost immediately in the worst possible operating conditions. The contract is an offline-capable case-tracking system for eHealth Africa, deployed across Sierra Leone, Liberia, and Guinea during the two thousand and fourteen to two thousand and sixteen West African Ebola outbreak.

The field workers the software has to support often do not have reliable internet access in the settings where they are collecting data. Every technical or process failure in the system has a direct human cost measured in disease-tracking gaps. The structural pressure is of a kind most software-management training does not prepare anyone for: a distributed engineering team across two continents, an outbreak that intensifies month by month, a product that has to ship into hostile operating conditions.

And the team itself is exhausted.

Reinhard's response, formed across these months, is not to accelerate the team. It is not to introduce additional delivery metrics. It is to prioritise what she later popularised as holding space — a leadership pattern designed to shield a team from external chaos long enough for the team to do the specific work only they can do.

The default instinct, when a team is burned out and you still have to ship, is to find ways to run the team harder. Clearer priorities. Shorter iterations. More accountability. Reinhard's move is to run the team around. The work that needs doing is on the team's side of the wall. The leadership contribution is to absorb the chaos on the other side of it, so the team can continue to function.

The system ships. More importantly, the team that ships it is still the team afterwards.

So. Your Next Move from this playbook.

Which Quadrant Two task have you been postponing for three weeks because something more urgent kept appearing — and what's the cost of another week's delay?