Every team has some level of dysfunction. And that’s normal, because teams are made of imperfect human beings. In his book The Five Dysfunctions of a Team, Patrick Lencioni identifies these five basic dysfunctions:
- Absence of Trust
- Fear of Conflict
- Lack of Commitment
- Avoidance of Accountability
- Inattention to Results
These dysfunctions build upon each other. A team that doesn’t trust each other is afraid to admit their shortcomings and mistakes. Teams like this aren’t vulnerable around each other. This leads to a fear of conflict, where ideas are not openly debated and bad behaviors are not called out for fear of offending someone. Rather than solving underlying problems, the team experiences growing tension manifested by occasionally passive aggressive remarks.
Because ideas aren’t openly discussed, there is very little buy-in from team members, and so they aren’t fully committed to any agreements. This leads to an avoidance of accountability, since it’s hard to hold someone accountable to a standard that they never really agreed to in the first place. All of this results in an inattention to results where the team fails to accomplish their most meaningful goals.
In this article, I’d like to examine these dysfunctions in the context of a software engineering team. Because believe it or not, software engineers are flawed human beings too.
Absence of Trust
Software engineers need to be able to trust each other. This includes trusting that your team members are on top of their work and can be relied upon to get their work done on time and correctly.
When members of an engineering team don’t trust each other:
Team members hide their mistakes out of fear
The team lead frequently follows up with team members to make sure the work is being done
The team lead serves as the gatekeeper who reviews all merge requests before code can be merged
Team members become protective of areas of the software application in which they’ve worked and don’t like anyone else touching their code
But when they do trust each other:
Team members catch their mistakes quickly, discuss them openly, and resolve them speedily
Each team member shows ownership over their work, reaching out for help when needed while still owning the solution and ensuring that the work gets done
All team members review each other’s code, and any team member’s stamp of approval on a merge request is good enough to allow code to be merged
Any team member can work in any part of the codebase
Fear of Conflict
Every software engineering team needs a healthy amount of conflict. You might argue that a team which is perfectly aligned and agrees on all issues has no need for conflict, which is technically true, but I have yet to meet a team like this. After all, engineers are known for being opinionated.
When members of an engineering team have a fear of conflict:
Team members don’t bring up process issues or other efficiency problems
Team meetings are boring and without much discussion
Team members allow toxic behaviors to go unchecked
Low performers bring down the team by making the same mistakes over and over and wasting their team members’ time
Morale decreases
But when conflict is embraced:
Team members always seek to improve the way they do things and look for outdated processes that should be changed
Team meetings are filled with lively discussion and sometimes heated debate (but always focusing on tangible issues, not general attacks on each other)
Team members call out toxic behavior and don’t tolerate any form of bullying or verbal abuse
Low performers are held accountable to the team’s standards and are told how their behavior affects the rest of the team
Morale increases
Lack of Commitment
Software engineering teams need to be committed to the goals that they’ve set. But if there’s no honest discussion when goals are made, there’s no buy-in from each team member to actually accomplish these goals.
When members of an engineering team show a lack of commitment:
Sprint goals and deadlines are frequently missed
Team members often work on the wrong things
Code-quality standards are not followed, and shortcuts are taken
But when every team member is committed to accomplishing the team’s goals:
Sprint goals and deadlines are generally met (with the occasional delay)
Each team member is working on the most important thing at any given time
Code-quality standards are agreed upon and followed (and enforced by code formatters, linters, and test suites run in continuous integration pipelines)
Avoidance of Accountability
Software engineering teams need to hold each team member to the standards that they’ve agreed to.
An avoidance of accountability stems largely from a fear of conflict. It’s important to remember though that when we talk about accountability, we don’t mean punishing someone any time they make a mistake. We also don’t mean you have to be rude about it. You can hold someone accountable while still treating them with respect.
Holding each other accountable means having an honest and open discussion when someone isn’t pulling their weight or is dragging the team down. These conversations don’t have to wait until tensions have grown until everyone is at their breaking point. They can happen immediately for the smallest behaviors in the form of respectable micro-doses of feedback. Being clear is not being mean.
When members of an engineering team avoid accountability:
Important tasks don’t get done
Low performers drag the team down
The team’s overall velocity decreases
Standards are ignored and code quality decreases
The team lead or manager is the only one who addresses poor performance or other bad behavior
But when team members do hold each other accountable:
Important tasks are completed
Low performers are encouraged to improve or to move on
The team’s overall velocity increases
Standards are upheld and code quality remains high
All team members feel comfortable holding one another accountable, not just the team lead
Inattention to Results
Software engineering teams need to be focused on results. Engineers don’t complete tasks just as busywork — they build things to deliver value to their customers and to solve problems.
When members of an engineering team show an inattention to results:
Sprint goals and deadlines are often missed
Lots of work may get done, but it may be the wrong work or low impact work
Team members don’t show an interest in or ownership of their work
Each team member seems to be moving in a different direction
But when team members show a strong attention to results:
Sprint goals and deadlines are generally met (with the occasional delay)
Lots of work gets done, and it’s the right work, the most important work
Each team member shows ownership over their work and pride in doing a good job
The members of a team are working toward a shared goal and are not simply a collection of individuals but a team
Conclusion
All teams exhibit some level of dysfunction, and that’s perfectly normal. But if you want to get better as a team, the first step is having an open and honest conversation about these dysfunctions. Identify your team’s strengths and weaknesses, and make a plan to improve.
Overcoming the five dysfunctions of a software engineering team is incredibly simple in theory and yet very difficult in practice. And that’s exactly what it takes to get better at this — practice, practice, practice.
Top comments (0)