Restructuring a Growing Team: A Lesson in Adjusting the Spotify Model

Problem

I was managing a rapidly growing software development department that doubled in size for a short period of time and reached a size of about 100 people. At that moment, we felt we hit a glass ceiling and had to restructure the team in order to scale. Two EMs were spread thin, managing around 50 people each along with taking care of projects, clients, and sales.

Furthermore, we were proud of our culture, particularly the profound sense of belonging people on the engineering team had. However, as we grew over a certain number, that feeling started to wither away. They became increasingly disengaged and started to feel detached from the team and company.

Actions taken

We started to look for alternative team structures that would allow us to share the knowledge, build relationships, and have people feel they belong to the team again. After some consideration, we decided to try the Spotify model of squads and tribes though we were aware that it was better suited for product companies that could organize their teams to address a specific set of user problems. As a service-providing company, we had to adjust their model to match our unique needs.

We organize a number of workshops to discuss how we could restructure the team and split it into smaller teams. We ended up splitting the team by technology we were implementing, which allowed us to split our large team into five teams (tribes) of 20 people. Then we went one step further and asked ourselves if we could also include some people from other departments to round up those tribes. That would make tribes more self-sufficient and responsible for specific business goals.

From the moment people were regrouped into smaller teams of 20, they retrieved that sense of belonging to a team. We hired a couple of managers, and all of us became responsible for managing one of those new tribes. In a certain way, I was relegated from leading a team of 100 to leading a team of 20-25 people, but there was more to it. We realized that self-sufficient as they were, tribes could also have more autonomy in terms of the business side of things, taking care of their profit and loss, selling their services, etc. So we moved a large piece of business responsibilities from other departments into tribes.

We ended up adjusting the Spotify model, which worked great for our needs. Tribe managers were acting as mini-CEOs for their teams, advocating for their interest within a larger company. That gave us a great business boost because tribes took over doing marketing, some of the sales, etc. Moreover, teams were able to allocate their developers’ time to meet their business goals. We innovated the software house to spin off some products, which also created additional revenue streams.

We initiated this transformation with people in mind; we wanted to reignite their sense of belonging to the team and uphold the culture we developed in the early days. As it turned out, we managed to extensively scale the business at the same time.

Lessons learned

• We learned so much on the go. The plan is nothing; planning is everything. We were sticking to Agile in our efforts to build an adaptable and resilient company. We didn’t come up with the final plan, but with contours of the outcomes we wanted to achieve. We were reiterating, pivoting, and adjusting as the situation was changing
• Stay open-minded throughout the process. Listen carefully to feedback given by the people affected by the change. We communicated every step along the way transparently and made sure that people knew what was going on at any given moment and thus felt in control and safe. We also made sure that people will be given an opportunity to work in the teams they want to work. As a result, they felt that they could influence decisions and be active participants in the process.
• I am a great admirer of Jeff Bezos and his advice that one should be able to feed the team with two pizzas. If your team grows beyond two pizzas, you should think about restructuring it.
• With 100 or 150 people on the team, you can’t prescribe culture. The culture is already there, and all you can do is describe it. It is simply too late to impose anything. We conducted workshops to learn about values and common practices shared across the teams and created a culture book based on those responses. It resembled a bit of reverse engineering; we didn’t build a culture first, but we built the company and acknowledged the culture that emerged.