Goodbye Chapter Leads, Hello Engineering Managers!
During my years at plista — an ad-tech company headquartered in Berlin — I have seen, experienced and designed several team structures in action. By now I’m certain this journey will never end. It’s an organic evolution fueled by the company’s needs and the industry’s experience.
Right in these days we’re again leaving one phase behind us, learning from the past and jumping to the next level. So this is the perfect opportunity to reflect on the past and explain the step we’re taking.
You’re running the “Spotify Model” and you’re hitting the wall with issues you cannot solve? Then this is for you!
Team Structure is Evolution
Especially during the company’s growth phase scaling from three to 20+ countries on 4 continents we faced the challenge to design the Product & Engineering organization to keep up with the growth and increasing complexity without losing velocity and team collaboration.
During my time we went through different types of team setups: starting off as two big teams, one developing the products that our end users on the www would see and the other taking care of all platforms that our customers and employees would use. The two teams both were cross-functional, with roles like DevOps, Frontend or QA. The two teams each had a lead all the members would report to.
This setup was great for its low overhead, direct communication and team feeling. But obviously it did not scale.
To allow for growth we needed sub-teams. For that, however, the teams decided to go completely different paths: one chose to split into sub-teams by function and the one by product. Both models were entirely different: one was a rather traditional department-type model with several function-homogeneous teams, like e.g. DevOps team or Machine Learning team, each with their own team leads.
The other one was implemented as an intentionally hierarchy-free, cross-functional model with teams structured around the different internal applications. Those product teams each didn’t even have any leads but instead all of the engineers would still report to and be coached by the one director.
Both models allowed us to scale the team to some extent but suffered from significant shortcomings that came with both setups. Thinking about it now it’s very obvious: The split-by-function teams quickly experienced a disconnect both on a professional and human level. Each team was working on their own roadmaps and own priorities, ultimately resulting in frustration and inconsistent progress for the end user product.
The other one struggled with all engineers receiving adequate coaching and proper technical direction for every-day challenges. This resulted in more and more responsibilities being shifted to the Product Owners. It left the Product Owners being accountable for all aspects of the product while not having the technical background or authority.
The “Spotify Model” and Us
To counter this, both teams migrated to a matrix model, the so-called “Spotify Model”. Back in those days it was hyped like the holy grail which would inevitably lead your company to the same success like Spotify’s. Or…so we thought. I personally was a big fan of the model and pushed for its adoption.
For the most part adopting the “Spotify model” was indeed beneficial for us. With the squad setup we managed to give the teams direct impact and a sense of ownership over their own product and at the same time keeping them autonomous and versatile. The role of the Agile Coaches helped us to question and strengthen the agile processes. However, the model also introduced several issues which over time turned out to be harmful and impossible to overcome.
I know — with this story we are far from unique, in fact there was a whole wave of blog posts, articles and even conference speeches from companies hitting the wall just like us. This is why I will not go through the whole list of drawbacks of the Chapter and Squads model but instead focus on the three areas that we experienced most pain in: alignment, coaching and product leadership.
Alignment
The alignment issue is a very obvious one when you look at the way the role of the chapter lead is setup up. In our case, the Chapter Leads would not only lead but also actively work in one of the squads. As Chapter Leads they are also the formal manager to all the chapter members, who, however, are spread over all the company’s squads. Therefore, your lead would often work in another squad than you. By design this can lead to conflict of interest.
While plista’s chapter lead management style was by no means autocratic this structure resulted in alignment issues. Just imagine: you’re an engineer that is asked to push for his squad’s goals but at the same time your personal goals are set by a Chapter Lead that is part of another team. Of course good Chapter Leads will try not to undermine the team’s goal and try to keep the goals to strictly personal development goals. But still he will introduce another set of goals and performance metrics next to the ones that the product team set up. Consequently the engineer is torn between one and the other, ultimately never focusing on one set 100%. Definitely not what we want, right?
Coaching
The other shortcoming we experienced a lot was the difficulty of effective coaching. As explained, often the Chapter Lead of an engineer would work as a member in another product team. He was, however, responsible for coaching his chapter members across all teams.
This often lead to a situation Piotr Majkowski describes very well from his time as Chapter Lead at spotify: “I felt like a dietician. […] Someone who has appointments with people who came to me every week and we would speak about goals and the current state […] and we would paint a better picture.” He then adds: “But instead what I wanted […] to be like a sports coach”.
To me, this parable hits the nail on the head — if you’re trying to coach an engineer without the every-day context you will never be more than a doctor handing out smart generic tips. For effective coaching, however, you want to have real-life, day-to-day experiences with your coachee. This way you really know what they are talking about and you can execute improvements together. Ideally you go through the pain and reward of the learning experience together with your coachee. This is what generates a sports coach-like experience.
Product Leadership
A less obvious but significant weakness we encountered is the model’s impact on the team’s product leadership. Product Development is ideally lead by the “magic trio” composed of Product Manager, Engineering Manager and Designer. Together they will work out the product’s customer value, business viability, feasibility and usability.
If you want to dive deeper into this topic I very much recommend Marty Cagan’s books INSPIRED and EMPOWERED.
With the Squads and Chapters setup we can’t have this trio — Yes, each of the product teams had a Product Manager but the Engineering part was a big issue: some of our teams would have several Chapter Leads present and others had none.
In both of those cases the Product Manager would not be able to do effective sparring with an engineering partner: In the case of many chapter leads they would not be sure which of them to speak with and no matter who he chose, the answer often would be: “Yeah, the back-end for that feature is possible but for the front-end you gotta ask xyz in the other squad…”. The chapter leads would only feel able to answer for their function and often the other needed leads were far away in other teams with other priorities.
In the other case of no Chapter Lead in the team the Product Manager would have to talk to all team engineers. So the PM had the choice between going through the overhead of organizing an expensive meeting with 7+ engineers or skip the discussion altogether leading to decisions lacking the engineering part of the picture for feasibility and including tech creativity.
Evolution Continued
Even after seeing those massive issues I don’t want to miss our experience with the Spotify Model. In our case it taught us the benefits of cross-functional product teams with a strong sense of identity, autonomy and ownership. Those are the aspects we clearly want to keep. The big issues we witnessed, however, are all bound to the role of the Chapter Lead. So that’s where we have to make amendments.
To overcome the described issues we need a leadership role present in each team ensuring aligning all engineers towards one set of goals, providing hands-on coaching and being a sparring partner to the team’s Product Manager and UI/UX Designer. It struck us like a lightning bolt: What we need are Engineering Managers, one in each product team!
So here we go: Goodbye Chapter Leads, Hello Engineering Managers!
Now you know where we stand — at the beginning of an exciting new chapter of plista’s Product & Engineering team evolution. And I’m sure it’s not the end of it!
