Skip to main content

People or Resources? Let's Be Honest With Ourselves

I've never liked it when people get referred to as resources. Especially when it's thrown around in front of the people themselves. Chairs, tables, capital, and computing power. These are resources, not people.

Nevertheless, a change of language is a good place to start.

A danger exists in any organisation where people may be abstracted away from their leaders, in these scenarios, it's easy to see people as resources or see people as a composition of their attributes be they: technology strengths, experience, height, weight and/or salary band.

Seeing people as a collection of their attributes or giving precedence to defining teams in terms of their numbers are signs that even though a change of language has occurred, a change of thought has not.

In organisations where improvement has started and language has changed, there can be a perception of a large change, when in reality, not much change has occurred. There are scenarios where if this occurs certain behaviours can be encouraged in order to shift mind-set in addition to changing language.

Below are some things to integrate into your software development teams that may help you contribute to a more fulfilling culture inside your organisations:

Increase one-on-one chats

Having a channel of one-on-one catch-ups outside of the usual delivery ceremonies enables relationships to be built between people. Building relationships allows for greater trust, which then allows for better functioning teams. Whilst I don't like putting a number on this, I would say monthly one-on-ones with each direct team member is a good place to start.

Monday 'how was your weekend' score during stand-up

Not all weekends are nice and happy. A lot of the time they're sad, tiring, or something unexpected has happened. One of the techniques I've seen work really well is getting team members to give a 1-5 score (5 being the best) of their weekend during their Monday stand-up. Team members don't say 'why', they gave a score, they simply give a score. The thinking behind this is that it helps team members have greater empathy with others in order to adjust communication appropriately. For example: Team members may not be as direct on pull requests by members who've had a bad weekend.

Regular team lunches

There's a reason why world leaders who don't like each other, meet up over a meal. There's something about food that makes people understand each other better and thus be more agreeable. In the end, it is a sign of a strong team that can have rigid technical discussions but still be able to have lunch together as a team. Likewise, it's good that a leader has lunch with their team. This is not only good for leaders but members. In the end, a leader is a human as well, with their own unique weaknesses, strengths, biases, and experiences.

In summary, a change of language is important, however, if people are still viewed as resources, then there is still plenty of room to improve. People are not a collection of their attributes nor are they a number as part of a team. Every person is a unique individual with their own weaknesses and strengths, experiences, and temperament. In order to really drive positive cultural change, organisations must not only change their language but also encourage understanding and empathy within teams.


Popular posts from this blog

My first time speaking at a conference

Since time immemorial we humans have valued the art of public speaking. Today, I want to share with you my experiences in speaking at conferences for the first time. Recently, I spoke at both DDD Melbourne and DDD Perth. Both of which were positive experiences that I learnt a lot in.

from zero to production in eighty days

When I mean zero, I literally mean zero. A brand new project, a PO that's new to IT, no existing processes in place and a small team of four including myself and the PO.

The departmental organisation we were working for doesn't have any developers, scrum masters, product owners working for them. Everything they did was either done by another department or outsourced completely.

This is a story how we went from zero to production in eighty days.

Context and agile practices

At times we have competing responsibilities - ship code or don't ship it because of a small edge case bug; put pressure on our team or make the business happy; coach our friends or write code.

This is a normal part of our everyday professional lives, and it's important to strike a balance that will help us in the future, but also deliver in the short-term.