Sprout Social always knows when its product teams have gotten too big.
Meetings stretch long and occur more frequently, with teams regrouping constantly to coordinate multiple projects rather than focusing on building just one new feature together. Engineers start feeling scattered and project managers overwhelmed. The product team’s Agile work style — or goal of continuously shipping and iterating on features based on customer feedback — falters.
“As the business needs continue to increase, there becomes a natural splitting point.”
“As the business needs continue to increase, there becomes a natural splitting point,” said Senior Project Manager Arnita Hayden.
The real challenge, she said, is figuring out how to actually divide up the team.
We talked to Hayden about how the Chicago-based social media management platform took it on.
How to structure product teams
- Adjust team structures to fit your needs. Sprout Social’s product team strictly modeled itself after Spotify’s team structure when it first began, but soon made adjustments to reduce the amount of time spent in meetings.
- Avoid creating silos. Sprout Social found it was important for heads of its tribes to be united under a common goal — otherwise, knowledge silos or goal silos could be formed.
- Don’t let teams get too big. When squads get too big, meetings get too long and it can be too hard to delegate work. Sprout Social continuously forms new squads, but makes sure they are completely staffed before separating them from the group.
Reaching the breaking point
In 2014, Sprout Social’s product team was comprised of about 30 engineers, designers, product managers and quality assurance experts. Then, the company secured $18 million in Series B funding.
In just a year, Sprout’s product team nearly doubled. The company’s ad hoc process for fixing bugs and assigning features unraveled, with random assignment of projects causing confusion, Hayden said. If a customer reported a bug, for example, remembering who built what proved challenging. When the developers who built the feature were finally found, they were often in the middle of working on different projects. Fixing the bug slowed work for everyone, she said, making it hard to deliver and ship products in an Agile environment.
In need of a formal structure for its product team, Sprout looked to Spotify as a model.
Adopting Spotify’s Squad structure
In 2015, Sprout Social’s product team modeled itself after Spotify, after the director of platform engineering was impressed by the efficiency, autonomy and Agile environment the Swedish startup’s structure provided the team.
The product team divided into six different business units — which it calls “tribes” — that it organizes in vertical and horizontal layers.
Each vertical business unit focuses on one area of the business: publishing, which focuses on outbound messages on social media; engagement, which is inbound messages on social; and analytics.
Horizontal business units span across the entire product team and include mobile, which focuses on building out the mobile app; global, which focuses on building notifications and other capabilities that span across the entire application; and growth, which focuses on converting and onboarding free users into paying customers.
Each tribe is usually headed by team of directors of engineering, design or product. Hayden said it’s important for leaders to work together so features aren’t developed in isolation.
“It’s important for leaders to be aligned toward a common goal in these tribes—otherwise they can end up in knowledge silos or decision-making silos.”
“It’s important for leaders to be aligned toward a common goal in these tribes — otherwise they can end up in knowledge silos or decision-making silos,” Hayden said.
Each tribe is then broken into squads that generally include no more than eight product managers, front-end engineers, back-end engineers, designers and QA people. Each squad is in charge of figuring out the design, structure and process for building new features. They work at their own pace — some complete one-week sprints, others do two-week sprints.
Once a feature is built and the code has been reviewed, every developer has the power to deploy a new feature on their own. Hayden said this contributes to a sense of autonomy.
“They don’t go through a separate approval process or priorities process — they have full autonomy to decide what makes sense to build for their customer,” Hayden said. “They don’t have to go through some master deployment process in order for the things to go live.”
How to divide teams when they’re getting too big
It’s easy to know when a team has gotten too large, Hayden said. The harder part is deciding how to divide it up.
She said Sprout Social avoids starting a new squad unless the team has at least one product manager and two front- and back-end engineers free. That way, if someone calls in sick, for example, there is still someone on the team who can work on the product. This policy often turns the timing of the split into a numbers game, she said, leaving it dependent on when a new hire starts.
From there, it’s important to establish what each new team’s responsibilities are.
“You want to create a division so that the two teams aren’t stepping on each other’s toes.”
“You want to create a division so that the two teams aren’t stepping on each other’s toes and have a way to be autonomous and deploy stuff independently,” Hayden said.
Don’t force it if parts of the system aren’t working
When Spotify launched in 2006, it strictly adhered to the Scrum philosophy of work, which clearly outlined how specific roles grouped together to work in an Agile environment. But as the company grew, it found that Scrum’s formal practices were getting in the way of its productivity, which is why it developed its own philosophy.
Like Spotify, Sprout Social was very strict in adhering to its chosen team structure when it first formally organized.
Among the tenets of the Spotify model is the Guild system, in which a group of people across the company who work in different squads and served in different roles but who share an interest in a similar topic — like a specific coding language — meet regularly.
Guilds helped Spotify maximize its Agile environment, but Sprout Social found forcing all employees into one created too many meetings for too many people. Now, it keeps the option of creating a Guild open for employees if they want, but participation in the group is not necessary.
“The Spotify structure works for them. But there are elements of it that may or may not work for you as a business.”
“The Spotify structure works for them. But there are elements of it that may or may not work for you as a business. I would say taking it at face value and trying to implement it is not the best approach,” Hayden said. “We learned over time that it’s OK to take bits and pieces of this that work well for us but leave those parts that don’t need to be in there out.”
Stay focused on the final product
Hayden credits Sprout Social’s product team structure with promoting fast feature development. But the organizational model is not without its shortfalls.
Sometimes, the product team has trouble coordinating across tribes and squads. Teams can be so laser focused that it can be challenging to make sure they are building a singular, united feature in the customer’s best interest. Other times, it can be hard to focus on building a feature across tribes. Recently, customers in the engagement division asked for a search function, she said — publishing had already built one. Hayden said it would have been easier to build both at the same time.
“Everyone is just narrowly focused on their mission, so that has been interesting in like trying to balance like, ‘How do we make sure that these things actually stand up across the company, that we’re creating a customer experience and it’s helpful?’” she said.
Still, she said more and more product teams — particularly those in Chicago — are modeling their work environment after Spotify. As the number of products in the cloud have increased, she said competition has increased, since it’s easier to build software than it once was. Spotify’s focus on creating an Agile work environment, and deploying features quickly, makes it an attractive model to emulate — so long as companies understand that they need to make it their own, she said.
“This model lends itself well to being able to ship and deliver quickly from market.”
“People really want to work in a more Agile fashion because it helps you have a nimble team,” she said. “This model lends itself well to being able to ship and deliver quickly from market.”
