Resources are Resources
So why should it be… you and I call people this so awfully?

There is a popular view in organisations and organisational theory that it is ok to describe people as resources. Serious Scrum’s own John Clopton has challenged this view in the past, I’d like to add my voice to this subject, with inspiration from this tweet of Melissa Perri.
The view that it’s ok to view people as resources goes something like this:
“Employees are a company’s most valuable resource and it is right to think of them in this way, and certainly better than viewing them as a cost.” — ITProPortal.com
A company’s most valuable resource. There is an element of positivity in that sentence, but that is being generous. In reality it’s an inverted shit sandwich, two negatives surrounding a positive.
Viewing people as ‘costs’ would indeed be worse, but what kind of worldview is that? Doesn’t the view of people as costs lead us pretty quickly to some very dark places? What happens when we need to reduce these costs?
However, the ownership part of this view unsettles me the most. That little apostrophe tells me that the company considers employees to be theirs.
Johanna Rothman believes that “When managers think of people as resources, they stop thinking” and I tend to agree with that view. (Source). They certainly add distance between themselves and the individuals and interactions inside teams.
What defines resources?

Resources are finite, and can be used up, like a battery. People, on the other hand, are fragile, and require care. They can suffer from stress, and can burn out if they are treated poorly.
Resources are exchanged. People need time to get to know each other. Teams have cultures. It takes time to settle down.
Resources have a cost. They depreciate over time. People have value to bring If you appreciate them, they will create value.
Resources are owned. Do I really need to address this one?
Back to The ‘Resources View’
“The reason that employees are referred to as resources is because it is easier to make sense of a complex situation when you bring it down to abstract terms.”
“This is especially the case when changes arise: a new top priority, a key employee goes on leave, extreme weather delays a project, etc. When these things happen, you often must find resources or employees with specific skills to fill in the gaps. You have to manage your resources.” — MeisterPlan.com
Let’s consider the positive aspects of this view. First off, the drive to simplify is an excellent motivator. Simplicity is the ultimate sophistication, after all, and who are we to contradict Leonardo da Vinci?
In addition, the need to plan for changes that might affect a team’s ability to deliver is also essential. We need to keep up to date with our roadmap, what we are trying to achieve, and evaluate whether or not we have the people and skills to realise the objectives of that plan.
However, there is a downside to this definition that I believe outweighs these positive aspects. When we treat people in an abstract way like this, we risk de-humanising them and removing people management from our view of work.
To put it another way, by viewing people or teams as abstract resources that can be moved around without consequence, we risk over-simplification. In ‘The Mythical Man-Month’, Fred Brooks posits that “adding manpower to a late software project makes it later.” (Source) People need time to get up to speed with complex contexts, and no two software development teams share an identical context.
Bonds need to be made in a team. People are naturally complex, and often downright irrational. We cannot ignore the teaming aspect of work, or the bonds between people that drive how well teams work together.
The need to identify gaps in capacity and the team’s ability to deliver is essential too. However, this definition implies that this activity should happen in a top-down manner. In other words, managers have a ‘divine right’ to tell people what to do.
I can relate to this belief, particularly when simplification is also considered. Life would indeed be less complex if we could just move cell values (people) into different columns (teams) each time we needed to solve a problem. However, these decisions have real world implications that are not abstract and simple. They require management, which somebody somewhere will need time for, and that will also have a knock-on effect on the team’s ability to deliver value.
Here’s a thought: rather than decisions on changes in team composition happening in management meetings or in isolation by individuals, how about involving teams in planning, and discussing as a group what we all need to achieve that plan?
Here’s a kicker from the same source above:
“I would never recommend calling a person a resource to their face.” — MeisterPlan.com
Indeed.
Let’s think about the alternative view for a moment.
Imagine working in a team or an organisation where everyone is a person. Ben Linders’ positive outlook suggests that when managers stop referring to people as resources, reciprocity can be expected: “managers can expect to be treated by their employees as people too.” (Source).
Individuals and Interactions
Peter Schein believes that personization is an important behaviour of leaders when instilling a positive culture in an organisation. “Modern leadership models can be complemented with a more personal relational emphasis if they are to be relevant to an emerging cohort of modern leaders.” (Source)

Bringing it back to Scrum for a moment:
“The essence of Scrum is a small team of people.” — The Scrum Guide
Scrum teams address complex adaptive problems. In order to do this, the individuals in teams need time to learn their context, and how to interact with each other in productive ways. In other words, the ability of a Scrum Team to deliver is dependent on people. They need to personize each other day to day.
When we reduce these interactions to the level of resources, we risk under-estimating complexity.








