Feb 2, 2022
TL;DR Thoughts and reasons behind dysfunctional software engineering teams.
TL;DR
We have all been there, or maybe some of you are there right now. It’s OK. In my experience, being a part of a dysfunctional team is a vital lesson we all need to go through at some point. Of course, we all wish to be a part of a great team, but we need the experience of being in a bad one to get some perspective and comparison by contrast. Only then can we see and understand what is happening around us and make a change or seek something better if deemed necessary.
What are the most common traits of a dysfunctional team?
This is definitely not a complete list of possibilities. Still, I think these are some of the most common things we can find within software engineering organisations or around them.
- Believers in “self-commenting code”.
- Code review drama.
- Nobody questions the status quo.
- No bond with your boss.
- Too many cooks in the kitchen for every single thing.
- Layers and layers of useless managers.
- Backlog clusterfuck.
- The release process is only theoretical.
- Product planning is apparently against “agile”.
- Team balance doesn’t exist.
- Glorification of overworking.
- Blame culture and silos.
- Last-minute vacations (unexpected absence is common).
- Tasks & tickets are as clear as Covid lockdown rules.
- Your Slack chanelofobia becomes a real thing.
- Only key players are allowed to participate in discussions.
- The feedback loop is the thing when you hear yourself on Zoom calls.
- Trust no one!
Now… the fact some of these things you might already find in the place you work at that doesn’t automatically means you should run away. It’s worth considering options and trying to fix and change things first. If you scan the list and find that 50% applies to you … now you can RUN!
Focus on the signs, first.
Let’s dig a little more into each item from the above list.
Believers in “self-commenting code”.
“I write such amazing, clear and easy to understand code that any comments are not necessary” — That’s just bullshit, which is usually coming from the most senior engineers who should lead by example. It’s a sign of more than what the title says. It’s a whole attitude towards of working in teams where key people usually hoard the knowledge and assume everybody should be on their level. You will find a correlation between that and lack of documentation, subgroups in teams and some kind of ‘engineering bullying” within an organisation, followed by poor testing and no attention to details (or over-focus only on details).
Code review drama.
If there are many divas, ninjas or other types of gurus whose ego is being hurt by someone daring to comment on their code negatively — your team has a problem. A good culture encourages everybody to participate in PRs, even (or especially) juniors and new-joiners. This should be part of their learning curve and an ego-balancing act for seniors up there. Of course, there are certain situations where PRs are not needed, but it’s a good habit to always do them. How PRs are executed, their comments and tone say a lot about respect in the team.
Nobody questions the status quo.
Many things are generally “bad” in your team, and nobody challenges them. From working teams, through planning, execution, writing code, quality, scruffy releases and lack of any sense of responsibility or ownership. People see a lot of areas where things could be better and often discuss (or joke about) them behind the scenes. Still, nobody publicly takes the initiative to change anything. When they do, it all comes down to the classics like “why change it if it’s working” or maybe “we’ve been doing like that for years”.
No real bond with your boss — 1–1s, feedback, growth plan, help.
I wrote about it a lot, and you can read in one of my other posts (link below), but the bottom line is — if you have no 1–1s with your boss, or maybe they are simply a waste of time, it’s probably one of the best signs some serious changes are needed.
Too many cooks in the kitchen for every single thing.
This moment, when you want to solve a problem and just learnt that too many people want to be involved on a particular topic. Yet, nobody wants to make any decision and take responsibility. What should take a few days to sort out, takes weeks, if not months. If you ever dreamed of wasting an enormous amount of time on politics, you would probably have chosen a different career… politician sounds good, right?
Layers and layers of useless managers.
And that usually means program managers, product managers, scrum masters, or delivery managers. Maybe an engineering manager involved, with QA manager lurking behind the scenes. A solid team (to simplify) need engineers, designer, product owner… that’s all. Of course, there are rare situations when someone else will get involved, but that should be an exception, not a rule.
Backlog clusterfuck.
Ideally, you should not have a backlog where all random stuff from devs is being put to “work on later”. If you do, it’s not bad. At least you have it. Now, if this backlog has tickets over 1-year-old (or worse, like 3–4 years) and 1000s of them, that’s a good sign things are not going well. You could delete the whole board, and the only thing you would hear is, “finally, someone did that!”. If it’s not being worked on, why it’s even there? This often happens in feature-obsessed organisations.
Release process is only theoretical.
Releases are crucial and should be supported by solid release pipelines to push the code live through all stages. It could be a CD, which is a good sign, but not always. Every release process should be adequately described in steps and responsibilities, including extra testing and post-live checks. Every engineer and non-engineer should know what is essential and understand it. Things are not right if engineers are not allowed to push code live, and this task lies behind a massive wall of paperwork, likely in some DevOps group.
Product planning is apparently against “agile”.
Engineers can’t deliver quality and optimal processes if they see only a week or maybe 2-weeks ahead. That’s not engineering. That’s just “code typing”. Nothing can be predicted, and the product itself can’t be future-proof if people responsible for creating it only have limited visibility into the future. Much could be optimised and done better if only teams had some high-level understanding of what was coming. Product teams need to stop making shit up as they go and always finding excuses like “we need to be agile, we can’t predict future, things change”… bullshit, even if the company is only a startup.
Team balance doesn’t exist.
If you are about to join a team full of seniors only … RUN! If they are all juniors … RUN. Teams should be balanced as there is always work for the most seniors who need to do complex stuff, and for juniors, who will see senior’s boring tasks as challenging. The imbalance is at the core of lousy team culture.
Blame culture and silos.
The blame culture usually happens when leaders create a “US vs THEM” mentality based on fear. It’s a widespread issue. One team is working on an important feature but needs help in a specific area on which they have no expertise or access, and when they ask for help, they get no response for weeks or maybe ridiculous deadlines like “in a half year”. When something goes wrong, no team takes responsibility, but everybody is just bouncing back the ball, blaming others for not doing their job.
Last-minute vacations (random absence).
People randomly leave at the last moment, going off-sick. That’s not a good sign and likely means they have nothing to do or simply don’t give a shit about what they do. It’s a survival mode.
Tasks & tickets are as clear as Covid lockdown rules.
TThat means people assume that things are well known, and no explanation is needed. This doesn’t scale, and the key individuals’ knowledge is being hoarded, leading to slow delivery and poor quality. Hard to be agile when things are blocked if this key person is unavailable.
Only key players are allowed to participate in discussions.
They are in charge and likely strong and experienced characters, but that often leads to situations where less skilled or more introverted individuals don’t want to be part of any discussion. They are afraid to be shot down and attacked by the group from the top. As a result, ideas are not heard, and everything the company is doing is “the old stuff” with no fresh perspective.
Your Slack chanelofobia becomes a real thing.
A tendency to create slack channels every time something happens. These channels usually have a few people involved and many others as “FYI” participants. In one place I worked for, we reached the limit of the Slack channel (felt like we landed in the Moon or something).
Glorification of overworking.
When people are praised for working another weekend or evening. It’s a wrong thing to do and only exposes the fact that the company craves such behaviour, and reward it. It also means your organisation sucks at planning work to prevent it from happening in the first place.
No trust
You believe there is no one you really trust…
The point!
After reading this post, I have a feeling I went on a moaning spree and threw out all the frustrations I experienced. I hope this will have some healing effect… Ohhhh…… it already had! ;)
But a bit more seriously…
The point of this post is to open your eyes to particular issues that might be happening in your team. Of course, it will be almost impossible that you went through this post and didn’t tick a few boxes, but believe me, there are places where it’s possible.
If your workplace ticks half of these boxes, you should really think about it, but that doesn’t automatically mean you should run. Instead, I encourage you to consider how you can help your organisation, make a difference, and make minor improvements that will make everyone’s life a bit better.
In the end, you are probably not the only one experiencing the frustrations, and your colleagues are in the same boat. So be the leader of change, be the hero company needs and if they don’t appreciate it, with all your heart you can say “I tried, I failed, I’ve learnt”.
