
“Hi, everybody. My name is Dejan and, … well…, I don’t play games (gasp). There, I’ve said it. This feels so liberating, I am a bit lightheaded. I think I’m going to sit down now.”
I cheated a bit in my pretend-address to the local Non-Gamers Anonymous chapter. I did play Microsoft Flight Simulator obsessively for years, but that is more of a gateway drug to real flight lessons than a multi-person shooter. Most people who tried it lost interest when they realized they cannot fire at other planes, promptly crashed their Boeing 737 and moved on to fight trolls and solders in a futuristic dystopia.
All these gaming-intolerant impulses kicked into high gear when I read the Spotify engineering model white paper. In case you missed it, Spotify is creating a stir with their new way of work organization. In a nutshell, they organize people into co-located feature teams called squads that have all they need to deliver a feature relatively independently. Several squads are organized into tribes that tend to be limited to about 100 people to prevent social connections breakdown.
Since squads are self-reliant, it is easy to envision a situation where the same problem is solved multiple times by squads that don’t communicate. To avoid this massive waste, like-minded squad members organize into chapters that share the same general knowledge (Web UI, iOS/Android, Design, Test) and a line manager. This provides organizational glue and prevents duplication. Finally, chapters are connected into guilds in a looser way, ensuring sharing of ideas and best practices.
The gamers are coming!
One of the first concerns that people have voiced was ‘how is this different from matrixed organizations’. I find guilty pleasure in observing these kinds of questions because they remind me of another debate closer to home, this one on how micro-services are nothing more than SOA.
But listen – oy with the gamification already! I explained the basic premise to my 18 year old son (an avid gamer) and even he was rolling his eyes (calling the lingo ‘juvenile’). The World of Nerddom is spilling into the rest of the reality with a vengeance that sometimes verges on bullying (yes, I get the irony). Case in point: a presenter at a recent NodeSummit suffered ironic remarks by the MC for daring to bring a Windows laptop to the stage, and not the all-beloved Mac (and I am typing this on a sweet new MacBook Pro; I just don’t like bullies, male or female). And now there is a growing chance another outgrowth of that world will become your everyday working reality.
Spotify is a young, rapidly growing company, and the main source of music for my teenage daughter. I am sure that game-playing millenials that I can see in the company photos feel very comfortable with guilds, tribes and squads. Their model is irresistible in that it addresses so many paint points that feed Dilbert cartoons. Their two-part video is smart, wonderfully animated and easy to follow, and many of the messages will ring true and soothe your pain if you spent any amount of time in an old enterprise work process.
What I find problematic is when those same enterprises latch on it and try to apply it in their own (very different) context. One of the reasons they would do it is the assumption that a successful implementation in a fast moving company gives it a seal of approval. Some of it is sheer survival instinct – everybody needs to move fast these days, and if your traditional org chart is slowing you down, you need to change if you want to be around in five years. Finally, and to be fair to large enterprises, it is really hard to find a true command-and-control organization these days – some variation of Scrum or Kanban is a norm virtually everywhere. Spotify provides a simplifying refinement that attempts to address the observed shortcomings.
It is not a religion
I see two problems with adopting Spotify model as-is:
- It is a moving target. White paper authors themselves pointed out that it is entirely possible that by the time you implemented the squad/tribe/chapter/guild model, Spotify will have moved on to the next refinement of it. A kitschy version: you can’t capture the wind or the waterfall – you end up with dead air and stale water, respectively (rim shot).
- It uses gamer-friendly terms. It assumes that everybody in the industry is a gamer and is instantly familiar and reacts positively to the images these names evoke. I cannot help but giggle imagining a bank IT shop where executives arrive and declare: “all right people, all of you on this floor are now the Stonehoof tribe. Stay tuned for the org chart to find out which squad and chapter you belong to. Guild masters are currently working on their corresponding chapter lists”. It is not even a generational thing – believe it or not, there are young people who have better things to do than kill hours working on their WoW reputation (and virtual gold). And yes, there are middle-aged clan leaders. Sadly.
Test out carefully
There are many worthy ideas in the Spotify engineering model. Some of them are a refinement of the matrixed models from the past. Most can be used without all the gaming jargon that goes with them. Discussions I had so far point at exactly that – savvy organizations will filter out the startup exuberance and latch on the more lasting nuggets. All of them should be treated as an experiment in the event they end up working only for Spotify (or in the event Spotify has already outgrown them).
And finally, the goal is to enable teams (squads?) to be agile and deliver results with the speed of the cloud. If that does not pan out, you just spent a lot of money re-arranging chairs on the Titanic. And called yourselves silly names that should be left behind once you reached your twenties.
Pardon the grumpiness. Hey, I may end up liking it after I live it for a while. Now if you excuse me, I have to go work on my LARP uniform. War is in the air.
© Dejan Glozic, 2015
My thoughts exactly.
My impression is that many project leads only look at spotify from a project management perspective. They think all they need to do is call their teams “squads” and tell them they are responsible for build, test, i18n and documentation – without considering the technical prerequisites. There is a small thing on that spotify chart called “decoupled releases”. This needs to go first to make squads truly autonomous. But it also requires a thorough rethinking of the project’s architecture (which happens to be a monolith in most traditional enterprises) – this is were you need to spend a couple of sprints before even thinking about going for squads. And I have yet to see that work out somewhere else.
Also don’t forget: Spotify is a startup with hundreds of developers working on exactly one “product”: spotify.com – Most projects in traditional IT shops have like 20-40 people per project. How many tribes/chapters can you get outta that?
Yeah, and it is obvious from the videos that Spotify uses micro-service architecture without calling it out by name.