Restructuring a Growing Team: A Lesson in Adjusting the Spotify Model
11 June, 2021
Engineering Manager at Hinterview
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.
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.
- 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.
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
A proposal for how to create an org structure that will deliver software systems that you want, not ones you get stuck with.
CTO at REAL Engagement & Loyalty
Snehal Shaha, Lead Technical Program Manager at Momentive (fka SurveyMonkey), details her short-term technical strategy to unify processes among teams following an acquisition.
Technical Program Management at Apple Inc.
Christophe Broult, Director of Test Engineering at diconium, focuses on how he scaled his team while building organization and management teams in place.
Director Test Engineering at diconium
Sangeeta Wakhale, Senior Manager Engineering at athenahealth, talks about the space she had created between her work and family life, balancing time between the two that enabled her to pursue her dreams.
Senior Manager Engineering at athenahealth
Alishah Novin, Sr Program Manager at Microsoft, shares his experience creating a viral LinkedIn post that led to a specialized take on mentorship, micro-mentorship.
Sr Program Manager at Microsoft Corporation