3 Toxic Development Team Behaviors

And how to solve them

Dev by RayRay
Mar 10 · 6 min read
Image for post
Image for post
Photo by Quino Al on Unsplash

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.

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.

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.

Image for post
Image for post

Hi, I’m Ray a Dutch 🇳🇱 JavaScript Developer and love to share my knowledge which I gained from being a Developer since 2009. I write stories about JavaScript, TypeScript, Angular, and anything related to life as a developer.

You can follow me on Twitter and Instagram or subscribe to my newsletter which I send when I post a new story.

Happy Coding 🚀

Better Programming

Advice for programmers.

Thanks to Zack Shapiro

Dev by RayRay

Written by

I write stories about Frontend Dev, JavaScript, Typescript, Angular, NodeJS, Serverless Functions, JAM Stack, FaunaDB, Netlify, Apple, iOS— https://byrayray.dev

Better Programming

Advice for programmers.

Dev by RayRay

Written by

I write stories about Frontend Dev, JavaScript, Typescript, Angular, NodeJS, Serverless Functions, JAM Stack, FaunaDB, Netlify, Apple, iOS— https://byrayray.dev

Better Programming

Advice for programmers.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store