Busy is not a deliverable

Vitaliy Mogilevskiy · November 12, 2026 · 9 min read

Everyone is busy. Nothing ships.

It's the last month of the quarter. Your infrastructure team has four projects due: a major database upgrade, a new region, a change to how secrets are stored, and a QA environment someone promised a customer. Every one of them touches the same databases, the same network and the same deploy pipeline. Every engineer is on at least two of them. The Staff engineer is on all four coordination threads.

Everyone is busy. The board is full. And at the end of the quarter, two projects slip, one ships with a rollback plan nobody tested, and the team is too tired to care.

Busy is not a deliverable.

Building software got cheap. Operating it didn't. AI makes every change cheaper to produce, so more of them are heading for your production stack every week. The way most teams organize that work was already straining. It's about to break.

What an ODA actually is

The basic unit of U.S. Army Special Forces is the Operational Detachment Alpha: twelve people, each with a distinct specialty, or MOS. A commander; an assistant commander, a warrant officer who is the team's long-serving technical expert; an operations sergeant who runs the team day to day; an intelligence sergeant; and two each of weapons, engineer, medical and communications sergeants.

That's a cross-functional team in the most literal sense. Nobody on it is a generalist, and nobody works alone. Every specialty owns its piece of the problem, and leadership's job is to structure the work so the pieces arrive together.

And the whole detachment works one mission at a time. Between deployments, the team trains, rehearses, recovers, and builds the relationships it will rely on next time.

What we copied, and what we skipped

Software borrowed the shape. We call them squads, pods or stream-aligned teams: small groups with a mix of specialists. That part was a good idea.

What we skipped is everything that makes the shape work:

• One mission at a time. Squads became a way to run more projects in parallel. A team of eight carries four initiatives, and its specialists are spread across all of them.
• Command intent. An ODA knows the objective and what success looks like, and decides how to get there. Squads get a roadmap of outputs and a deadline.
• Recovery and training. An ODA's calendar has downtime built in. Ours is pedal to the metal, quarter after quarter, and the tech debt and burnout compound.

The result is the opposite of what squads were for. The point of a team of specialists is to bring one problem to completion fast, each person working the part they know best. We use them to start more work instead of finishing it.

The coordination doesn't go away, either. It gets labeled “cross-functional” and handed to whoever is senior enough to hold it all in their head. Usually that's a Staff engineer, who now spends the quarter in sync meetings instead of doing the work only they can do.

Why operations feels it first

Product teams can sometimes get away with parallel projects, because their work lives in different parts of the codebase. Operations can't. Every project eventually lands on the same shared stack.

Four concurrent projects means four sets of changes to the same databases, the same network and the same deploy pipeline, in the same quarter. They have to be sequenced around each other, tested around each other and rolled back around each other. Each one carries the others' risk. When something breaks at 3 a.m., the first ten minutes go to working out which of the four changes did it.

That's where morale goes to die: a team that's 100% utilized on paper, spinning its wheels, stepping on each other's changes, and slipping anyway.

AI makes it worse. Code is cheap to write now, so there's more of it, and every piece eventually needs a schema migration, a new service, a config change or more capacity. The volume of change heading for production is going up. The number of people who can safely land it is not.

The mission I still measure against

For eight years at Alcatel-Lucent, I worked on a team led by a former special operations officer. He's a private person and a good friend, so he stays unnamed here, but everyone who worked with us will know exactly who I mean. He ran our team like a detachment, and in those eight years we never failed a project.

One stands out. Eighteen software and functional engineers worked alongside our operations team to replace the legacy ERP system behind a fully automated offshore contract-manufacturing operation. It touched everything. We ran it as one mission:

1. Test rollout. Every step and every person identified and timed, and every change to every system sequenced, so each person knew exactly what to do, when and how.
2. Dress rehearsal. The whole thing again, end to end, adjusting the plan wherever reality disagreed with it.
3. Execution. The production cutover over a four-day holiday weekend, 24x7, exactly to plan. Nothing slipped.

What made it work wasn't the plan. It was him. He removed every obstacle in everyone's way. He advocated for the team with the people above him. He built real relationships with every one of us, so nobody could say no to him, even when it meant working nights, because he'd be right there next to you at whatever hour it was.

And after the push, he gave us time: to recover, to fix the tooling that had fought us, and to strengthen the infrastructure for the next wave. We sharpened the axe. That's the part of the ODA model almost nobody in software copies.

When he left, I ran those operations myself as part of an HP Enterprise consulting engagement, and kept running them his way.

The other way

Years later, at a different company, I watched an engineer get handed a QA environment to build on his own. It needed pieces from half a dozen teams: networking, databases, deploys, access. The experts who could have set up each piece in a day were busy with their own quarterly deliverables and couldn't spare one, despite his repeated asks.

He figured it all out himself and delivered on time, which says a lot about him. It also says a lot about the system. A few days of each specialist working their piece, together, would have made it a shorter, cleaner project, and he wouldn't have had to carry it alone.

Nobody did anything wrong. Everyone was busy.

“But software isn't a military operation”

Fair. These are the objections I hear most, and why I don't think they hold up for operations work.

• “Specialists will sit idle.” Some of the time, yes. A weapons sergeant isn't firing all day; his value is that he's there the moment he's needed. Queueing theory is blunt about this: as utilization approaches 100%, wait times explode. Fully booked is not the same as delivering, and the specialist with slack is what keeps the mission from stalling.
• “One big mission means late, risky integration.” Only if one mission means waterfall, and it doesn't. The team iterates inside the mission, and because everyone is on the same objective, integration happens continuously instead of at the end of the quarter.
• “Requirements change too fast.” Keep missions short and well scoped. Command intent survives a change of plan: a team that knows the objective can change how it gets there.
• “Conway's law says organize around the system you want.” Agreed, which is why the team is organized around the mission rather than the org chart's silos.

Where it doesn't fit is open-ended product discovery, when nobody knows the objective yet. That's real. But changing production isn't discovery. A database upgrade, a migration, a new region, a cutover, a DR test: each has an objective you can write down on day one. And that's exactly the work AI is multiplying.

Run your next production change like a mission

You don't need to reorganize your company. Pick your next high-risk change and run that one this way:

1. Command intent. One page: the objective, what success looks like, and what makes you abort.
2. One mission, the right specialists. Staff it with the people who know each piece best: the database owner, the network engineer, whoever owns the deploy pipeline. Clear their other work for the duration. If you can't, you don't have a mission; you have a wish.
3. Test rollout. Every step, owner and duration, in order, with a rollback for each.
4. Dress rehearsal. Run it end to end somewhere production-like, and fix the plan wherever it was wrong.
5. One operations lead for the window. One person runs the clock and makes the go/no-go calls. Everyone else executes their part.
6. After-action and recovery, on the calendar. Then turn the steps into runbooks and automation, so the next mission starts from a better place. Sharpen the axe before the next wave.

You can't hire operators after the outage

Special Operations Command has five principles it calls the SOF Truths. Two of them belong on every engineering leader's wall: “Special Operations Forces cannot be mass produced,” and “Competent Special Operations Forces cannot be created after emergencies occur.”

The same goes for the people who can run a mission like this. You can't grow a Staff operations engineer in a quarter, and you can't hire one the night of the outage. If you're hiring one now, the Pager Test is an independent interview built to find out whether a candidate has actually operated what they describe, and whether you'd hand them the pager at 3 a.m.