People are not Resources

In the dynamic and ever-evolving field of software engineering, the language we use to describe our teams and colleagues can have a profound impact on the workplace culture and the way we perceive each other. One term that has been prevalent in the industry but is increasingly under scrutiny is "resources" when referring to software engineers. In this blog post, we will explore why this terminology can be demeaning to some degree and suggest alternative ways to frame the conversation.

I first wrote a post on this topic way back in 2014. Having misplaced that post in my latest platform change, I decided to write about it again, as it's an unfortunately common problem.

What is a 'resource'?

I need to schedule my resources.

We don't have enough resources, we need more bodies.

Which resources are working on that?

I think we've all heard things like this before. I've worked for companies that actively avoid this type of language, and that's fantastic. Unfortunately, that's not always the case. This is incredibly offensive, to say the least. It implies that despite being educated, experienced, and passionate, engineers are:

• on the same level as 'materials'
• as disposable as a paper clip
• identical in skills, knowledge, and abilities
• boundlessly interchangeable and replaceable
• little more than numbers on a balance sheet

Obviously, this is inaccurate.

There is a lot written about the sociological structure of engineering teams, and that's far beyond the scope of this post, however, it should be apparent to anyone who has worked in a development environment, that the above statements are 100% false. So, why is this so common?

When thinking about why (mostly) managers use this word, the best reason I can think of is that it makes it easier to change the lives of their coworkers. I mean, it's much nicer to say you're "reallocating a resource" rather than, moving someone off a project or team. It's hard to fault someone for that. I think it comes from an approach to simplify the engineering process. It's a broken approach that basically has people trying to think of engineering like a factory production line. Analysts and Project Managers stuff requirements in one end, and engineers are in the middle making the 'goods', which are then sent to 'testers', or 'test resources' who allow a production quality product to spit out the other end.

This type of environment means your engineers are simply 'resources'; universal units of man-power. It suggests that the more 'resources' you assign to a project, the faster the work will be completed. This may be very true in a factory. If three people (or machines?) packaging frozen pizzas can package 3000 pizzas per hour, it should be reasonable to expect that six people could package 6000 pizzas per hour, right? Probably. So, the same is true of software engineering, right? Two 'resources' can finish it in two weeks, so let's just stick two more 'resources' on it and get it finished in one week. Problem solved! Not exactly.

The Dehumanizing Effect

At its core, referring to software engineers as "resources" reduces them to mere tools or commodities, akin to interchangeable cogs in a machine. This dehumanization can have several negative consequences within an organization:

1. Diminished Morale

When engineers are labelled as resources, it can lead to a sense of depersonalization and a feeling that their contributions are not fully recognized or valued. This can erode morale and motivation over time.

2. Inhibited Creativity

Creativity and innovation thrive in environments where individuals feel respected and empowered. Treating engineers as resources can stifle their creative potential, as they may feel constrained by a role that does not acknowledge their unique skills and perspectives.

3. Reduced Productivity

A workforce that feels dehumanized is less likely to be engaged and committed to their work. This can lead to decreased productivity and potentially high turnover rates, as engineers seek environments where they feel more appreciated.

Alternatives to Consider

So, what can we use instead of "resources" when referring to the talented individuals who drive software engineering? Here are several alternatives to consider:

1. Team Members

By referring to your software engineers as "team members," you emphasize their active participation and collaboration within your project. This term fosters a sense of unity and shared goals.

2. Colleagues or Peers

Using terms like "colleagues" or "peers" underscores the equal footing on which everyone stands within the team. It promotes camaraderie and mutual respect among team members.

3. Talent

Recognize the exceptional skills and expertise of your software engineers by referring to them as "talent." This term not only acknowledges their value but also encourages them to continue developing their abilities.

4. Professionals

Describing your software engineers as "professionals" emphasizes their commitment to their craft and crucial role within the organization. It highlights their dedication to maintaining high standards.

5. Experts

If your team members possess specialized knowledge in certain areas, calling them "experts" showcases their proficiency and the invaluable insights they bring to the table.'

6. Staff

"Staff" is a straightforward and inclusive term that encompasses all members of your software engineering team. It highlights their integral role in the organization and their contributions to its success.

The Impact of Language

The choice of language in the workplace is not a trivial matter. Our words shape our attitudes, interactions, and even our thought processes. By avoiding the term "resources" and opting for more respectful and inclusive language, we can create a workplace culture that fosters positivity, collaboration, and innovation.

Conclusion

In conclusion, it's time for the software engineering community to finally rethink the use of the term "resources" when referring to the talented individuals who make up our teams. These professionals are not interchangeable, and their contributions go beyond mere resource allocation. By using language that acknowledges their humanity, skills, and unique gifts, such as "team members," "colleagues," or "professionals," we can create a more positive and empowering work environment. Words matter, and it's crucial to use language that reflects the value and respect we have for our colleagues in the world of software engineering.