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.

Comments

Popular posts from this blog

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.

Have You Ever Produced Negative Value in a System!?

As developers we encourage our product owners to order the priority of their backlog in order of value. However, every time a new feature is implemented by a development team, there is a certain degree of risk associated with the introduction of that new code. Namely, risk of breaking another part of the product and maintenance cost. When a development team pulls in a new feature to implement there is a certain acceptance of this risk. In many cases, the risks that arise due to additional code complexity doesn't justify the value added by the new feature itself, so the development team can start implementing it.

Are there scenarios where the value added to a software product can be negative though?

I Don't Know

Many people who come from command and control working environments have a very limited circle of safety. This maybe because their suggestions have been discarded rudely, being treated poorly, or always fearing for their job. They do not suggest improvements and are often too scared to ask for help.