Testing, Learning, and Improving: Building a Successful System Progressively

Problem

The situation was: within the company, we were a collective of six teams distributed geographically across the world and several time zones, the biggest difference between timezones being eight hours. Each team had experts who specialized in their own specific product area, but the other areas that we owned as an organization were a black box to them. They were not made privy to those areas and were not able to provide support if an issue came up.

We wanted to find a way to address this roadblock. I took it upon myself to look more deeply into the matter and to take ownership of the problem. I came across the Spotify squad model. I did some research and thought that the model would suit our needs and help us bridge these knowledge gaps. I adapted what they had done to match what we needed. I began to come up with the vision of how this would change the way that we did things going forward. It would impact not only engineers on a day-to-day basis, but also product, as well.

Actions taken

Instead of using static teams as we did before, we would be concerting more dynamic squads around problem statements that were customer-focused. Before, we were simply prioritizing everything ahead of time, these predetermined teams working on predetermined problems.

Initially, after documenting all of my ideas, I wanted to gain some buy-in from the leadership. We ran through the write-up, and it was received positively. The second-biggest hurdle involved getting buy-in from the engineering team. I was not expecting to get 100% buy-in, but the vast majority were interested in trying the plan out.

There were some struggles, which I had expected. We had frequent retrospectives on how the new system was working, but I decided to conduct agile health checks at the end of each quarter across the teams who were involved. I took a look at metrics like delivering value, learning, speed, support, and direct feedback from engineers to understand the effectiveness of squad model. We found ways in which to improve for the subsequent quarter and continued. Around sixty to seventy percent of the participants who were surveyed reported that the new system satisfied their needs.

It took three quarters to find our stride using this approach. The problem had been solved across the board. This was my first time overseeing and influencing such an extensive team, and I gained a newfound sense of confidence in my ability to lead.

Lessons learned

• The health check was as simple as asking each team member what they liked most about the new system and what they liked least. Through that, we were able to identify real problems and address them specifically. We also polled our team for how they felt about fun, speed, process, value delivery, and other metrics.
• I learned the value of a test-and-learn approach to problem solving. New processes should not be set in stone and discarded if they do not achieve results immediately. We test, improve, and then test again until there are no more improvements that we can make.
• My communication skills improved as a result of this experience. I had the chance to talk to a lot of people who I normally did not have the opportunity to talk to. I was able to introspect from a technical point of view, considering the needs of teams other than my own in a way that I was not used to. I knew on a higher level what our products were, but never got deeper into the other areas of the company in this way.