Spotify Light ... Nitro Engineering 2017

Finding a good and maybe even the right org structure for an engineering organization is something of a dark art.

Initially everything is so easy. 5-10 engineers are in one location, have one boss, work on the one thing and have one common skill.

But then you are successful. And you hire more engineers and then you realize that to derisk the hiring and the growth you probably want to hire in more than one location and then a couple of engineers will leave, because the people management aspect of the being an engineering manager is not something that comes naturally to most of us. Oh dear … and then things get … interesting :)

And then Spotify invented the squads and the tribes and the guilds and the chapters … and everything looked so easy. Again, except … it is not.

First of all, the biggest challenge is still not to talk about it, but to do it. Every day. You have to live it. And that is true regardless of the model that you pick or choose to implement.

Second, the Spotify model works for Spotify. There is no guarantee it will work for you. But it is a good start. And nothing prevents you from just picking the pieces that work for you and/or customize the model so that it works for you.

Nitro is not different from a lot of other startups. After a phase of rapid growth we ended up with too many engineering locations (4!) and not enough critical mass in each of them and no coherent org structure model to keep it all together.

Right now we are in the process to consolidate all our engineering into two (2!!) locations (Dublin and San Francisco). We also looked at the org structure and reflected what we want and need to get done in 2017. We need to …

• … put a stronger focus on people management
• … maintain our focus on strong technical leadership
• … increase our velocity (ship more and ship more often)
• … hire and on-board a lot of engineers (2-3 per month)
• … make it work for two locations

To make that work we are going to borrow two concepts (and just two) from the Spotify universe: The squads and the guilds.

The squads are integrated, independent, fully autonomous software development teams. They have a product owner and a UX person and a couple of engineers (frontend, backend, systems) and whatever else they need to ship features fast and right¹.

The squads will get formed or assembled to serve a purpose or to deliver a feature or a project. The squads do something. For instance a squad might build a new account based licensing system that integrates with enterprise identity management solutions and active directory to support our growth in the enterprise sector. We are doing Software Gardening and occasionally something in the garden needs serious attention (read the garden is on fire). For that we have the Rapid Reaction Squad. It protects the other gardeners from interruptions. For 2017 we will probably end up with 6-7 squads. We also try to keep the squads as small as possible. They can be as small as 3 people and should not get bigger than 8 (remember the 2 pizza rule :)). If they do we need to split them.

The guilds are an orthogonal concept and are the home of a skill or craft. For instances we have guilds for Product Management, User Experience, Frontend Engineering, Backend Engineering and so on. That means the guilds are formed at skills boundaries. The guilds try to get better at their craft.

The difficult question was how to align people management with this and how to align this with the locations.

At the end we decided that we can live with distributed guilds, but not with distributed squads, means all squads are in one location (either SF or Dublin). With that we are optimizing for maximum velocity.

We also decided that (at least for now) we want to align the people management with the guilds, which means every engineer “reports” into a guild and is on “loan” to a squad. That obviously means that our guild leaders need to be strong technical leaders in their field of expertise and also strong (distributed) people managers. Interesting job :).

We think that with this we will get a good balance between having enough structure to be fast and successful and not too much structure for our size. We also want to make sure we focus on the essentials, e.g. ensure that the squads are as autonomous as possible.

We will then decide, if and how to adopt more concepts (tribes, chapters, …), when we need them.

2017 here I come.