The Human Cost of Mobbing All Day Work (Part 4)

Misallocated talent is a business problem

This point deserves to be stated plainly: flattening distinct engineers into generic units of "senior technical labor" is commercially irrational, not just dehumanizing.

Highly experienced people are costly for a reason. They are not merely faster typists or more expensive implementers. They bring judgment. They see risk earlier. They recognize patterns. They know when a local decision will create downstream drag. They often prevent damage that never becomes visible because their presence kept it from happening.

When an organization deploys those people as if they were interchangeable bricks, it wastes precisely what it is paying for.

I think here of my own role on that brand-new federal greenfield project. I was the team's senior DevSecOps engineer. My value was not that I "knew programming" in the abstract. My value was that I knew security, risk, architecture, delivery constraints, and how to help a system become safer before insecurity became embedded in its foundations.

A process that reduces that kind of expertise to "take your turn driving Java in the shared environment" is not merely asking a person to stretch. It is misallocating expensive talent.

The Tiger Woods analogy I used in Part 1 applies here too. If you hand Tiger Woods a hockey stick and put him into an NHL Stanley Cup game, his athletic gifts do not disappear. The organization has simply created a context in which those gifts cannot be translated into recognizable value. That is not an efficient use of elite talent. It is a spectacularly poor one.

In business terms, this matters because organizations do not merely pay for labor hours. They pay for the probability that the right kinds of judgment will be applied in the right places. When the operating model prevents that judgment from surfacing, the organization does not get the full return on its payroll.

Quality suffers when thought gets shallow

There is another cost that often remains hidden until later: quality degradation.

A team in continuous managed availability mode may still ship code. The output may even look brisk. Features move. Screens change. Commits happen. Tickets close. The dashboard can look healthy.

The question is what kind of thinking produced the code.

Shallow, interrupted, role-rotated work tends to push teams toward local correctness rather than deeper coherence. People solve the thing in front of them. They satisfy the immediate constraint. They keep the room moving. They maintain momentum. They do not always have enough private cognitive space to ask the more expensive questions:

Is this abstraction sound?
What security risks are we normalizing here?
What hidden assumption is about to become part of the architecture?
What defect class are we creating for later?
What operational burden will this impose in production?
What are we teaching the codebase to become?

Those questions are not luxuries. They are often where the real money is.

A defect that slips through because no one had enough uninterrupted time to think carefully is expensive. A brittle design decision made under constant transition is expensive. A security concern missed in greenfield development is expensive. Rework is expensive. Production incidents are expensive. Loss of client trust is expensive.

Not all of that can be pinned on one collaboration model, of course. Real delivery is far messier than that. The point is that environments which keep thought near the surface create conditions in which preventable downstream costs become more likely.

That is a profitability problem.

The team may be learning more slowly than it appears

Another subtle cost hides inside the promise that "everyone will learn the whole system together."

Sometimes that is true in a useful way. More often, the learning is shallower and slower than the visible togetherness suggests.

Deep learning requires wrestling. It requires trying, failing, tracing, comparing, reflecting, and sometimes sitting alone with the problem long enough for the pieces to click. A highly synchronized environment can expose people to many moving parts, though exposure is not mastery.

This matters especially when experienced engineers are working outside their native tools or domains. They may be present for the work all day long, yet still have too little private ownership over the problem to consolidate real fluency. The system can generate the appearance of constant learning while actually slowing the transition from observation to independent competence.

For an organization, that means the cost of synchronization may be paid twice: once in reduced present-day throughput and again in slower development of durable individual capability.

Attrition and disengagement are not free

There is also the problem many organizations least want to measure: what happens when the environment itself pushes good people away, or leaves them present but diminished?

An engineer who feels chronically flattened, publicly mismatched, or neurologically overrun may still keep showing up for a while. The resignation often begins long before the resignation letter. A person can remain on the payroll while disengaging from initiative, creativity, experimentation, and discretionary effort. The team still has the body. It has less and less of the mind.

If the person eventually leaves, the organization incurs familiar costs: replacement, onboarding, knowledge loss, project disruption, recruiting time, managerial time, and downstream instability. Those costs are easy to list. They still tend to be discussed only after the departure, as though the environment played no role in creating the condition.

Even when people stay, a culture that makes participation cost-prohibitive wastes some of the most valuable thing an experienced engineer can bring: judgment offered freely, with confidence, from a position of real engagement.

That is a business loss whether anyone labels it that way or not.

Why the model feels efficient anyway

Given all of this, it is worth asking why such models persist.

Part of the answer is that they solve a real managerial pain. Remote work makes leaders anxious when they do not understand how knowledge work behaves. Continuous collaboration quiets that anxiety. It replaces invisible work with visible activity. It creates an atmosphere of alignment. It reduces the fear that someone, somewhere, is stuck or idle or disconnected.

It also gives teams an immediate sense of momentum. Things are always happening. People are always engaged. Questions get answered in real time. Nobody disappears.

Those are not fake benefits, but they're also not free benefits.

The model feels efficient because it concentrates visibility and compresses uncertainty. What it often fails to do is maximize the amount of careful, high-value engineering work produced by the people inside it.

That is the difference between looking busy and being profitable.

The profitability question

I am deliberately using the word profitability here, even though not every team measures success in direct profit-and-loss terms.

The reason is simple: engineering time is expensive. Whether you are serving private clients, internal business stakeholders, or the federal government, the underlying financial question still exists. Are we converting costly human effort into durable value at a sensible rate?

If the answer is no, the organization is losing money even if the loss is hidden inside labor utilization, missed opportunity, preventable rework, or underused expertise.

A mob-all-day model can harm that conversion in several ways at once:

it reduces sustained deep-work time
it increases transition and recovery cost
it encourages visible participation over role-appropriate contribution
it mistakes shared presence for shared understanding
it suppresses specialist leverage by flattening expertise
it inflates ceremony cost at project scale
it increases the probability of shallow decisions and downstream rework
it raises the risk of disengagement and attrition among costly professionals

None of these losses may be dramatic on any given afternoon. That is part of why they are easy to tolerate. Their force is cumulative.

A delivery model does not have to produce immediate catastrophe in order to be economically unsound. It only has to be wasteful enough, consistently enough, that the organization gets less durable value from expensive people than it should.

That is a much lower bar than many leaders realize.

The business question is still a human question

It may be tempting to separate the human case from the business case too sharply, as though Part 1 was about feelings and Part 2 is about real operational concerns.

I do not think that separation holds.

The business cost exists largely because the human reality is what it is.

The reason constant managed availability hurts output is that people are not abstract processing nodes. They are embodied minds with finite attention, distinct strengths, varying transition costs, and different neurological profiles. A system that ignores those realities does not become more efficient by doing so. It simply buries the cost until it reappears somewhere else in the ledger.

That is why I think Joel's item 8 deserves to be taken more seriously in 2026 than it sometimes was in 2000. This is not a soft question about comfort. It is a hard question about whether the environment allows expensive professionals to produce the kind of value they were hired to create.

A team can look intensely collaborative while quietly eroding its own return on talent.

That is the productivity cost nobody wants to measure.

And it is often paid long before anyone admits it exists.