High performing teams

Tough technical challenges, changes, new blockers found day after day, uncertainty, lack of answers, and a great deal of responsibility on top of it all. 

This seems not to be the ideal environment for most, but there is a special group of people that thrives exactly when these arise. These people come up with outstanding solutions to the problems, deliver solid results, and are motivated while working in these challenging environments. It’s likely that we are talking about a High Performing Team.

In this article, we will go through some aspects of High Performing Teams that would help us identify such teams and also bring our teams’ performance higher. We will start with a brief overview of performance, and describe some of the characteristics of these teams, both from the team and management perspectives.

What is performance?

Performance relates to the measurement of a set of indicators. In the case of software development, we have deliverables: quality, quantity, speed, complexity, customer satisfaction. And when we are talking about a team, there are also indicators. Some examples are: how integrated a team is, how a team deals with complex problems and changes, how quickly a team adapts to a new environment, learns and so on. So, a team’s performance can be measured by the indicators of their deliverables combined with the teams’ indicators previously mentioned.

Let’s now take a look at some characteristics of high performing teams.

There are two main aspects: the team itself and the management. Firstly, let’s focus on the characteristics of the team.

Ingredients of a high performing team

On the team side of this equation, we have a couple of critical ingredients. The most important item is the clarity of what needs to be done. What are the goals we are trying to achieve? Why is this important? The team should be informed and have someone who could support them in case more questions arise. 

After we know what needs to be done, we need to figure out how to achieve that objective. Technical expertise is a critical enabler for higher performance. This is important because of the flexibility required to quickly adapt to the changes and dealing with dependencies and complexity. It’s not that all the team members must be tech-gurus, but expertise definitely plays an important role. Previous experiences and background in similar situations also make the decision-making process more fluid, allowing for more energy to be focused on the problem itself. One experienced team is able to think of multiple approaches to tackle the problem, weigh the pros and cons of each solution and choose the best one to reach the goal. 

We also need something that can tell us if one solution-attempt worked or not. And fast! This is achievable by short feedback loops. This might mean better continuous integration practices, more unit tests, more infrastructure available for running tests, more equipment. This feedback can also take the form of more direct communication between team members or access to important stakeholders (such as customers, end-users, etc.) if required. The doors should be open. Regarding making sure the solutions are working, it might also be a good idea to define clear acceptance criteria and/or the most important scenarios or project checkpoints. This helps the whole project team to be aware of the milestones completed and to be achieved.

It’s important to say that a High Performing Team is not necessarily a team of high performers. So, what’s the deal here? A great collaboration between team members is paramount to success. Collaboration encompasses many different aspects of team dynamics: the communication between team members and their attitude to work in an uncertain environment. These might foster or hinder openness, dialogue, and creative aspects, like thinking outside the box and coming up with new ideas to solve a problem. Also in the collaborative aspect, the team members must be on the same page and set realistic expectations for each other. For this to happen, they need to know each other well, their strengths, and weaknesses and trust each other. This enables high quality and team members are not shamed for not knowing a certain topic, which helps to create a good and open working atmosphere.

As we have faced them time and time again, some challenges are not obvious and we had to accept some risks to move on. Over time some of these risks will materialize, causing failures. The way a team handles uncertainty, risks and failures vary in a continuum between complete aversion to risk and excitement. I personally believe that working in such a technically uncertain, but emotionally safe environment, where we are open to thinking outside the box and would not be punished for a solution that did not work, can be one of the most satisfying work-related feelings. It somehow captures the essence of teamwork and creativity in the context of problem-solving. 

And this leads us to autonomy and responsibility. Teams need autonomy to make decisions, to reflect on their actions, and learn how to deal with problems ahead of them, no matter how complex they are. Autonomy does not mean that the team is free to do anything they want to. They are free within the project goal, aware of (possibly many) technical constraints in addition to time and resources available. Let’s keep in mind that autonomy goes hand in hand with responsibility. When you are given the freedom you are also given a set of expectations that should be met. And here time is a valuable ally to enable teams to take more responsibility and deliver more (quality, efficiency, number…) considering their previous experiences together.

Another important aspect is the sustainability of the team and their outcomes. We should not aim at having a team delivering outstanding performance for one month and go back to the normal operation later on. We are not trying to solve one emergency that needs our experts working together. No, the idea is much bigger than that: we need to be providing outstanding performance day after day, achieving goals without quality drops, unnecessary waste, or increasing technical debt. Teams are made of people and their needs must be taken into consideration! It is critical to find ways to keep the team engaged and motivated. From time to time there will be eventually a bit of chaos and some pressure to get things done. Reduce those moments, focus on attacking the root causes and the time spent on these urges should reduce. This will allow time for looking for the improvements required.

To complement the team’s perspective, let’s now look at the management perspective.

The management role

Management provides the foundations for the team in order to ensure their optimal operation. At first, this means covering the very basics that must be in place, so the team can perform at all: infrastructure, access to the required resources, information, references on who can help... this might also mean re-prioritizing some scope to allow the team to move smoothly, removing some blockers in a higher management level, when inter-team (or project) dependencies/conflicts come up.

Once these basic needs are covered we can think about the next ones. Given its importance, it’s worth repeating that the team must have a crystal clear goal at all times. The amount of uncertainties in software development projects is already huge, so having this clear objective already helps a lot. This is a job for the management and leaders of the organization. Depending on the environment, these leaders could be architects, product owners or business leaders, that together with management are able to provide the required guidance, support, and stability for the teams to achieve long-term goals despite the changes that will inevitably happen. 

As a team, decisions will be made and problems will be solved. The team should be encouraged to get problems solved end-to-end, owning them. On the management side, support and autonomy are required when it comes to their decisions, trusting they made the best decision given the circumstances. This creates a positive loop that will reinforce the team into making more decisions without fear of being misjudged. No matter how good the teams are, they will not get it right all the time. This is part of the game… and an important one! There will certainly be mistakes and failed experiments. The edge between high performance and chaos is really delicate. Management must be understanding that the team will also run out of answers from time to time. 

As a manager, I know personally how challenging it is to keep my teams focused and undisturbed. So many things are changing and someone is always demanding information from them. This is yet another thing that really enables teams to perform more. So, it is up to the management to get the priorities clear, communicate the goals and keep the team undisturbed for as long as possible. 

Even though being in a high performing team is extremely satisfying itself, rewarding the team members accordingly cannot be left aside. The good side is that if we are talking about high performing teams, the results provided by the teams will definitely support these rewards.

A reality touch

On paper, things are usually clear. This section is to show some messy reality in action! I had the opportunity (and pleasure, and headaches) of being a part of a really intense project in my career. Overtime and weekends at work were happening to meet the deadline. The project was crazy complex and required many people from different teams of the organization to cooperate together. The goal was clear: an installation by this date! We felt like failure was staring us in the eye every day. 

We were 5 people in “do whatever it takes” mode to get the delivery done (clear goal). We got together and very openly discussed our options. The only one that had any chance of success was to lower our formalities to the absolute lowest possible and quickly feedback ourselves on the changes that we were expected to make against the outcomes. As a system tester, I was able to provide valuable feedback about the system and the impact of the latest hardware and software changes. But to speed things up, part of the software team was working really closely with me, checking the test results and explaining to me the changes made, giving me valuable insights on potentially more vulnerable areas that could be impacted, and so on. No bug reports, no official builds being created. Was this bad? Following the process is important, but when faced with the possibility of having 5 different approaches tested informally versus having 2 official builds formally tested and reported, we chose the first (autonomy / short feedback loops/collaboration). And we received support from our managers to work like that while it was required (support). 

We kept our managers aware of the overall status, but this was a rather fast update, mostly just letting them know what we needed help with (resources and logistics). It was very helpful for us to know that we did not need to spend time on endless meetings to put everyone on the same page (support/autonomy/focus). The team was working together efficiently and solutions were coming. There were at least a couple of times when we had no good solution for the next move. Some experimentation also took place. “This seems impossible...” was the beginning of some conversations we had. Small chances of success were better than not having a solution for the problem, so we went for it. Obviously not only successes, so retries were happening quite often (handling uncertainty and failures). There was another interesting aspect that is worth mentioning: a team member had some spare time and was asked to join our team to help us out. Unfortunately, this really did not work out. He was completely outside the team dynamics and was definitely not in sync with the rest of the team in terms of languages, actions, and lack of formal communication. So, even though he was technically capable, bringing him in the team for a week or two would cost us too much, so we decided that it was more effective for him not to be part of the project (autonomy/decision making).

Eventually, we got by and the project was delivered on time and finally installed. It had all the required functionalities without workarounds, working as expected. As a company, we were able to continue improvements on top of that solution that was already bringing value to the customer.

Conclusion

To wrap this article up. Is there a recipe for a High Performing Team? Not exactly. Is it easy? Again, no. Should we stop ourselves from giving it a try because of that? Definitely NOT. The drive, energy, and results High Performing Teams provide to the organization are worth the effort put on them and allowing them to work in this elevated environment.

Having experienced this once will increase the chances the person wants to feel this again. This is really nicely described in a book called Flow, by Mihaly Csikszentmihalyi.

There is something in logic about the triggers for a given event to happen: conditions that are necessary, but not sufficient. For high-performance teams, the ingredients previously described are required, but not necessarily sufficient. Be skeptical of one-fit-all solutions. Up to a given level, it’s up to the team to find out the areas that need more fine-tuning. Management is to support and encourage that search. Keep investigating! And no matter where you or your team stands in the performance continuum, strive for excellence and higher performance.

References / Further reading

• Csikszentmihalyi, Mihaly. Flow. Andrews McMeel Publishing, 2008
• Lencioni, Patrick. The Five Dysfunctions of a Team. John Wiley & Sons, 2002