Spotify’s DNA of Autonomy and Collaboration
The Agile Zone is brought to you in partnership with Hewlett Packard Enterprise. Discover how HP Agile enterprise solutions can help you achieve high predictability and quality in your development processes by knowing the status of your projects at any point in time.
Anders Ivarsson, an Agile Coach from Spotify, was kind enough to present his talk from Agile Ísland at our company on Friday morning. It was ostensibly about “scaling agile” but really it was a talk about how they’ve created a culture that prizes autonomy and collaboration.
I’m personally tired of hearing about how new, growing, successful businesses do things. In most cases, these evangelists really have no idea, and all you get is a post-mortem about choices a company made and tools they use, wrapped up in a presentation that these choices are integral to the company’s success and you should listen. In reality, most of the choices are made for no real reason, it’s just the way things turned out, and who knows if the company is successful because of these choices or in spite of them. And of course we don’t know if these choices led to an actual profitable or sustainable business or how they adapted to times when money wasn’t pouring in.
I felt different about this Spotify presentation even though it fit the mold. The reason is because Anders spoke very little about agile tools and very much about how the company is structured around autonomy and collaboration. Autonomy and collaboration are built into organizational structure. It seems monumentally difficult to create a command-and-control environment at Spotify. You’d have to restructure the entire company, top to bottom. Which means that a few bad apples (any company doubling its size every year has more than a few bad apples) won’t ruin the bushel. It would take a concerted effort of senior management to change that DNA, not a few incompetent bad hires.
This is the total opposite to most agile success stories you probably know of, where success is limited in area but especially depth and time, because most people are working in a command and control structure (even if the company doesn’t necessarily operate in a command and control fashion). Without structural reform, you can’t really do more than scratch the surface of truly agile or lean changes. And without structural reform, when a bad apple comes along into a ‘command and control but currently agile’ situation, all progress can be wiped away and it is incredibly easy to slip, almost immediately and without anyone observing, into a command and control system.