How Spotify’s Chapters helped us overcome our engineering silos and regain alignment.
When I first joined COYO as VP Engineering almost two years ago the company had already become a reasonably grown start-up at the time. The whole COYO Engineering department consisted of some twenty people, the company’s main language had only recently been switched to English and along with me the first two real international colleagues had their first days, too. The product, a social intranet platform for employees, surely looked sleek and lightweight from the outside. But technologically it had grown quite fast over the course of barely only two years back then and several members of the team reported (or complained rather) to me, that it was just this big pile of monolithic beast, no-one except for the elders was able to fully grasp and maintain.
And pretty much like the code base seemed to be like a patchwork rug, some of the teams and their members showed signs of misalignment and clearly aspects of modern work such as clear communication, an open and blame-free feedback culture and an empowered vibe which can lead to high performing and self organizing teams were not in place entirely — as always this never addresses everyone and everything but freshly speaking, the several teams were mainly minding their own businesses while still working on the same code base. Conway’s Law took its toll.
So obviously we were in need of some means of aligning our technological efforts and visions while at the same time finding ways of addressing that big bunch of growing technical debt (refactorings used to be somewhat in the hands of a mighty few or were done completely under the radar of Product Owners).
It was when I was doing some research on that challenge and already had an image in my mind about some form of team-spanning meetings or perhaps a lightweight matrix organization when I remembered that famous article from that Spotify called “Scaling Agile @ Spotify” dating back to 2012. In the article the then Agile Coaches Henrik Kniberg and Anders Ivarsson described a rather novel approach towards growing agile organizations. And while the concepts behind it weren’t completely new, the cultural vibe that came along with it was unparalleled — I was hooked and knew I might have found just the right inspiration.
So what to make of it? Just get a couple of people into one room and talk this through, trying to squeeze our teams into that model? Nah!
There is but one little catch in the original proposal and that is what Spotify calls Squads. These are roughly another wording of independent cross-functional teams and this unfortunately totally wasn’t the case with us yet so we decided to skip this one for now — as well as the Tribes, which really are a bunch of squads working in the same area of the application or product. And while one of our goals surely is to split up that aforementioned beast into components or products even, that then could and should be owned by something such as tribes, our current challenge still was way a bit behind that. After all, Spotify’s own engineering lead Marcin Floryan gave this brilliant talk about the fact that “there is no Spotify model”, which is an euphemism or a recall to never forget to create your own thing out of what really rather is more a framework than it is a blueprint to blindly copy.
So we went for the Chapters and since we had been in a rather early stage of our scaling agile endeavors we decided to start simple and defined three chapters, one for backend, frontend and operations respectively. One other fundamental difference from the framework as originally proposed was that the Chapter Leads we announced were not to line-manage the members of their chapters. As if we were anticipating certain challenges that come along with that and have been recently reported by former Spotify employee Jeremiah Lee in his blog article “Failed #SquadGoals” or Willem-Jan Agelings rant about it (which to be honest I haven’t read when we were thinking about how to adopt the model).
Because the problem is that teams in reality are rather long-living entities which form cultures of their own. Being somewhat traditionally managed by chapter leads, who usually come from a different team aka ecosphere and often times cannot say an awful lot about the daily working performance of their protégés, just didn’t feel right.
They really should be consensus-driven servant leaders who, alongside a clear idea and visions for the products/tech stacks they own, should try to develop their chapter members to become better in their profession — through the means of coaching and mentoring. A chapter to us is the central place of alignment and vivid discussion of what greater tech epic to tackle next. Chapter leads must see into the success of the chapter meetings, aiming them to be outcome-based and sure enough encourage people to take on difficult topics and tasks to work on. Certainly over time they should be able to assess the different levels of seniority of their members but in a usual Scrum or Kanban-based environment they cannot and should not directly tell people of different teams what to do. Chapters are fruitful places of people who speak the same language and seek ways to deepen their knowledge of certain areas of expertise — sometimes resulting in spinning off Communities of Practice from chapter meetings to further concentrate on important matters.
We are well into the process at the time of writing. It has been well over ten months since we first introduced chapters here at COYO and they are a continuing success of regaining alignment over technological topics. Having defined them across engineering domains rather than artificially assigning teams to superimposed conceptual cuts of an application that still was largely interdependent, turned out to be the absolutely right decision at the time. The only true major downside of that approach perhaps is that engineers are required to choose one chapter (with the liberty to attend other meetings to their liking) and thus potentially losing track of bleeding edge stuff from the other chapters.
Slowly but surely we are getting the better of our technical debts with still a bit of road ahead. On our way we have learned a great deal on aligned communication, taking on responsibilities for parts of the product and actually being accountable for them. But most of all we have found ways to overcome our silos while still having strong and self-organizing teams. By taking only those components out of the Spotify framework that were suitable to us at the time we have become a more mature, professional and scalable Engineering department.
