Creating High Performance Teams
You are starting a new journey on a new project. No matter if you join an existing team or form a new team, as a tech lead you would try hard to ensure a high performance team. But how?
Let's start with a definition.
What is a High Performance Team?
If you think of a team, having 10x Engineer heroes, doing overtime and working at nights; that is not what I meant. My interpretation of a High Performance Team is actually pretty close to what I understand from an agile team. Here we go:
- Time to Market is short.
- Autonomous and capable of building the intended product(s) on its own.
- Can adapt to changes fast.
- Can identify and fix bugs fast.
- Can fail often, but recovers quickly.
But how to achieve that?
I will list several methods below which all deserve more explanation and separate focus. In this post I will give you an overview, in the following weeks I will continue sharing new posts that give more insights for many methods listed here.
Understand the Current State
Before going further into taking actions, better to understand what the current state is. There are a bunch of unknowns when starting something new. The solutions won't be served for you on a golden plate. Rather, well, you have to figure them out. Understand the actual state about the team, how people work together, the product and the system architecture and so on. Mitigating the unknowns in the beginning can be pretty useful while you build your strategy, not after.
Four aspects of understanding the current state: getting to know the people and how they work together, understanding the product, the system architecture and technologies.
People First!
Understand the people and how they work together. Do some ice breaking activities, but also meet them in person. Sure, this can be tricky nowadays due to the pandemic. However, online 1-on-1 meetings can also help. In such meetings, besides getting to know each other, one can also sort the following questions out.
- What is working well?
- What are the pain points?
- Who is doing what?
- What are people's interests and contributions?
- What are their skills?
Answering these questions are of course not limited to 1-on-1 meetings. Daily stand-ups, retros and other regular or irregular meetings are a chance to sort things out.
Way of Working
This can show a lot about the cultural aspects of the team. Some questions around can help:
- Are they pairing or working solo?
- How much do they pay attention to testing, automation etc?
- What about ownership, are problems handled fast and taken care of or the opposite?
- How do people react when problems occur?
- How is the intercommunication between teams?
The Product
You are building a product, right? Yes, then it can not go without it, understanding the product is an important step through high performance teams. What about the following questions:
- What are the key features of the product?
- What about prioritisation?
- What are the domain entities, how are they interacting with each other?
- What is done so far, what is upcoming?
The System Architecture
The System Architecture tells a lot about the flow of data, services and their interactions. This also includes indirectly information about how different modules and/or teams in the overall system are coupled or independent. Ask following questions to yourself:
- Is there an up to date visualization of the System Architecture?
- Is it visible at a prominent place?
- Does everybody know and understand it?
- What are the main components and how do they interact with each other?
- How well does it represent the product?
The Methods Ensuring High Performance Team
Revisiting our initial goal: You want to create a high performance team. You have learned something about the product, the team, how they work and the system architecture (if there is one). Now it is time to go forward. Let's dive into more aspects on how to ensure a "sustainable" high performance team.
As People First, we start with People!
Continuous Feedback and Health Check
It is the people delivering value and building the product. Identifying their goals, objectives and pain points as well as helping and enabling team members are some key features for achieving a high performance team. Collecting feedback through 1-on-1's, retros and surveys can help a lot. What makes the difference are the actions based on the input. Otherwise, the problems can turn into complaints.
Onboarding / Offboarding
The product changes, the requirements changes, so the team members! The question is:
How fast can a new member start delivering value?
To achieve a fast one, let's make sure that the development environment can be constructed by some scripts. Practically, not everything is automated and there are more steps than just creating the development environment. In that case, having a document listing all necessary steps as a check list can also be helpful. Ideally you would have an onboarding buddy for helping the new joiner.
Similar also applies for the people leaving the team; hopefully it will be only about deleting the relevant resources and rotating passwords instead of setting weeks of knowledge transfer sessions.
Roles and Responsibilities
If we want to have a high performance team, we better make it clear what we expect from people. Otherwise, we may be performing very well for things that are not relevant to our product. Try to understand the following:
- What are the tasks the team have to take care of on a daily, regular or non periodic basis?
- Which roles are responsible for which tasks and who is filling which role?
- How clear are the expectations set?
Here comes the ownership theme. In the end, it is the team that is responsible for all the work that has to be done. However, distributing the responsibilities among the roles (not individuals), can bring some clarification:
Clear Expectations -> Better Outcomes.
Knowledge Distribution
It is totally normal that each member of the team has their own skills and maybe even focus points. However, that does not mean that there won't be overlapping. Indeed, there should be. Why so? Maybe the answer is hidden in the following question:
What happens if a member is missing?
i.e. quitting, sick leave or just vacation
Knowledge distribution is not only necessary for the sake of the project, but also for the team morale. This helps the members feel more confident and relaxed, as the work can still progress without them as a person. The team is responsible for the progress, not an individual. This brings a more distributed and balanced ownership of topics among the team, and contributes to a good and healthy team spirit. There are ways to ensure knowledge sharing. Let's go on with them:
Pairing
One of the most important tools to avoid knowledge islands is pairing. It helps actively distribute the knowledge among the team members. But it is more than that!
Ensuring 4-eyes principle, namely two developers are developing code and actively looking at the same screen together, pairing helps a lot for a higher quality of work. Yet another motivation, the pairs learn to work together and build connections.
On the other Hand, pairing can sometimes be too tiring. Besides, if the same pairs work all the time together, it can also loose its actual goal. The pairs can become so close to each other that they may feel like a sub-team inside the team. Moreover, knowledge is accumulated yet on kinda another island. But I have some good news, you can avoid that:
Rotate pairs frequently and take breaks :)
Tech Huddles
Tech Huddles are great to keep the developers improving themselves, bring suggestions and have open discussions. It is also the right environment to talk about architectural topics. It helps people to share knowledge, learn new technologies and tackle new solution suggestions.
The System Architecture
Given an introduction in the beginning, The System Architecture is a living document, sits in the heart of development. It is visited in Tech Huddles frequently. Together with Architecture Decision Records, it is also a TO-GO document when onboarding new team members.
Better keep it in boards like Mural or Miro, it can make it easier to access.
Architecture Decision Records (ADRs)
You are having tech huddles and making decisions. Keeping the track of the decisions made so far can be helpful for the following:
- A diary for the architecture itself
- A summary to show during onboarding new joiners
- A proof how the architecture evolves and reasoning behind
Identifying The Risks
Remember again, one of the key features of a high performance team:
Can fail often, but recovers quickly.
Ask yourself the following questions:
- What can go wrong, what can fail? (Seriously, many things can go wrong.)
- What are the scenarios of failure?
- What are the relevant action plans?
- What is the MTTR (Mean time to recover) or MTTA (Mean time to acknowledge)?
- What about a threat modelling workshop? It can help identifying the possible failures, their impact and recovery plans, it is great for identifying risks!
Automation, CI/CD
I will just list some questions here:
- Time to market?
- How fast a feature or a fix can propagate to the deployment environments?
- How frequent are services being deployed, are there deployment days?
- Are there any manual processes after code is pushed to the main branch? Or do you even not push to the main branch at all?
Trunk Based Development
If we consider the above questions, we can easily figure out that, creating Pull Requests (PR) would not be the best method to have a smooth and fast deployment experience, because there is a manual step involved. Trunk based development, indeed, answers this need.
To make it safe, however, it can only work well with pairing and testing. Pairing can be regarded as a step of reviewing even during development. On top of that, testing can bring a safer value pipeline and less manual effort.
Automated Testing
You have a CI/CD, you push to the main branch: all good. But how are you going to make sure that it is not going to break your product?
The details about testing are far beyond the scope of this blog. Despite this fact, I have to mention that, make sure your pipeline has several testing steps before and after deployments. Is that catching buggy code before going into production? Of course the answer is not only about the pipeline, but also about how “well” the code is covered in tests.
TDD, namely Test Driven Development, does not only help you to write tests, but also to design your code in a way that you know what you expect from a module even before implementing it. Besides, in general complexity in writing tests are related to the complexity of the implementation of a module. Take this as a sign :)
Monitoring
One of the key features of a high performance team is identifying and fixing the bugs fast. You have a well tested code and things are fine during development. However, things can still fail afterwards. It is not only the code, but also the state that the code runs with, i.e. data and/or external services, is changing. Each environment has its own state.
When it comes to production, at least a certain level of monitoring must be in place. This includes but is not limited to health checks and major functional tests, checking the key features of the product. On top of that, a more grained level of monitoring, i.e. response times with warning alarms should be active. However, the alarms should be fired only when it can make the team feel that "There is a problem and we have to look at it immediately."
So, keep the alarms meaningful and limited.
Planning & Prioritisation
In the end, however the team performs, it has a limited capacity and how efficient using it is a big question. Planning alone is so big, that can not fit into this blog. Still, one can put the followings into account:
- How well is the feature request fitting into product goals?
- Is there a clear Acceptance Criteria and Definition of Done?
- What is the cost of delay of a particular feature, bug fix etc?
- How big are the tickets?
- Can one pair finish the ticket on their own in one sprint?
- Are the feature requests balanced with tech excellence?
- How often are tickets spread over more than one Sprint?
- How much focused is the team or in other words, how many tasks run in parallel, Work In Progress (WIP)?
Summary
In order to create a high performance team, there are several aspects to take into account. In general, they are somehow about sustainable development and time to market.
In this post, I have listed some proven methods that I use actively in my projects in ThoughtWorks and they can be applied to many projects while giving a broad understanding about creating high performance teams. Moreover, please do not forget that each project has indeed its own dynamics. Therefore, these approaches should be adopted, extended and aligned with the project and people's needs and relative circumstances.
What is Next?
As mentioned in the beginning, this post is an overview covering many methods and all of these deserve more explanation and a separate focus. In the next weeks I will be sharing new posts that give more insight for several methods listed here.
Questions, comments and any feedback are welcome. Contact
Extra Readings
Attribution
Cover Photo: fauxels from Pexels,
Onboarding Photo: Etienne Boulanger on Unsplash
Knowledge Islands Photo: Asad Photo Maldives from Pexels,
Pair Programming Photo: Christina Morillo from Pexels
Identifying Risks Photo: John Moeses Bauan on Unsplash,
The charts are self work.