Innovation, Autonomy and Accountability: my talk to the UK Department of Media, Culture and Sport

I was asked to speak at the UK Department of Media, Culture and Sport in January. One thing that often comes up when you talk to people about autonomous organizations is the subject of accountability. This is something that we even discuss within Spotify, from time to time.

When talking to a government organization, especially one who is responsible for distributing funding for programs, like the DCMS, the concern around accountability is paramount. At the same time, governmental organizations are also looking to innovate to provide better services to their constituents.

My goal with this talk was to present the idea of how a governmental organization could innovate by using autonomous teams while maintaining accountability by picking good metrics to measure success of programs and measuring those metrics on an ongoing basis. This would allow the programs to have autonomous control of their work and innovate, while having a objective measurement of the value that they were returning.

A response to the IEEE article: Yahoo’s Engineers Move to Coding Without a Net

http://dilbert.com/strip/1996-07-01

link to the article

First, a disclaimer

Let me start out with the understanding that the article as written is being interpreted through the writer’s own biases and background. I certainly have been misquoted or had a radically different interpretation of my words by an author than was meant.

This is a response to the article as written. I would be happy for someone from Yahoo to let me know if they feel the article was an accurate depiction or not.

Yahoo’s new approach to quality is something many other companies already do

What yahoo learned is what many other companies have learned a long time ago. That segmenting test and development is a bad idea. It leads to developers and testers living in their own silos and playing a blame game on each other. Agile methodologies challenged this idea 16 years ago. Having separate test and development teams is a pretty big red flag for waterfall development.

It wasn’t the fact that there were QA that was the problem

Taking away QA can improve quality to a point because it makes quality everyone’s job, but it won’t get you a high-quality product. You could do that by creating a culture of quality, making everyone feel responsible for quality and keeping the QAs on the teams. You can’t find every bug in the product through test automation. Developers tend to be poor testers of their own code, because they expect it to work and they have a hard time using the product like a non-developer. Having someone on the team with an expertise in quality thinking and a user mindset can do real wonders for product quality.

What Yahoo should try next in their quality evolution

Yahoo could also have increased quality and velocity substantially by keeping the QA, integrating the teams of developers and testers and by creating a culture where everyone feels responsible for the quality of the product. I contend that in their evolution they might yet find another factor increase in these by doing exactly that.

Nice deck from Dan McKinley of Stripe: Choose Boring Technology

As you grow as a developer (and development leader) and you work with more and more technologies over time in different projects, you start to realize how easy it is for the team to get more focused on the challenging technical problems than the actual product issues. Ignoring the product issues will kill the product (and possibly the company). With limited attention (he calls them innovation credits), it is best to put your effort into innovations that can differentiate your product. All too often, teams get more focused on the next cool technologies, turning everything into a nail as the old saying goes.

Dan McKinley does a great job explaining this in his talk below.

Video of my talk “Apportioning Monoliths”

This was my talk at the Daho.am conference. Listening back to it now, I am struck by how often I said “many, many.” And I cursed! I usually try not to do that. So, it’s a bit of a looser take on this presentation. Luckily the audience had beer (this was in Bavaria, after all), so all were fine with it. I had flown in from Stockholm that morning, so I might have been a bit more tired than I thought…

I was really impressed by the lineup of speakers and the content of the presentations. A really good day. The Stylight engineering and event teams did a great job.

The Spotify Tribe: My talk from Spark The Change last week

The organizers of Spark the Change in London asked me to speak about the Spotify matrix model. I was only too happy to comply. It was a great conference, and I met a ton of good people. As usual, I tend to talk to my slides, as opposed to putting a ton of text on them. Hopefully, you can still get something useful from it.