5 Traps, that Hinder Building the Dev Team

As a rule, it looks like most of us don’t think about how to build a development team. The team is just there. There are several developers, sometimes a tester and they form a team… only in name. However, are these people really a team? Real teamwork is a fleeting matter. Unfortunately, organizations often fall into traps that don’t allow them to achieve teamwork within their dev teams. How to get out of the impasse? Read below.

We define these problems as dysfunctions that don’t let the dev teams achieve success. All of them are interrelated, but one of them may pose a significant threat to teamwork.

Trap 1 – Lack of trust in the dev team

This is the most fundamental dysfunction that prevents the team from working and developing. Lack of trust stems from the reluctance to become dependent on the group and … openness to one’s weaknesses. The dev team members must open themselves to their mistakes and weaknesses. That’s how trust is built. Lack of openness to others results in hiding their shortcomings and prevents them from working.

Trap 2 – The fear of conflict in the team

This results from the first dysfunction. People who don’t trust are conservative, afraid that coming into a conflict would offend someone. More than once, they prefer to keep the status quo rather than getting into a fiery discussion. Dev teams in which members don’t express their opinions and ideas directly, because they are afraid of confrontation, won’t come to anything creative. According to Patrick Lencioni’s thought:

“Balanced discussions and comments will not result in better solutions. They will also not improve the atmosphere in the development team. It won’t help to hide hidden grievances.”

However, please don’t confuse healthy conflicts with regular fights and personal comments. It has nothing to do with that and it can ruin the relationship in the dev team.

Trap 3 – Lack of commitment in the dev team

You all know how it is. In order not to cause a conflict and not to argue, we nod at everything.

Yes, I agree. Yes, I’m cool with that. Yup, whatever man.

Is such an attitude indicating a commitment? Well, rather, it indicates the deadly disease (slow dying) of the team. Passivity…

Those who during the fiery discussion have kept their opinions for themselves, feel dissatisfaction, omission.

“I will act like the rest of the team wants, cause I don’t want a conflict. However, I know it is not my solution.” Do you know the school CPF model? Cram, pass, forget. Exactly, such an attitude has no commitment at all, it’s just rattling off.

Trap 4 – Avoiding of responsibility by members of the dev teams

Where we don’t feel that what we are doing, concerns us, there is no sense of responsibility. Team members who don’t identify with the team, avoid responsibility. This is also related to paying attention to colleagues when we see that what they do affects the software development team badly. Those who aren’t very involved will not bother to tell others that they are doing something wrong.

Trap 5 – Lack of attention to results

All these elements have such an effect that everyone cares for themselves. For their careers, for recognition, and even their own ego. There is no real cooperation here. People put their needs above the needs of the team. No one feels responsible for the results. Often at the end, when the team is billed with the result, there are further misunderstandings. Obviously, because someone says: ‘I would do it differently’.

How not lead to dysfunction of the development team?

In the end, as we reached the finish line, I gathered my arguments. Especially for you. Simple to read and assimilate, tips about how a real team should behave:

• Team members trust each other mutually
• They engage in constructive arguments about their ideas
• Team members have an impact on team decisions, so they identify with the team as well
• They feel responsible and require responsibility from others
• They are focused on a common goal

Summary

In the end, I’ll add that when creating this article, I helped myself with the book ‘The five dysfunction of a team: a leadership fable’ written by Patrick Lencioni. In this way, I could more easily put into words what I experienced myself.

According to you, how do not cause dysfunction of the software development team?