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

Additional patterns that support the same values

The three ideas I mentioned are the core of what I would recommend. There are also several supporting patterns that reinforce the same values.

Use bounded collaboration windows

Pairing, mobbing, and shared working sessions can be excellent tools when they are bounded, purposeful, and chosen for the kind of work at hand.

There are situations where intense synchronous collaboration is exactly the right tool:

• onboarding
• incident response
• shared debugging
• risky migrations
• hard architectural knots
• knowledge transfer in fragile areas of the codebase
• moments when a team genuinely needs to think together in real time

The problem begins when the tool becomes the atmosphere.

A strong team treats these methods as techniques, not as the air everyone must breathe all day long. They are invoked with intention. They have a purpose. They have a natural end. People are allowed to return to solitary or asynchronous work once the collaborative value has been extracted.

What this looks like in practice:

• time-box pairing or mobbing sessions
• name the purpose at the start: onboarding, debugging, design spike, incident response, knowledge transfer
• end the session when the purpose has been served instead of defaulting into all-day co-presence
• ask deliberately, "Should this stay collaborative, or has it become better suited to individual work?"

Protect specialist leverage

One of the most expensive organizational mistakes is flattening distinct professionals into a generic pool of "engineers" and pretending that equal participation in the same workflow is the same thing as fair or effective contribution.

It is not.

A mature team spreads knowledge without erasing specialization.

Healthy teams ask better questions:

• where does this person's experience create disproportionate value?
• what kind of work should they shape, review, challenge, or guide?
• what needs to be shared broadly?
• what should remain role-sensitive because the quality of judgment matters?

What this looks like in practice:

• identify where each senior contributor creates the most leverage.
• use specialists not only as implementation labor, but as reviewers, designers, mentors, and risk spotters
• reduce single points of failure by sharing context intentionally, not by pretending every role is identical
• distinguish between "everyone should understand this at a useful level" and "everyone should perform this role interchangeably."

Normalize asynchronous-first questions

Another practical shift that helps enormously is simple: non-urgent questions should default to asynchronous channels rather than live interruption.

What this looks like in practice:

• encourage people to write down non-urgent questions instead of turning immediately to live interruption
• prefer channels or threads for questions others may also benefit from seeing
• normalize language such as, "Please send that asynchronously unless it is urgent," and, "Can this wait until my focus block ends?"
• teach teams that urgency should be justified rather than assumed

Create protected focus blocks

If deep work is genuinely important to engineering quality, then it must be protected as a real production asset rather than treated as a private preference.

What this looks like in practice:

• create no-meeting windows, focus blocks, or clearly defended periods of low interruption
• make responsiveness expectations explicit so people are not punished for concentrating
• treat attention as scarce and valuable, not as a common pool anyone may draw from without cost

Tell the truth about scale

Some collaboration problems are really scaling problems in disguise.

Once a project gets large enough, a "team meeting" can stop functioning like a team conversation and start functioning like a small audience event. At that size, being heard is no longer simply a matter of willingness. It becomes a function of timing, confidence, interruption tolerance, verbal compression, and comfort taking airtime in a crowd.

There may be no perfect answer. There are still many bad ones.

What this looks like in practice:

• stop pretending every large ceremony is naturally representative
• Use smaller forums, better synthesis paths, and asynchronous collection of input when the room becomes too large for genuine conversation
• Recognize that quieter people are often the first to disappear from the signal when scale is ignored

Better systems are not softer. They are more honest.

There is sometimes a fear that if organizations move away from extractive, high-visibility collaboration models, they will drift into chaos, weak accountability, isolation, or sluggishness.

That fear misunderstands the alternative.

A better system is not one that asks less of people. It is one that asks truer things of them.

It is stricter about:

• not wasting attention
• not using expensive talent generically
• making room for truthful feedback
• distinguishing urgency from convenience
• protecting focus as a real production asset
• designing ceremonies and collaboration structures that scale honestly instead of pretending every large meeting is a genuine team conversation
• refusing to buy managerial reassurance at the cost of human diminishment.

That is not softer. It is more disciplined in the right places.

What a balanced organization should be able to say

If I were to state the values plainly for an organization, team, or client, I would say something like this:

We believe:

• the client deserves excellent service
• excellent service depends in large part on whether the organization has created conditions in which people can contribute from a place of strength, truthfulness, and sustained investment
• retention matters because people matter and because strong organizations do not casually waste scarce talent
• fulfilling work matters because people do better work when they are able to bring something real of themselves to it
• collaboration should increase value, not erase identity
• a strong organization serves those who serve within it

We do not believe:

• people are disposable
• titles make people interchangeable
• that the needs of the client justify treating the people doing the work as though their bodies, minds, and histories were irrelevant

These are the kinds of value statements I would want leadership to mean, not merely display.

Item 8, rewritten for 2026

If I were rewriting Joel's eighth item now, I would make it something like this:

Do engineers have working conditions that protect concentration, respect embodiment and neurological diversity, and provide intentional pathways for collaboration without turning every workday into continuous managed availability?

That is the question I would want organizations to ask.

Not because quiet is quaint. Not because respect is a slogan. Not because collaboration is bad.

Rather, because software is built by people, and people do their best work when they are supported strongly enough to think clearly, speak honestly, contribute from their real strengths, and remain invested in the teams and organizations they are helping to hold up.

A team that understands that will not collaborate less.

It will collaborate better.

Posts in this Series

1. Collaboration and Continuous Availability (Introduction)
2. The Human Cost of Mobbing All Day Work (Part 1)
3. The Human Cost of Mobbing All Day Work (Part 2)
4. The Human Cost of Mobbing All Day Work (Part 3)
5. The Human Cost of Mobbing All Day Work (Part 4)
6. The Human Cost of Mobbing All Day Work (Part 5)
7. The Human Cost of Mobbing All Day Work (Part 6)