🗓️ 2020-08-02
⏲️ Reading time: 5 minutes and 31 seconds.
In today’s workplace, a lot of emphasis is placed on the wellbeing of workers. In fact, workers are not supposed to be called workers. Resources are people, people are participants.
When this kind of cultural shift is applied across the social spectrum of an organisation, the effects are widespread - not all of them are the expected outcomes of inspiration, motivation, equality, safety.
There are negative effects too, dangerous effects to productivity.
When the focus shifts to the people of an organisation, focus is shifting away from the customer. Losing sight of the customer will cause a fragmentation of the shared objective: delivering customer value.
For a participant to feel valued, it is simply not enough to tell them so. In movies, there is a saying. “Don’t tell the audience, show the audience”.
By telling participants they are valued, there is a risk that those very people who you are trying to reach will in fact disengage. When the message is overtly stated there is a hollowness to it - and sensitive people will detect (or infer) that it is an attempt to reassure, rather than any kind of actual cultural movement.
Kindness, supportiveness - “all that hippy stuff” (to quote Elizabeth Hendrickson) do not, alone, convey the whole message. It is not enough to simply say to the employees of an organisation that they are valued. The question arises, “What part of me is valued?” - to work in an organisation that will reimburse you for a desk and chair is nice. But when your opinions are ignored, you don’t feel safe to deliver bad news, there’s no real collaborative connection with the other members of your team … when your PO is actually the “boss” and every work item you deliver is late, buggy, or both it’s pretty tough to feel valued.
Combating this descent into self-worth depreciation is actually something that can be easily achieved. It simply means following through on the message. Organising ways of working that treat team members as the highly trained, highly skilled, creative and hard-working people that they are.
Even the most junior members of a team ought to have a voice. Even when those team members raise issues that are “wrong” or ask questions that are years behind other members of the team is not cause for talking down to them, patronising them.
When someone is late with an item of work they thought would ship earlier, it is not something that should be used to make them feel uncomfortable. It is actually a problem with the ways of working. People are not always wired up to take on work all alone, indeed a lot of people work better when in collaboration with others. High-bandwidth communication and keyboard-switching such as is seen with Pair Programming is an effective way to raise quality standards, build stronger knowledge across the whole team, and allow people to relax and get to know one another at work.
Pair programming is weird. It either works, or it doesn’t work.
In all the cases I have seen where it doesn’t work, it is because there is nobody around who wants to make it work. It is because the pair not only feel unempowered in this situation, they actually have no knowledge of the concepts at play, have not had any exposure beyond the (all too) common “you know, pair up on this and work it out”.
The pair that doesn’t work is the one where one programmer ends up doing all the typing and the other feels increasingly disengaged, eventually pulling out their own laptop and doing something else.
So to set up a pair for success, they will need some support and time to prepare for their pairing. Some time to read about it, a few failed sessions, even some coaching. It will be worth it.
Pairs that work are those where the programmers (or at least one of them) has seen it before, read about it before, participated before.
When a pairing succeeds it is because the participants are comfortable to match pace. If there is a super-fast programmer paired with a not-so-super-fast programmer, they slow to the speed of the not-so-fast programmer naturally, so as to maintain the integrity of the pairing.
Sometimes the super-fast programmer will whip up a test for the slower programmer, and pass the keyboard. The slower programmer might apologise for being slower but the pair that works is one where the apology is accepted but not necessary. Both programmers are not just producing work here. They are investing in the growth and knowledge of the whole team.
It’s a long-game strategy.
When retrospectives are held, it is vital that there are clear definitions of what a retro-item ought to be. Focus on “team work” and congratulatory messages are not actually what makes people feel valued. This may be difficult to digest initially, even counter-intuitive especially given the “people not resources” culture in vogue - but for people to feel valued the one thing that will carry that message all the way home, every time is listening.
As long as a retro item is focused on delivery of customer value, it is appropriate to attempt to implement the person’s suggestion. Give the suggestion some time to succeed or fail, so that all may learn from it.
There will be times when more senior team members will be tempted to scoff at the suggestions of more junior members, but with the benefit of tighter feedback loops these suggestions can be implemented in earnest and their effects observed, safely.
There is nothing wrong with suggesting something that will fail. There is always the possibility that a suggestion that appears on the surface to be naive and uninformed will actually turn out to succeed even if those who are affected by the suggestion find a deeper inspiration from it and come up with something truly beneficial in response.
These types of experiments, conducted by the team, will only serve to grow their collective experience. Of course, this works best with long-lived teams but in the case of teams with some turnover the knowledge-waste will at some point become the signal to management that more attention needs to be paid to the length of a given team’s grouping.
If it is truly safe to fail then each team member will feel more than just valued they will feel trusted. A person who feels trusted is less likely to consider themselves unempowered, less likely to question their own self-worth, and more likely to love their work and their workplace.
When management trusts the teams to tend towards success, failures become milestones on that team’s path to success. As more and more successful improvements are made, the team is attracted to an equilibrium whereby the flow of work is increasingly unhindered, until value is being released at a near-optimal rate.
When the team is given the clear objective of optimising for delivery of customer value and each team member is truly valued and trusted in word and in deed, the delight they feel as they produce customer value will be transmitted, in kind, to the customer.