Software development teams that function well have a defining trait: they are so good at working together that they always achieve their goals.
A high-functioning team is almost always high-performing; But mind the difference. Not all high-performing teams are high-functioning – it’s possible that a team that meets their deliverables on target is actually struggling with underlying issues that could affect their performance in the long run. These issues are not obvious in the beginning; but as their deliverables grow and they work together for longer, the problems begin to show.
What could be the culprit? It’s likely that the team is, or has become, fundamentally dysfunctional.
A dysfunctional software development team suffers from a combination of problems such as:
- misalignment in roles and priorities
- unreliable members
- lack of mutual trust
- either too little or too much collaboration
- cognitive overload
- feedback barriers
- and many more…
While every dysfunctional team is unique, they often end up with the same grave outcome: they simply stop working.
To borrow and repurpose a famous quote from Leo Tolstoy, “All high-functioning teams are alike; each dysfunctional team is dysfunctional in its own way”
Where to begin?
Cultivating a high-functioning software development team is continuous work. You can start with these three steps:
#1 Talk about the people first, before the product
There will be plenty of time in the software engineering process to talk about the product. In fact, it will mostly be what everyone will talk about for the rest of the project’s duration. It’s important to be clear on the product goals and requirements as well as the code and architecture. But these should not be the focus of the first team meetings. No one will remember it and they probably should not try to. These details will change – even the overall product goals will change as you learn more about the users and the market.
Focus, instead, on presenting what will likely stay the same: the people behind the product.
During the first meeting, try to introduce and provide key information about these 3 groups of people:
- The end-users
- What is their main problem?
- What is their demographic?
- Who will they become when the problem is solved?
- The stakeholders
- What is their vision?
- What’s their main driver for investing in a solution (e.g. revenue, reputation, safety, etc.)
- What’s at stake if the product failed?
- Finally, the team members
- How is their professional background relevant to their role in the project?
- What skillsets do they have and plan to acquire?
- Which part of software development do they find challenging and what kind of help do they expect from each other?
- What do they hope to gain from building a successful product?
It’s important to be reminded of this key information regularly and whenever any of these groups change, e.g. when a new member joins or the vision has pivoted.
Remember: software is used, paid for and built by people. Harmonizing our unique personalities and abilities could be more complex than implementing any technical product.
#2 Agree on decision-making principles upfront
Most software development teams constantly improve their technical process – that’s from development to operations. They optimize their tech stack, code, pipelines, infrastructure, etc. To a certain degree, most teams also employ a specific project methodology, such as Scrum, Kanban or SAFe.
What’s typically missing in their setup are clear and well-adopted principles for making team decisions.
Teams make simple decisions every day; rewording a label on a button, approving pull requests, releasing to production are some of the decisions that are part of the daily flow. Then, there are the huge ones like switching the frontend framework e.g. from ReactJS to Vue, moving from microservices to a monolith, or restructuring the database from relational to NoSQL.
Without any guiding principles on how to handle different categories of decisions, whether its small or pivotal, the team could end up disagreeing to a point that it turns into a vicious cycle of bad arguments. While disagreements are normal (and healthy) within a team, constant arguments are counter-productive and stressful.
To avoid this, the team should initially define their framework for making decisions. Here are a few examples of decision-making principles for software development teams:
- As much as possible, get everyone’s input and decide based on a consensus
- Create a simple decision matrix that reflects who and how to make certain types of decisions
- If only a few team members have the final decision on a specific topic, they should consult other experts and those who will be affected by the changes
- Use test-driven and data-driven approach with sensibility
- Establish an acceptable timeline for reaching a final decision
- Team decisions must be documented and revisited
The composition, structure and circumstances vary from team to team, which influence the way they make decisions. Finding the appropriate principles upfront and adjusting it as the team evolves can help you manage conflicts before it turn into an irrevocable chaos.
#3 Try 1:1 between each teammate
Conversations between a people manager and an individual contributor are common, even in software development organizations. But what about a 1:1 between each teammate?
Let’s be honest. Some of the most difficult problems within a dysfunctional team involve only two people. Unfortunately, this seemingly localized issue has a disruptive effect on the whole team. Even high-functioning teams are not immune to this – they may even turn into a dysfunctional team if they don’t address the problem at once. Once two people in the team start turning against each other, more undesirable consequences follow.
Be aware of these common challenges between two teammates:
- One thinks that the other is unreliable
- One thinks that other is inconsiderate
- They reject each other’s different ways of completing the same tasks
- They don’t care about each other
A team is just like any other type of social unit that can only function when it operates around these basic values: respect, cooperation and compassion. How can you respect, cooperate with or care for someone that you hardly know?
Some people believe that work should never get personal. This is even more apparent in high-tech organizations. But I challenge you to look at this from another point of view. The more you deny that your relationship with your colleague can affect you personally, the harder it is to approach the problem in a more humane way.
Knowing a bit more about your teammate can give you different perspectives whenever a difficult situation arises. A healthy level of empathy, combined with objectivity, can help you minimize conflicts when a disagreement ensues.
There’s no other way to get to know a teammate than to talk to one another. Team-wide activities are great for establishing the overall work culture and team spirit. On the other hand, talking directly to a person and getting more comfortable with collaborating and communicating outside the usual group setting could lead to a more meaningful work relationship. That’s what a high-functioning team is all about.
Practice on the field
Software product development is a team sport. Having the best athletes doesn’t make you a champion. Building a high-functioning team requires selecting the right players who can harmoniously complement each other’s strengths and weaknesses. And this doesn’t happen in game 1. It takes time to understand how each individual person works – more time to leverage their unique capabilities to create and maintain real synergy. It’s an investment that is just as important as the software itself. Once you have a high-functioning team, you can build just about any product you can imagine.