Tech people have a superpower. They can communicate without speaking, without being in the same room, or even via email or teams. They can communicate purely through their actions.
But this is not telepathy, this is no telekenesis.
I’m talking about PRs, infrastructure (as code) and tool configurations.
Tools and processes have become silent battlegrounds for the supremacy of ideas in our software engineering organisations. These levers are often our modern enterprise’s most insidious command and control mechanisms. Couple those with an aggressive workplace culture and sometimes you have a recipe for misery.
We Fixed That To Make Our Lives Easier
Walk into any software engineering department in the world and you’ll find a list of complaints. You also won’t have to go far to find them. Do any of these situations seem familiar?
- We didn’t like that you put stories into our backlog, so we stopped your access.
- You broke our CI, so we will ensure that we require extra signoffs on your PRs.
- Your build agents don’t have what we need to complete our work, so we created our own.
- Our DevOps team didn’t have time to deploy our changes so we had to do it ourselves.
- Getting access is slowing us down.
- Your mandatory patching broke my machine.
- This documentation is out of date.
The list of complaints goes on forever. And if you work in a healthy culture, these complaints could well be heard but will be worn lightly. They are seen as things that need to be fixed and will be fixed. You won’t necessarily see the same problems coming up again and again. Problems arise, they get solved and the whole organisation moves on.
However, in toxic organisations, these same complaints circulate endlessly. These repeating problems can become signals of doom. People become frustrated because things aren’t moving forwards.
Complaining as a Service
People love to help. But people also love to complain.
Why do we as IT people love to complain so much? What’s in it for us?
Let’s say we’ve built a CI pipeline with many tests. Recently, some tests have taken longer because of limitations in one piece of infrastructure. It needs a regular reboot, but no one has the relevant access to automate it. Someone has volunteered to restart that infrastructure whenever needed to get the tests to pass. This works for a few days, but then that person has a day off, and someone else needs to step in. When the first person returns from holiday, they forget to take this work over again. Friction is caused. Who’s responsibility actually is this?
Heat is generated when our social contracts break down. People forget things. People make mistakes. People plug gaps in the process.
In a socio-technical system, people are the lubricant. Lubricant occasionally needs changing.
We find release by complaining. Perhaps we complain ‘officially’ at the standup, or perhaps we get to do it unofficially in the form of gossip behind people’s backs. Either way, the frustration will find its way out. But unchecked, complaining leads to bitterness and team toxicity.
When you’re working in a socio-technical system – the people are the lubricant. If you’re experiencing a lot of friction then the lubricant regularly needs changing.
Passive Aggressive Enablement
Not everyone is blessed with the gift of giving respectful feedback and not everyone is very good at receiving criticism. In software development, often it seems you need a thick skin to stand criticism from others.
One of the most challenging aspects of working in technology, is finding acceptable ways of communicating. This can be ascribed to ‘workplace culture’ but for people who have to think deeply about technological solutions it seems too easy to just give everyone a pass on how they can interract at work.
If, for example, you have ever felt that:
- It’s hard to bring up subjects because you worry about how certain people will react.
- You’re avoiding (or dreading) meetings because of tension in the team.
- People do things which you consider aggressive but no-one else seems to be bothered about it.
- Repeated attempts to resolve conflict end up going around in circles.
Then perhaps it’s not you, it’s perhaps something else that’s going on with another team member or your team’s culture.
And sometimes, for any amount of reasons, a person just no longer is deemed to be a fit. If you read the excellent Dynamic Reteaming by Heidi Helfand, the chapter on Anti-patterns discusses the toxic team member:
“Maybe they were arrogant or verbally abusive. Maybe they were insulting or abrasive. Maybe they were passive-aggressive and hoarded information. These types of behaviours threaten the safety of others on the team and in the workplace in general. Feeling safe is tied to high performance.”
Heidi Helfand “Dynamic Reteaming”
Conversely it is often hard to bring up what you perceive to be problems with either code or with people without resorting to the easiest route which is using the tools. If you complain via PR, complain via mail or via chat you’re not really addressing the core issue. Sometimes it’s difficult to confront somone and have a conversation. And sometimes this is made harder due to experience, or perceived seniority or just personal preference, history and working style.
First Blame The System, Not The Person
What you can do is not to take it so personally.
The ‘culture’ is the set of social rules that govern our interactions. It is the norms which we as a group conform to. They are always changing and never written – if they are written then the rules will most likely be quite generic or out of date.
Therefore, just because you can’t get your change approved or your infra deployed, or your ticket looked at, this usually isn’t anything to do with either you or the person you think should fix the ticket. It’s the fault of the system you’re working in.
So first see if you can work with the system to make what you need happen. If the system doesn’t allow for it, perhaps it’s wrong?
You can challenge this system. Do it respectfully, do it with good intent and see where you can take your organisaton. This can be a very powerful way of improving work culture for everyone. By fixing systemic problems you hopefully make everyone’s life a little easier.
But Sometimes, It Is The Person
But bear in mind, again as Heidi Helfand says:
“It could be that something else is going on in their lives, and they are acting out at work because of that.”
While we all like to think that high-performing teams can be constructed and can last forever, in reality they are often simply fleeting arrangements, fortuitously coming together at the right time and dissipating as quickly as they arrive. Sometimes, the influence of a single person is enough to make or break a team, but it’s also clear that people change. Occasionally the very person who was responsible for the early success of a team can become the one that threatens their future success.