Very interesting document from Henrik Kniberg & Anders Ivarsson on how they’ve structured Agile teams @ Spotify for maximum damage.
Earlier this year, we saw the Valve Employee Manual that had wonderful visualizations of how they say things are organized there. The model works for Valve in their blockbuster oriented industry as Don Alvarez put well in this post.
At any rate, this all builds on some slow hunches I’ve had regarding how organizational structures either enable or disable market driven products and rapid response teams. How do you realize the “learning organization” vision that Eric Ries and Steve Blank advise, the ideals of Agile / Continuous Development against traditional waterfall?
Adam Pisoni of Yammer had some interesting thoughts on the subject on how they do it there:
At Spotify: The smallest functional unit is a “squad” that behaves like a Lean Startup in themselves, focusing on a specific function and iterating a minimum viable product continuously. There are 30 squads totaling 250 people across 3 countries.
Making the squads play nice with each other means sorting them into “tribes” of less than 100 people – cutely based on Robin Dunbar’s number of how many effective social relationships you can maintain. There are in turn larger groupings called chapters and guilds.
Some other interesting points:
- As standard issue Agile goes, they have Product Owner and coach / Scrum Master roles and quarterly performance / trend reviews with each squad.
- “Scrum of scrums” held on demand to discuss dependencies. In practice, I’ve found this depends on people’s ability to think in systems and consider cross functional impact, so you need people who are good this.
- One downside to autonomous teams is a loss of systemic efficiency e.g. duplicating efforts and losing learning across squads. Chapters and guilds are a solution for this – chapters are based on similar skills, guilds on broader communities of interest.
- System Owner concept to mitigate risks in architecture by having one throat to choke on key system issues. I firmly believe this architect function is necessary to keep all the parts working together.
A couple really important systems design aspects to me are that the teams have everything they need to produce in their respective areas, including autonomy / decision making power within their mission scope. There’s a joke in product management that leading without authority basically amounts to making a suggestion until someone with actual authority comes along and exercises it.
I think Joel Spolsky nailed it in this article – a single great person in a top down command and control structure cannot possibly work as well as the distributed intelligence of teams:
In tech startup land, we all understand instinctively that we have to hire super smart people, but we forget that we then have to organize the workforce so that those people can use their brains 24/7.
Thus, the upside-down pyramid. Stop thinking of the management team at the top of the organization. Start thinking of the software developers, the designers, the product managers, and the front line sales people as the top of the organization.
The “management team” isn’t the “decision making” team. It’s a support function. You may want to call them administration instead of management.
“Hiring smart people and getting out of their way” is a cliche often regurgitated when selling people on an organization but power and politics are usually determined by structural elements. Just like one measure of power is how much budget you can spend before asking someone for permission, there are usually structural checks and balances that slow people down from getting stuff done.
The common thread remains that how systems and teams are structured relates to how responsive your products can actually be in the market. This is a somewhat facile organizational design statement, but one I’m drawn to in thinking about how systems and organizations can be designed to sharpen the pokey end of the solution spear and apply learning more rapidly.