The 5 Dysfunctions of a Software Team

Over the past fifteen years, I have worked with some amazing teammates, but sometimes, we struggled to ship. Not shipping features is very demoralizing to a software team and it corrodes the product and team cohesity. Even though all of the individuals within a team might be capable and extremely productive individually, there might be some factors that cause us not to ship when we get together as a team.

As part of an assigned reading for a team I was on, I read the Five Dysfunctions of a Team by Patrick Lencioni. He frames the dysfunctions as Absence of Trust, Fear of Conflict, Lack of Commitment, Avoidance of Accountability, and Inattention to Results. From my experience, I found software teams to be more nuanced in their productivity and output and I found it helpful to reflect and define the dysfunctions of a software team with more specificity.

Lack of Technical Leadership

Decision paralysis can set in when there are many things on your plate and you need to pick a direction. A strong technical leader can help facilitate the decision making process and own the decisions that have been made. Teams also need to be constantly aware of the technical vision. Individual contributors can and should have tunnel vision on what they are working on, but it is important for them to have direction when they Need it. An effective technical leader can also help communicate the need for and importance of sustainability and technical maintenance of the product to the stakeholders.

Lack of Product Definition

A default state for developers and individual contributors is bettering the product through working on maintenance or trying out new ways to improve developer experience. This is great, but can demoralize the team eventually if it is not balanced with features that provide business value. When the business path of a product is not well defined we also may have the tendency to fill our backlog with not-essential-to-the-business features. This could cause users to not engage with the product, leading to not enough feedback and eventual disengagement within the dev team. Not having proper product definition could also lead to too many pivots in the development cycle, which in turn can contribute to the feeling of never finishing a project.

Lack of KIND and Deliberate post-mortems and incident reviews

Incidents are inevitable and I would even posit that they are a sign of progress and change. If we are not deliberate on conducting the review without assigning blame, we could go down the slippery slope of not learning from the incident, prevent us from team accountability, and keep us from owning the entire lifecycle of the feature. This can contribute to a culture of fear of failure, thus never trying new things.

Failure to Embrace Automation

Not embracing automation of process, deployment, and release can lead to tedium and release fatigue. Not automating deployment and shipping puts an easy target on the developer’s back leading to blame when something defective gets shipped. Not automating process and standards can lead to time unnecessarily spent on nitpicking and bikeshedding.

Lack of Defined and Documented Process and Rhythm

We are creatures of habit and look for rhythm in our professional lives. A productive shipping team has purposeful process and a rhythm that is sustainable for the team. For some teams this may look like weekly cycle and for other teams it maybe a 6 weeks, but it is important to have that rhythm.

I used to think being productive had mainly to do with our tech stack choices but experience has led me to believe it is more nuanced than that. I think I can say this on behalf all developers that we are content and happy when we ship something that make our customers happy. It takes a village to create and sustain an impactful product.