When I first joined Spotify as an agile coach at the beginning of 2017, one of the challenges we faced was how to understand whether our teams were high-performing. How should we measure that, understand it, and analyze it?
We didn't have clear expectations or data about what it meant to be a high-performing team at Spotify.
First, however, we needed to get alignment on that, at several levels, before we could even start talking about doing health checks to measure how the teams were doing. Here's how we approached the issues.
Get buy-in from leadership
One of the biggest challenges we had was getting buy-in from our senior tech leaders. That's because, inherently, getting together to talk about what makes a high-performing team seemed to them to be a low-value activity.
It isn't about contributing to delivery, creating a product, or making money for the company, so buy-in was harder to get than for an initiative where the value proposition was clear.
Nonetheless, we were able to get their buy-in by talking with them and explaining the value of aligning on these issues. We promoted the business and operational benefits of going from a group of development teams that all operated in different ways, to teams that were aligned on their values, behaviors, and ways of working.
Then they started to understand why there might be more chaos, uncertainty, and misalignment in the ways that we were currently working. Once we were able to get that buy-in, we began to create the shared principles for our organization.
[ Also see: How to create and lead high-performing agile teams: 8 secrets ]
Begin bottom-up collaboration
Getting leadership to give us the mandate was the big challenge. But then we also had to get buy-in from them to be able to run a bottom-up collaboration. We needed this to create the shared principles, instead of leadership just deciding on the principles in a top-down manner. That's how leadership is used to doing things; they're used to figuring things out.
The problem with doing bottom-up collaboration is that it's not necessarily what the teams are doing in real life. Maybe the teams are looking at different metrics to understand what it means to be high-performing. Maybe what leadership brings to the table is wholly unrelated to the specific context of the teams' work.
So it was a challenge to have that conversation with leadership and getting them to let go of control and allow the teams to decide what values and principles would guide our organization.
[ Special Coverage: Agile + Devops West ]
Conduct workshops and health checks
Then we created the principles in a bottom-up fashion. We held workshops with representatives of our engineering teams to ensure that the principles were really what we wanted to exemplify.
Next, we developed a health check, or a self-assessment guide, to go along with the principles and supported teams in facilitating the discussions on high performance. This health check covers a range of behaviors that we want to see on teams that are high-performing. It gives the teams insight into what's working and what's not.
The team members assessed themselves, then saw how they scored. Upon seeing the scores, the teams could understand how they were meeting expectations for high performance, and committed to making incremental changes to become more aligned with the rest of the organization.
We were able to get feedback about the health check and immediately put that feedback into practice by creating and running a new health check based on that feedback. By utilizing this process, we were able to get a good snapshot of what was going on, so we could use the data to start improving things on the teams.
However, we still had to convince the teams that it was worth their time to participate in this—and that in itself was a challenge. To get their buy-in, we had to show them an example where it worked—where a team used the health check, got relevant data, and improved as a result.
We were able to get one team to buy into doing the health check by positioning it as a different version of a retrospective. Once that team used it with positive results, it was relatively easy to get the others on board.
[ Also see: How to build high-performing DevOps engineering teams ]
What we learned
We learned several important lessons about creating high-performing teams at Spotify, including:
Create values without the 'how' in mind
There will always be great best practices, but it's important to empower your team to discover what the implementation of a certain value looks like to them. It's not our job to tell the teams how they're going to do their work. We want to leave that up to them.
What's important is getting the result, not the method that's used to get to it. That was one of the biggest lessons—not to put the how into the principles or into the health checks.
Do team evaluation through planning poker
Use a planning poker approach of self-assessment rather than an open discussion. Facilitating the health checks in this way allowed individuals the space to give their honest views of how their teams were doing without being biased by a discussion-based approach.
Note-taking is essential
It's important to understand why a team aligned on a certain score when analyzing the data and identifying trends. Don't take the score at face value, since a score of four out of five for a particular behavior might mean completely different things to different teams.
Psychological safety is important to understand and measure
However, we ran into some challenges when implementing a question about psychological safety in the health check, since people wouldn't respond honestly if they perceived a lack of safety.
We learned that instead of addressing safety in a group setting, we should address it on an individual basis or in an anonymous way. This allows the individual to respond to the health check questions in a neutral way without consequence, so they won't be affected by the perceptions of leadership or their peers.
Operationalize health checks early
Put a rhythm behind it, and figure out how teams or organizations will act on the data before it's collected. Don't collect data without a plan in mind, accountable partners, and buy-in from leadership.
How to get started
Follow a model that’s similar to what we did. It’s important to get buy-in from tech leadership up front. And alignment on tech principles, areas of improvement, and best practices is best conducted from the team level upward, not the other way around. Finally, you use a tech principles self-assessment to measure continuous improvement of your team, and the organization as a whole, over time.
Attend my session at Agile + DevOps West and learn more about how Spotify has created high-performing teams, how the company assesses them, and how you can use this model to mold high-performing teams in your organization. The conference runs from June 7-9 in Las Vegas.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
