Plato Elevate Winter Summit has been announced (Dec 7th-8th)

🔥

Back to resources

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

Reorganization
Agile / Scrum

11 June, 2021

Marcin Dyguda

Marcin Dyguda

Engineering Manager at Hinterview

Marcin Dyguda, Engineering Manager at Hinterview, shares how inspired by the Spotify model of tribes and squads, he helped restructure a growing team and made their engineering function more efficient.

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.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

How to Build a Software Team from the Ground Up

12 November

Deepesh Makkar, Sr Director of Engineering at SunPower Corporation, shares his experience transitioning his organization from contractors to a 50/50 split of full-time employees and international vendors.

Hiring
Motivation
Cross-Functional Collaboration
Agile / Scrum
Deepesh Makkar

Deepesh Makkar

Sr Director of Engineering at SunPower Corporation

How to Successfully Complete A Major Reorganization

4 November

Kirk Gray, VP of Engineering at McGraw-Hill, recalls his experiences performing major reorganizations of departments, including successful techniques to ensure a smooth transition.

Alignment
Convincing
Reorganization
Roadmap
Fairness
Kirk Gray

Kirk Gray

VP Engineering at McGraw Hill

Choosing the Perfect Implementation of Agile

25 October

Shubhro Roy, Engineering Manager at Box, stresses the importance of the holistic nature of Agile methodology; picking and choosing Ă  la carte may cause more problems than it solves.

Goal Setting
New Manager
Agile / Scrum
Shubhro Roy

Shubhro Roy

Engineering Manager at box

An Engineer’s Place in Product Creation

25 October

James Andrew (Andy) Vaughn, Principal Technical Product Manager at AppFolio, speaks on the mutually beneficial partnership between product managers and engineering leadership and its relation to a harmonious product development organization.

Different Skillsets
Meetings
Internal Communication
Reorganization
Roadmap
Toxic Atmospheres
James (Andy) Vaughn

James (Andy) Vaughn

Principal Technical Product Manager at AppFolio

Optimizing With Scrum

13 October

Phillip Derosa, Global Director of QA at OneSpan, takes Scrum seriously; he knows that the methodology is only as effective as its implementation.

Goal Setting
Agile / Scrum
Phillip Derosa

Phillip Derosa

Global Director of QA at OneSpan

You're a great engineer.
Become a great engineering leader.

Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.