Open any capacity plan in any software company and read the column headers.
Resource. Allocation. FTE. Bandwidth. Headcount.
Not one of those words describes a person. They describe parts. Fuel. Pipe width. A count of heads, as if the rest of the body came free.
I'm a software engineer by training. I've built those spreadsheets. I've sat in the planning meeting and said "we need two more resources on payments" without hearing myself. Nobody in the room flinched, because everybody talks this way.
Thomas Erikson, the Swedish behaviourist behind Surrounded by Idiots, sat down with Debra and me on Corey-osity Unleashed and said something I keep coming back to. Most people are decent. Most people want to do a good job. Nobody walks into the office planning to wreck everything by five o'clock.
So why do so many of us lead as if we're managing a gearbox?
The words come first
Language sets the frame for every decision downstream. Call someone a resource and you start making resource decisions about them.
A resource is interchangeable. Swap one out, slot another in, same output. A resource has no bad week, no sick kid, no strong opinion about the architecture. A resource sits idle or sits busy, and idle is waste.
Run a team on those assumptions for a year and watch what happens. You move people between projects every quarter because the spreadsheet says the total adds up. You measure utilisation and call it productivity. You treat the engineer who knows the billing system inside out as one unit of capacity, same as the graduate who started on Monday.
None of this comes from malice. It comes from a model. And the model is wrong.
Psychologists have a name for this
Nick Haslam published a major review of dehumanisation in 2006. Other researchers have cited it thousands of times. He split it into two forms. One treats people as animals. The other treats people as objects or automata. He called the second form mechanistic dehumanisation.
Here's the part worth reading twice. Haslam argued dehumanisation isn't limited to war or hatred. It's an everyday social habit, rooted in ordinary thinking. You don't need contempt for someone to see them as a machine. You need a busy week and a spreadsheet.
Workplace researchers picked this up and ran with it. Gaëtane Caesens and Florence Stinglhamber at UCLouvain built a body of work on what they call organisational dehumanisation... the feeling, among staff, of being treated as a tool by the place they work.
Their findings aren't subtle.
- In a 2017 study of 1,209 employees, feeling dehumanised by the organisation sat between low support from the company and three bad outcomes: lower job satisfaction, more emotional exhaustion, and more psychosomatic strain.
- In a 2019 study of Belgian employees, organisational dehumanisation predicted emotional exhaustion, the core of burnout. Exhaustion in turn predicted worse health and stronger intentions to quit.
Burnout and attrition. The two problems every engineering leader complains about at every conference I've attended. The research points straight at how people feel they're being treated.
Machines don't share what they know
This next study should worry anyone running a tech team.
Researchers followed 245 employees in the telecoms sector across three points in time. Staff who felt dehumanised by their organisation reported more psychological distress. Distress, in turn, led to more knowledge hiding... deliberately keeping back knowledge a colleague asked for.
Think about what your team runs on. The undocumented reason the retry logic works. The customer who always breaks the import. The flaky test everyone ignores except the one person who knows why it fails on Tuesdays.
Treat people as parts and they'll start acting like parts. Parts don't volunteer context. Parts do the ticket in front of them and nothing more.
Fred Brooks warned us in 1975
Software people have known this for fifty years. We keep forgetting.
Fred Brooks wrote The Mythical Man-Month in 1975. The title is the joke. A "man-month" assumes people and time trade off cleanly, as if two engineers for three months equals six engineers for one. Brooks argued the trade only holds for work you split into pieces with no communication between the workers. Software doesn't work this way.
From the same book came Brooks's law: "Adding manpower to a late software project makes it later." New people need ramp-up time, and the experienced people stop to teach them. Communication channels multiply with every person you add. And some tasks don't divide at all. Brooks's own line: nine women don't make a baby in one month.
Brooks himself called his law an "outrageous oversimplification." Fair enough. The point stands anyway. The moment you treat engineers as fungible units, your plans stop matching reality.
Every late project I've watched get "more resources" thrown at it looked like this picture. Five people pointing. One person doing the work, now slower, because she's answering questions.
Different people, different fuel
Here's where Erikson's work earns its place. His colour model sorts behaviour into four broad styles: red, yellow, green and blue. In our conversation he described a room full of blue IT technicians, headphones on, staring at the wall. A cheerful "hello, Monday morning!" from an extroverted manager sends them running for the work-from-home option.
I'm not sure about this part: academic psychologists criticise personality typing tools like Erikson's colours and DISC for weak predictive evidence. I'm using the model as a prompt to notice differences, not as science about any one person.
You don't need a colour chart to get the underlying point. People differ. A machine runs the same no matter who operates it. People don't. One engineer does her best thinking in silence. Another needs to argue it out at a whiteboard. One wants the detail. Another wants the why and nothing else.
A machine-minded manager writes one process for everyone and calls it fair. A people-minded manager learns what each person needs and calls it the job.
The cost lands on the bottom line
My own research found 99.5% of survey respondents had worked for one or more types of bad boss. I don't think most of those bosses set out to be bad. I think a lot of them inherited a machine model of work and never questioned it. Erikson said the same thing in our conversation. Most poor managers try their best. Nobody trained them.
The machine model feels efficient. It isn't. You pay for it in exhaustion, in resignations, and in knowledge walking out the door inside the heads of people who stopped volunteering it months ago. I wrote about the hidden cost of bad leadership over on Step It Up HR, and this is one of its quietest forms.
What to do on Monday
You won't fix this with a values poster. Fix it with habits.
Change the words in your own documents
Go through your capacity plan, your roadmap deck and your Jira dashboards. Replace "resources" with names or with "people." Replace "FTE" with "engineers." It feels petty. It isn't. Every time you read a name, you remember a person sits behind it.
Stop measuring utilisation as if it were output
A machine at 100% utilisation is efficient. A person at 100% utilisation has no slack to help a colleague, fix the thing nobody asked them to fix, or think. Track outcomes instead.
Ask before you move someone
Before you shift an engineer between teams, have the conversation. What do they know which nobody else knows? What will they lose? What will the team lose? If you don't know the answer, you're moving a part, not a person.
Find out what each person runs on
Use your one-to-ones for this, not for status updates. I've written before about one-to-ones turning into status meetings. Ask what kind of work energises them and what drains them. Ask how they like to get feedback. Write it down. Use it.
Treat a late project as a people problem first
Before you add bodies to a late project, ask the people on it what's in the way. Often it's a decision nobody's made, a dependency nobody owns, or a person carrying too much. More heads won't fix any of those.
You lead people, not a gearbox
The language of machines crept into software leadership because our work happens on machines. Fine. The code runs on servers. The team doesn't.
Erikson's line stays with me. Most people want to do a good job. Your job is to stop getting in their way.
So open your capacity plan this week. Count how many times it says "resource." Then ask yourself... when did you last talk to each of those resources about something other than a ticket?