People Are Not a Utility
On the Myth of Human Resources
This enchiridion entry follows on from the following articles and stories:
Humans are not Resources
Sometimes there is a peculiar cruelty in politeness. No one shouts when they call you a “resource.” No one sneers. No one cracks a whip.
The term arrives gently, laminated in HR slides and capacity planning spreadsheets. It is spoken in the same tone one might use to discuss office chairs or cloud subscriptions.
“We’re a little tight on resources.”
“We need to utilise our resources better.”
“Are you fully allocated?”
And somewhere between the third quarterly planning session and the seventh sprint review, you realise something unsettling: you are being discussed in the same grammatical category as electricity.
This is not accidental, it is an inheritance.
The industrial revolution did not merely give us factories to be used as metaphors; it gave us a grammar. In that grammar, inputs become outputs, labour becomes throughput, and time becomes fuel. The moral good is efficiency. The moral failure is waste.
And if a machine runs hot, you service it. If a human runs hot, you call it high performance.
In software development—particularly in serious, regulated, respectable environments—the factory metaphor survives under softer lighting. We have kanban boards instead of conveyor belts, CI pipelines instead of smokestacks, dashboards instead of foremen. But the logic remains familiar: maximise utilisation, minimise idle time, optimise flow.
Utilisation…
There is a quiet horror in that word. It assumes that a person not currently producing measurable output is waste. It leaves little room for thinking, recovering, wandering, pairing, mobbing, reflecting, grieving, or learning.
And yet software is not steel. It is not wheat. It is not petrol. It is shared cognition rendered executable and, ideally, valuable.
It is the most human of industrial artefacts. It emerges from conversation, from misunderstanding slowly clarified, from insight that arrives unannounced during a walk, from the friction of two minds pairing over a problem neither could solve alone.
To treat that process as extractive is to confuse combustion with cultivation.
The virtue of “be useful” is deeply embedded in us. It is the anthem of the diligent. It is what we tell our children. It is what we whisper to ourselves when we are anxious about our place in the team. Usefulness promises security. It promises belonging.
But detached from habitat, usefulness becomes a tyrant.
It persuades the bereaved engineer to return too soon because “the team needs me.” It convinces the burnt-out lead to push through another quarter because “we can’t slip now.” It frames rest as indulgence and reflection as delay. It erodes the courage to say, “We need to slow down.”
This is not villainy. It is metaphor gone feral.
When we adopt the factory lens, people become interchangeable components in a throughput machine. When we adopt a habitat lens, something different happens. We see teams not as pipelines but as ecosystems. We recognise that resilience comes from diversity, that recovery is seasonal, that learning requires slack, and that flourishing—not mere output—is the foundation of durable excellence.
The factory asks: “How do we get more from them?”
The habitat asks: “How do we design an environment in which they thrive?”
The former extracts. The latter cultivates. And forests, as it happens, outlive, and arguably outperform, factories.
A person is not a resource to be utilised, but a participant in a habitat to be tended.
The “human resource” metaphor persists because it simplifies management:
It aligns neatly with financial accounting.
It enables forecasting and allocation.
It reduces complexity to quantifiable units.
It supports narratives of control.
But software development is not mechanical production. It is collaborative cognition towards value.
Cognitive work requires:
Psychological safety
Shared understanding
Time for reflection
Social synchrony
Recovery cycles
Extraction logic undermines all of these. When we optimise for utilisation:
Slack disappears.
Learning becomes secondary.
Pairing appears inefficient.
Recovery feels indulgent.
Burnout masquerades as commitment.
In contrast, habitat thinking reframes the system itself as the object of stewardship. The team is not fuel for the work; the work is shaped by the conditions of the team.
The difference is moral as much as operational. In the utility framing, people serve the system. In the habitat framing, the system exists to enable people to flourish while achieving purpose.
Some practices to consider
Protect Slack as an Asset — Idle time is not waste; it is where insight incubates.
Design for Pairing and Mobbing — Shared cognition reduces fragility. Knowledge diffused is resilience gained and, often, flow improved.
Normalise Recovery — Seasonality applies to humans. Recovery is valuable, not optional.
Reward Stewardship — Recognise behaviours that improve the environment: documentation, mentoring, context-sharing.
Make Cognitive Debt Visible — Track friction, confusion, and fatigue as seriously as technical defects.
Shift Language, Shift Understanding — Language shapes design. Consider replacing:
“Resources” with “people.”
“Utilisation” with “capacity.”
“Allocation” with “commitment.”
Some things to avoid
Romanticising habitat thinking while still measuring only throughput.
Treating “wellbeing” as a perk rather than a valuable, structural design choice.
Allowing urgency narratives to override recovery rhythms.
Assuming flourishing reduces performance (the evidence suggests the opposite).
Some signs You’ve Slipped Back into the Factory
You praise overwork as dedication.
You equate busyness with value.
You fill every gap in the calendar.
Pairing is discouraged because “two people on one ticket is inefficient.”
Engineers apologise for taking leave.
Here’s an example. Two teams face a regulatory deadline.
Factory team: Maximises individual ticket throughput. Cuts pairing. Cancels retros. Delivers on time. Loses two engineers within six months. Knowledge fragments. Velocity declines.
Habitat team: Maintains pairing. Preserves retros. Limits work in progress. Negotiates scope instead of sacrificing recovery. Delivers slightly later. Retains staff. Improves system clarity. Handles next deadline with less stress, less interruption, and with confidence.
Short-term optics favour the factory. Long-term viability favours the forest.
You can extract effort, but you must cultivate understanding. One burns out. The other grows roots.
If software is shared cognition made executable and valuable, then the moral responsibility of leadership is not to maximise utilisation, but to design habitats in which minds can flourish.
Because it turns out that flourishing, unlike utilisation, compounds.
Some Further Reading
Matthew Skelton & Manuel Pais on Team Topologies
Cal Newport on Deep Work
Shoshana Zuboff on Extraction Systems
Robin Wall Kimmerer on ecological reciprocity
Richard P. Gabriel on software engineering as a habitat