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

Joel Spolsky's eighth item in the Joel Test asked a deceptively simple question: do programmers have quiet working conditions?

In 2000, that question was often about cubicles, doors, offices, and noise. In 2026, the question runs deeper. The modern threat to serious engineering work is not only a loud office or an open floor plan. It is the environment in which a developer is never truly allowed to disappear into the work at all.

Some organizations have recreated the worst features of the noisy office through remote work. They have taken a medium that could have supported autonomy, flexibility, asynchronous collaboration, and thoughtful silence, then used it to impose continuous shared presence instead. The language used to describe that arrangement is often upbeat and reassuring: collaboration, alignment, pairing, mobbing, teamwork, support. The lived experience can be something else entirely.

A more accurate phrase for some of these environments is continuous managed availability.

That phrase may sound severe, though I think it is precise. The problem is not collaboration itself. Pairing can be valuable. Mobbing can be valuable. Shared debugging can be valuable. Junior engineers and interns can learn a great deal by watching experienced people reason out loud. Hard migrations, incident response, tricky architectural changes, and unfamiliar codebases can absolutely benefit from intense synchronous work.

The trouble begins when a bounded technique becomes the default operating model for the whole day, every day.

I worked in one remote environment where teams were expected to remain on Zoom from the beginning of the workday to the end. The larger team was about forty-five people, though people were divided into smaller breakout rooms of roughly five to eight engineers working on related aspects of the same project. The working model was called "mobbing" which we later renamed "collaborative coding." One person acted as the driver. One acted as the navigator. The remaining participants primarily contributed through Zoom chat. The driver and navigator changed at regular intervals throughout the day according to a schedule set in advance, typically somewhere between every five to ten minutes.

On paper, that model may have looked efficient, modern, and highly collaborative. In practice, it created a very different experience. It did not merely invite collaboration. It required persistent social and cognitive availability. It treated uninterrupted co-presence as the default condition of engineering work.

That distinction matters.

A healthy collaborative culture says, "We will come together when it helps us think better, solve faster, or learn more."

An unhealthy one quietly shifts to, "You will remain available to the group at all times, and your body, attention, and private thought must fit around that requirement."

That is not a small shift in tone. It changes the moral and cognitive character of the work.

Quiet is not the point

Joel was right to care about quiet, though the word itself is too narrow for the problem many engineers face now.

A room can be quiet and still be hostile to concentration. A remote call can be orderly and still be neurologically expensive. The deeper issue is not just sound. It is whether the environment protects the fragile mental state required for serious engineering work.

Software development is not usually a sequence of tiny independent thoughts. Good engineering work requires the slow construction of an internal model. You have to hold the architecture, the flow of control, the data structures, the hidden assumptions, the edge cases, the naming choices, the recent failures, and the intention behind the change in your mind at the same time. That structure takes effort to build. Once built, it is easy to disrupt.

A noisy office can disrupt it. So can a casual interruption. So can an all-day collaborative environment in which you are never allowed to stop monitoring the room.

This is why the modern form of item eight should ask whether engineers are allowed to achieve sustained cognitive depth without chronic self-management, not ask merely whether programmers have quiet working conditions.

The phrase, "chronic self-management" is important.

Many people can survive difficult environments by compensating. They mask. They endure. They keep one eye on the chat. They mute and unmute. They smile through interruption. They work their meals and restroom breaks around the collaboration schedule. They monitor the clock so they will be ready for their next public role. They privately absorb the cost and the stress at their own personal expense.

From the outside, this may still look like productive participation. From the inside, it can feel like trying to carry water in your hands.

The hidden human cost

The first great cost of a mob-all-day model is depletion. It's not merely distraction.

When people describe environments like this, they often talk first about lost focus, and that is certainly part of the story. Focus matters. So does throughput. So does code quality. Those deserve their own treatment.

Before we even get there, though, there is a more basic truth: some forms of collaboration are exhausting in a way that traditional management language does not know how to describe.

A developer in an all-day Zoom collaboration model is doing far more than simply simply writing code and occasionally talking. That person is often doing several things at once:

• staying aware of the shared conversation
• tracking the code under discussion
• watching for Slack messages and side-channel input
• anticipating the next turn as driver or navigator
• managing tone and responsiveness
• deciding whether there is time for a quick break
• suppressing irritation when the work rhythm becomes unnatural
• trying to remain mentally ready while also attempting to think

That is far more than one small cognitive surcharge.

This is one reason many organizations misunderstand what they are asking of their engineers. The work is more than only the visible task on the screen; there is also the invisible labor required to remain continuously present, regulated, socially responsive, and contextually available.

That invisible labor becomes even more expensive for people who are on the ASD spectrum, who are highly sensitive, highly introverted, ADHD, or otherwise neurologically divergent. The point is not that neurodivergent people cannot collaborate. Many do, and often quite well. The point is that continuous exposure, rapid transitions, uncertain turn-taking, persistent mediated presence, and reduced control over one's environment can come with a significantly higher neurological cost.

A system can be bearable and still be draining. It can be survivable and still be wrong.

The promise of resilience, the reality of flattening

There was another layer to this model that made the human cost sharper. This was not a junior-heavy team using mobbing primarily as a teaching tool. The baseline hiring expectation was seniority. People were generally expected to bring at least eight years of experience in their field before they would even be considered. In other words, this was a team composed, by design, of experienced professionals.

The justification for the model sounded reasonable on its face. No one engineer would become the sole holder of critical knowledge. The project, and by extension the client, would be protected against staffing turnover, internal reshuffling, and single points of failure. In theory, the whole team would rise together. Everyone would eventually know the entire system. The pace of individual specialization might be slower, though the collective resilience would be stronger.

There is a real organizational concern hiding inside that rationale. Brittle staffing models are dangerous and knowledge hoarding is dangerous. Teams do need resilience. Leaders do need to think beyond heroic individuals and single points of failure.

The trouble is that the operating model quietly treated experienced engineers less like distinct professionals and more like commodities or interchangeable bricks in a wall.

Once everyone was reduced to the generic category of "engineer," differences in domain background, technical depth, tool familiarity, workflow preferences, muscle memory, and accumulated craft were flattened into something the system preferred not to see.

That flattening is inefficient and ineffective. It is dehumanizing.

I am thinking here of my own experience. I am a vim user. I have decades of muscle memory there, and much of my background has been in systems-level work. The application in this environment, by contrast, was a custom enterprise Java application. I had not worked meaningfully in Java in roughly twenty-five years. Still, I was "an engineer" on the team, so the expectation was that I would participate on essentially equal terms with people who had been building Java applications in IntelliJ IDEA (an integrated development environment (IDE) specifically built for Java development) for years. I didn't have the tools or the libraries for doing the work installed on my computer.

That is a revealing detail.

The problem was not that I was incapable of learning. Senior engineers learn new domains all the time. The problem was that the system appeared to regard difference itself as a nuisance. It did not want to make careful distinctions between kinds of expertise, kinds of fluency, or kinds of contribution. It wanted a pool of high-end interchangeable labor that could be rotated through the machinery with minimal regard for where each person's strengths actually lived.

That assumption carries a human cost. It communicates that a person's real background, habits of thought, tools, and hard-won craft identity are secondary to the process. It also creates a subtle but persistent pressure to perform competence in ways that are misaligned with one's experience. A senior engineer who is legitimately senior may still be made to feel novice-like, not because the depth is absent, but because the model insists on uniformity in a context where uniformity is artificial.

This is one more reason I resist the easy language of "cross-functional collaboration" when it is used carelessly. Cross-training can be good. Shared understanding can be good. Reducing single points of failure can be good.

Those aims become harmful when the system forgets that people are not fungible.

I also want to add that the project was brand new to the organization. The time between contract award and kickoff was extremely short. The team was brought together quickly based on who had relevant experience and, more importantly, who could be spared. Given the time, they could have made different staffing decisions.

When Collaboration Becomes Continuous Managed Availability

Part 1

Joel Spolsky's eighth item in the Joel Test asked a deceptively simple question: do programmers have quiet working conditions?

In 2000, that question was often about cubicles, doors, offices, and noise. In 2026, the question runs deeper. The modern threat to serious engineering work is not only a loud office or an open floor plan. It is the environment in which a developer is never truly allowed to disappear into the work at all.

Some organizations have recreated the worst features of the noisy office through remote work. They have taken a medium that could have supported autonomy, flexibility, asynchronous collaboration, and thoughtful silence, then used it to impose continuous shared presence instead. The language used to describe that arrangement is often upbeat and reassuring: collaboration, alignment, pairing, mobbing, teamwork, support. The lived experience can be something else entirely.

A more accurate phrase for some of these environments is continuous managed availability.

That phrase may sound severe, though I think it is precise. The problem is not collaboration itself. Pairing can be valuable. Mobbing can be valuable. Shared debugging can be valuable. Junior engineers and interns can learn a great deal by watching experienced people reason out loud. Hard migrations, incident response, tricky architectural changes, and unfamiliar codebases can absolutely benefit from intense synchronous work.

The trouble begins when a bounded technique becomes the default operating model for the whole day, every day.

I worked in one remote environment where teams were expected to remain on Zoom from the beginning of the workday to the end. The larger team was about forty-five people, though people were divided into smaller breakout rooms of roughly five to eight engineers working on related aspects of the same project. The working model was called "mobbing" which we later renamed "collaborative coding." One person acted as the driver. One acted as the navigator. The remaining participants primarily contributed through Zoom chat. The driver and navigator changed at regular intervals throughout the day according to a schedule set in advance, typically somewhere between every five to ten minutes.

On paper, that model may have looked efficient, modern, and highly collaborative. In practice, it created a very different experience. It did not merely invite collaboration. It required persistent social and cognitive availability. It treated uninterrupted co-presence as the default condition of engineering work.

That distinction matters.

A healthy collaborative culture says, "We will come together when it helps us think better, solve faster, or learn more."

An unhealthy one quietly shifts to, "You will remain available to the group at all times, and your body, attention, and private thought must fit around that requirement."

That is not a small shift in tone. It changes the moral and cognitive character of the work.

Quiet is not the point

Joel was right to care about quiet, though the word itself is too narrow for the problem many engineers face now.

A room can be quiet and still be hostile to concentration. A remote call can be orderly and still be neurologically expensive. The deeper issue is not just sound. It is whether the environment protects the fragile mental state required for serious engineering work.

Software development is not usually a sequence of tiny independent thoughts. Good engineering work requires the slow construction of an internal model. You have to hold the architecture, the flow of control, the data structures, the hidden assumptions, the edge cases, the naming choices, the recent failures, and the intention behind the change in your mind at the same time. That structure takes effort to build. Once built, it is easy to disrupt.

A noisy office can disrupt it. So can a casual interruption. So can an all-day collaborative environment in which you are never allowed to stop monitoring the room.

This is why the modern form of item eight should ask whether engineers are allowed to achieve sustained cognitive depth without chronic self-management, not ask merely whether programmers have quiet working conditions.

The phrase, "chronic self-management" is important.

Many people can survive difficult environments by compensating. They mask. They endure. They keep one eye on the chat. They mute and unmute. They smile through interruption. They work their meals and restroom breaks around the collaboration schedule. They monitor the clock so they will be ready for their next public role. They privately absorb the cost and the stress at their own personal expense.

From the outside, this may still look like productive participation. From the inside, it can feel like trying to carry water in your hands.

The hidden human cost

The first great cost of a mob-all-day model is depletion. It's not merely distraction.

When people describe environments like this, they often talk first about lost focus, and that is certainly part of the story. Focus matters. So does throughput. So does code quality. Those deserve their own treatment.

Before we even get there, though, there is a more basic truth: some forms of collaboration are exhausting in a way that traditional management language does not know how to describe.

A developer in an all-day Zoom collaboration model is doing far more than simply simply writing code and occasionally talking. That person is often doing several things at once:

• staying aware of the shared conversation
• tracking the code under discussion
• watching for Slack messages and side-channel input
• anticipating the next turn as driver or navigator
• managing tone and responsiveness
• deciding whether there is time for a quick break
• suppressing irritation when the work rhythm becomes unnatural
• trying to remain mentally ready while also attempting to think

That is far more than one small cognitive surcharge.

This is one reason many organizations misunderstand what they are asking of their engineers. The work is more than only the visible task on the screen; there is also the invisible labor required to remain continuously present, regulated, socially responsive, and contextually available.

That invisible labor becomes even more expensive for people who are on the ASD spectrum, who are highly sensitive, highly introverted, ADHD, or otherwise neurologically divergent. The point is not that neurodivergent people cannot collaborate. Many do, and often quite well. The point is that continuous exposure, rapid transitions, uncertain turn-taking, persistent mediated presence, and reduced control over one's environment can come with a significantly higher neurological cost.

A system can be bearable and still be draining. It can be survivable and still be wrong.

The promise of resilience, the reality of flattening

There was another layer to this model that made the human cost sharper. This was not a junior-heavy team using mobbing primarily as a teaching tool. The baseline hiring expectation was seniority. People were generally expected to bring at least eight years of experience in their field before they would even be considered. In other words, this was a team composed, by design, of experienced professionals.

The justification for the model sounded reasonable on its face. No one engineer would become the sole holder of critical knowledge. The project, and by extension the client, would be protected against staffing turnover, internal reshuffling, and single points of failure. In theory, the whole team would rise together. Everyone would eventually know the entire system. The pace of individual specialization might be slower, though the collective resilience would be stronger.

There is a real organizational concern hiding inside that rationale. Brittle staffing models are dangerous and knowledge hoarding is dangerous. Teams do need resilience. Leaders do need to think beyond heroic individuals and single points of failure.

The trouble is that the operating model quietly treated experienced engineers less like distinct professionals and more like commodities or interchangeable bricks in a wall.

Once everyone was reduced to the generic category of "engineer," differences in domain background, technical depth, tool familiarity, workflow preferences, muscle memory, and accumulated craft were flattened into something the system preferred not to see.

That flattening is inefficient and ineffective. It is dehumanizing.

I am thinking here of my own experience. I am a vim user. I have decades of muscle memory there, and much of my background has been in systems-level work. The application in this environment, by contrast, was a custom enterprise Java application. I had not worked meaningfully in Java in roughly twenty-five years. Still, I was "an engineer" on the team, so the expectation was that I would participate on essentially equal terms with people who had been building Java applications in IntelliJ IDEA (an integrated development environment (IDE) specifically built for Java development) for years. I didn't have the tools or the libraries for doing the work installed on my computer.

That is a revealing detail.

The problem was not that I was incapable of learning. Senior engineers learn new domains all the time. The problem was that the system appeared to regard difference itself as a nuisance. It did not want to make careful distinctions between kinds of expertise, kinds of fluency, or kinds of contribution. It wanted a pool of high-end interchangeable labor that could be rotated through the machinery with minimal regard for where each person's strengths actually lived.

That assumption carries a human cost. It communicates that a person's real background, habits of thought, tools, and hard-won craft identity are secondary to the process. It also creates a subtle but persistent pressure to perform competence in ways that are misaligned with one's experience. A senior engineer who is legitimately senior may still be made to feel novice-like, not because the depth is absent, but because the model insists on uniformity in a context where uniformity is artificial.

This is one more reason I resist the easy language of "cross-functional collaboration" when it is used carelessly. Cross-training can be good. Shared understanding can be good. Reducing single points of failure can be good.

Those aims become harmful when the system forgets that people are not fungible.

I also want to add that the project was brand new to the organization. The time between contract award and kickoff was extremely short. The team was brought together quickly based on who had relevant experience and, more importantly, who could be spared. Given the time, they could have made different staffing decisions.

Links

• Introduction
• Part 1: The Human Cost of Mob-All-Day Work