In my career as a developer, I’ve worked with many different people in teams ranging in size from two to ten members.
During these years I’ve learned so many lessons thanks to certain behaviors that have led to toxicity in our working environment.
In this post, I want to share the worst behaviors — ones that can totally destroy a team’s working environment.
1. Making Assumptions
This applies to teams working in many areas, not just development.
Everyone knows that communication is one of the biggest factors in the success or failure of a team. If you want to achieve big goals you have to work together and have clear communication guidelines.
When some of those guidelines are ignored or they’re not clear, the team suffers.
If someone in a team starts with an assumption, this can lead to unpredictable results, discussions or even errors in applications.
When a team member or a manager asks you to do something, you need to make sure you understand them correctly. You can do this by telling your team members, “so, you mean x when you say this….” Or simply ask questions when you don’t understand what needs to be done.
I’m by no means a perfect team member, but I’ve seen the positive results when I asked those extra questions or repeated what the other person told me in my own words.
I hope this has positive results on your team too.
2. Lack Of Communication
As developers, we’re often seen as people sitting alone in the dark, coding all night long. For most of us that’s not exactly true — but there’s some truth in it.
We know that when developing an application (or a part of it) it’s important to have a clear and continuous stream of communication — without this, bugs, errors, and fruitless discussions are common.
I have experienced this so many times. Usually, it’s not intentional. Most of us are just so deep in thought, working out a solution for a problem we need to solve.
Forgetting to communicate is common in our work. But since most problems in a team are caused by a lack of communication, we need to solve this and come up with a system.
When you have issues like these it’s time to put your heads together. We need to define when we communicate, what we communicate, and how we communicate with each other.
It’s important to write these things down. Especially for developers, because we use our brains a lot for our work. The system doesn’t need to be difficult! A simple system that solves the communication problem is good enough.
My solutions are probably highly inspired by the Agile framework Scrum. But I’ve found them highly effective over my last year’s development.
Daily standup meetings
I find standup meetings useful for planned communication — if everyone in the team attends, of course. If your team is remote, using slack with the Geekbot is useful.
My team and I do a standup every morning at 11:00 via a video call, where we describe what did we did yesterday, what we’re planning to do today, and if we have things that are blocking us from doing our work. This makes it easy for each other to help and communicate.
Use a form of scrum or kanban board
A lot of teams work with the Agile manifesto and use a framework, like Scrum or Kanban, for the implementation. The handy thing about these frameworks is that they’ve already defined a couple of things that you can apply.
Both frameworks use a board where you can see where everyone in the team is working on. If your team doesn’t have the budget to use something like Jira, you can easily use Trello. Or, if you’re using Github for your code, use those boards.
Here you can assign work to people, put it in a status column and see when something is done. It’s easy, but it really helps with communication!
Every couple of weeks (you and your team should decide how often) it’s good to discuss how everything is going.
I like it when everyone can describe three wins and three improvements from those weeks. I like to hear my teammate’s wins and improvements.
In the case of the wins, spend as much time talking about that as the improvements. Celebrating our wins is just as important as learning from our mistakes. I believe there are no wins without mistakes when you turn them into lessons.
All these solutions contribute to a team’s communication. If something isn’t working in your team, improve and adjust it until everyone is happy with it. That is what I like about the Agile mindset!
3. Not Taking Responsibility
Let’s be honest, working in a team can be both fun and challenging.
When errors and bugs, or even worse, are introduced, servers go down because of errors and people’s real natures come to the surface. People who normally work great together starting to blame one another. This is not good for the vibe in the team!
The problem is that most people are scared to admit they made a mistake. Perhaps they’re afraid to get fired or worried they will lose some respect in their team. People can have many reasons to blame someone else. But that doesn’t help anyone!
It’s all down to a lack of responsibility. If nobody takes responsibility, the vibe in the team will go from bad to worse.
Everyone should feel comfortable enough to admit that he or she made a mistake. After that, it is not so much the problem of one person in the team. If you are a team, if one fails, everyone fails. If one wins, everyone wins.
I believe in taking collective responsibility — fixing each other’s problems, together!
I believe in running a marathon together instead of everyone for themselves. Because, if we’re honest, we need each other.
I hope that if these behaviors occur in your team, nobody starts blaming people. But I do hope that someone will acknowledge we have a problem as a team and that you work out the solution with each other!
If you have discovered these things in your team and found other solutions, feel free to let us know in the comments, so we can learn and be inspired by each other.
Happy Coding 🚀