The Unit of Allocation Is No Longer the Person

For most of my career, allocating work was simple. You had a thing that needed doing, you had a person, and you assigned the person to the thing. The person was the unit of allocation. One engineer, one project, one thread of effort. When the work got done, you assigned them to the next thing.

That model is dead at my shop, and I suspect it is dying at yours.

In an agentic development organization, no one works on just one thing. Every engineer is running multiple stacks of work simultaneously, orchestrating agents that do the bulk of the execution while the human supervises, steers, and unblocks. When I need something done now, I do not assign a person. I assign a thread of someone's attention. And that turns out to be a much harder problem than assigning a person ever was.

The visibility inversion

When the unit was the person, capacity was legible from above. A person was either allocated or available. You could look at the org chart and the project list and do the arithmetic. Management as a discipline was built on that legibility. The manager saw the whole board; the worker saw their piece of it.

That assumption has inverted. When the unit is a thread of attention, the engineer is the only one with visibility into their own run queue. They know which agents are executing, which are blocked, which are waiting on review, which need intervention, what context is loaded, and what context is about to go stale. I know none of that, and I structurally cannot. There is no report that surfaces it, because the state lives in twenty run queues that change by the minute.

For the first time, the individual contributor has dramatically more situational awareness than anyone above them. This is not a communication problem to be fixed with more standups. It is an information-theoretic change in the organization, and it has an unavoidable consequence: scheduling decisions must be delegated to the node. The engineer is the only one capable of making that scheduling decision with current information. This is not autonomy as a management philosophy. It is information locality as a fact.

That delegation exposes the second problem: the variance is enormous. In my organization, the spread runs from engineers carrying one or two threads to engineers carrying fifteen. That is not a rounding error in capacity planning. It is an order of magnitude of difference inside a single team with the same agents available to everyone. Part of the spread is the work itself, because thread count is partly a property of what you are carrying: well-specified, testable, isolated work is cheap to carry, while ambiguous, cross-cutting work generates intervention and burns foreground attention. But the mix does not explain an order of magnitude. Two things do, and they move on very different timescales. The first is fluency with context management and the coordination tooling, which is learnable in months. The second is engineering judgment, and that one is not fast. My highest-multiplexing engineers have fifteen to twenty years in this industry. Supervising many threads means making rapid, correct calls on agent output across all of them at once, and that speed comes from a pattern library built over decades of watching things go wrong. The engineers at the low end are not lesser engineers. They are earlier on both curves. But I want to be direct about what this means, because it runs against the prevailing narrative. Agentic development does not level the experience curve. It takes what was an incline and turns it into a cliff, and that cliff is hard to surmount. When execution is cheap, judgment is the binding constraint, and judgment is the thing experience builds. What that cliff means for how the next generation of engineers builds judgment at all is a question I take seriously and do not have an answer to. Not a partial answer, not a framework, nothing beyond inklings. It deserves its own essay, and an honest one. Right now, those two skills together dominate every other variable in individual throughput, and their distribution across the organization is wildly inconsistent.

So we have an organization full of self-schedulers with no shared instrumentation and wildly different throughput characteristics. That is the problem we are working on.

Foreground and carrying

The first structural move we made was to stop pretending all concurrent work is the same kind of work. We now divide an engineer's load into foreground tasks and carrying tasks.

Foreground tasks are the things you are actively driving. Highest priority in your queue, the work you push on every day. We are getting better at predicting completion for foreground work. Not good, yet. The variance is still uncomfortable. But better, and improving.

Carrying tasks are everything else you are responsible for. You move the needle on them as you can, and "as you can" turns out to be quite often. But we do not even attempt to predict completion dates for carrying work, because completion depends on a complex, interacting set of factors: what else lands in your foreground, what blocks, what an agent can advance without you, and what needs your judgment. Pretending we can forecast that would be theater. So we forecast the foreground, and we let the carrying flow.

This distinction sounds small. It is not. It gives everyone a shared vocabulary for load. When an engineer says, "I can carry that, but I cannot foreground it," that is a precise statement about attention allocation, and it is a statement only they are positioned to make.

The tooling mandate, and how I changed my mind without being wrong

The second structural move is the one that surprised me: we now mandate standard tooling.

I need to be honest about my history here. I have spent thirty years as a terminal person. Emacs, Vim, the operating system as my IDE. Every time an employer mandated a heavyweight development environment on me, my productivity dropped, and I learned early to judge engineers on outcomes rather than tools. I have been vocally, sometimes obnoxiously, against tool imposition for my entire career.

I was not wrong. In the artisanal era, tool choice was inseparable from craft. A master's tools are an extension of the master, and standardizing them costs you exactly the mastery you hired for.

But if I kept walking that path, I would become wrong, because the era changed underneath us. Manufacturing thinking never worked on software for one reason: human attention was not manufacturable. Machine attention is. Once the bulk of execution moves to agents, the manufacturing playbook stops being a category error and starts being the correct frame. And to be precise about what that means: we are not standardizing the human. We are standardizing the machinery around the human, because the human is the scarce resource, and the structure exists to multiply attention, not to grind it down.

The results settled the argument. The engineers who use our standard tooling well simply carry more than the engineers who do not. We tried optionality because optionality was the default and the tradition. We got variance. We mandated standards, and the number of concurrent threads an engineer could drive went up. The mechanism is specific: context management. Every thread an engineer carries has a state, and holding that state is what consumes attention. When the standard tooling holds the state, the human can hold more threads.

Cockpits, not IDEs

The mandate is narrower than it sounds, and the boundary is principled. I do not care what editor you use. I am never going to mandate Emacs, tempting as that is. Craft tools remain personal.

What we mandate is the coordination layer. The tools that create visibility into what is running, what is blocked, what is queued, and what needs a human decision. In our case, that is a small set of internal tools for task orchestration, stacked change management, and agent supervision, integrated tightly with the terminal because the terminal is where everything lives.

Here is the frame that finally made it click for the organization: we are not mandating an IDE, we are mandating a cockpit. And frankly, if you are opening an IDE at all, you are probably reaching for the wrong tool, because in this model the human should rarely be writing code. Your job is no longer coding. Your job is flying. A pilot does not get to choose a bespoke altimeter, because the instruments are how the pilot sees, and how everyone else sees the pilot. Standardized instruments are what make it possible to run many aircraft through the same airspace.

I mean the claim about IDEs as a claim about abstraction, not preference. An IDE is organized around source artifacts: files, classes, symbols, references. Those are implementation units. Agentic work is organized around execution units: threads, agent state, blocked work, pending decisions, intervention points. Which thread should receive my next five minutes is a first-class question in this world, and an IDE has no data model for it. That is not a missing feature. It is the wrong ontology. A text editor is technically sufficient to administer a Kubernetes cluster, since after all you can edit the YAML, but nobody serious calls a text editor the operational interface to a distributed system. Distributed systems needed a control plane. Distributed cognition does too. That is what the cockpit is.

I will make this concrete with the data point I know best. I recently counted what I am personally carrying in this cockpit, and the answer is somewhere between twelve and twenty concurrent threads at any given time. Three to four in the foreground, the rest carrying. My most senior engineers run up to fifteen in the same cockpit. I do not offer these numbers as targets, and I doubt they are anywhere near the ceiling. I offer them as existence proofs. Those numbers were not possible for anyone here two years ago with any tooling, and they are not possible today in an IDE. They are what happens when the instruments hold the state.

There is a compounding effect we did not fully anticipate. Because everyone flies the same cockpit, everyone hits the same friction, and everyone improves the same tools. Our tooling iteration speed has climbed dramatically since we standardized, because improvement effort is concentrated instead of scattered across twenty personal setups. The mandate is not a static constraint. It is a flywheel. The more people use the standard tools, the faster the tools get better, and the more obviously correct the standard becomes.

The problem we have not solved: steering

All of that is the part that is working. Here is the part we are in the middle of.

Delegating attention allocation to engineers produces good local decisions. And I want to be precise here, because this is not a crisis. The things that must ship are shipping. Our engineers are choosing genuinely valuable work.

But we have excess capacity now, real surplus attention, and I am watching where it flows. It flows toward what is interesting. Engineering infrastructure, observability, metrics, operational polish. All of it broadly useful, none of it wasted. The subtlety is in the time horizon. That work is useful eventually and generally. The user-facing, revenue-generating work is useful right now and specifically. And the distribution between the two is not matching the strategy.

This is the predictable consequence of the model. When you delegate scheduling to the nodes, the nodes optimize on the gradient they can see, and the gradient an engineer can see is technical. The revenue gradient lives somewhere else in the organization. Allocation has become local. Prioritization cannot. Nobody is making a bad decision. The system as a whole is simply not pointed quite where it needs to point.

So the question I am working right now is where to put the steering wheel. How does an organization direct surplus attention toward strategic priorities without reverting to top-down assignment, which is exactly the model we dismantled because it cannot see attention load? The new answer has to be some way of making the strategic gradient as visible to the engineer as the technical gradient already is, so that the same good local judgment that runs their attention also runs it in the right direction.

I do not have that answer yet. But I can already see what it implies. The old organization optimized by assigning work. The new one has to optimize by shaping the environment in which work is chosen. If engineers own their own scheduling, then leadership's job is no longer deciding what people do. It is deciding what local decisions become globally rational. My suspicion is that the answer looks less like better reporting and more like economics: some mechanism by which strategic priorities can bid for attention in terms an engineer can weigh locally. That is a suspicion, not a design. Working it out is a different job than the one most of us were trained for, and I suspect learning it is the actual work of the next few years.