Transcript of my speech from OPEX Week Summer 2018

I was delighted to be invited to speak and participate on a panel at the OPEX Week Summer conference today. While it is not my specific function, I do learn a lot from understanding other disciplines and industries.

Below is the text of my speech.


In the software industry today, we can change our product daily in response to direct, instantly measured customer feedback. We can trivially give different versions of our products to different customers to see which they like more. We have figured out how to reduce the time from idea to customer value to revenue from years to days or even hours.

Some of you are thinking, “that would be great to be able to do that in my industry.” Some of you are thinking: “what a nightmare, how do you plan, track and manage in that environment?”

The thing is that when I started in the software industry, it didn’t work this way. We would spend months designing and planning, then we would build the new product, then we would ship it to customers, and then we would start on the next product. It would take years. If we misjudged our customer needs, it would take us years to find out and correct the issue.

For software, it was the revolution of the internet that allowed us to break free of our old industrial manufacturing paradigms. It was a two-edged sword though because the platform that enabled us to become more lean and efficient also lowered the bar to competition. The speed of innovation is now the critical aspect of success and survival. Easy access to investment has reduced the value of efficiency to less than zero. Companies can lose money indefinitely if they can show continued growth. If we, the market leaders become complacent, a much smaller competitor can come from nowhere and take our market away instantly. The barriers to entry are now lowered significantly.

What I am describing may seem interesting, academic or even obvious, to some of you. “That’s nice for you” or “too bad for you over in software” you might be thinking, “but my industry is different.” Tell that to the taxis, or the automotive manufacturers, or retail.

Just as we in software improved our agile and lean software development processes by learning from TPS, Deming and the established OPEX practices and literature, we can share what we have learned back with the larger OPEX community today.

This talk is a short talk, so I will focus on one way we’ve found to improve innovation velocity: a true autonomy culture.

For me, an autonomy culture starts with Toyota and its’ Kaizen.

Kaizen pushes responsibility for improvement through the whole organization and puts the decision making closer to where the knowledge is. However, for the companies I know and have spoken to, kaizen is usually used to make efficiency improvements to the process, not to the product itself.

If you want to bring more innovation into the product, you must find how to bring autonomy to more levels of the organization
* empowering teams with access to the customer
* Giving them the ability to perform low-risk experiments to validate their hypotheses
* Using data to inform their decision-making and measure their effectiveness

You are changing the model of the organization from plan/command/control to inform/inspire/measure. It’s a real culture shift. Leadership sets the direction and high-level strategy and each team in the levels below figures out how they should approach their part of achieving that strategy with increasing levels of specificity.

The inform/inspire/measure model was how we worked at Spotify, it was how we evolved to function at Avvo, and this will be how we work at AstrumU as we grow.

If you are hiring smart people, you should be taking advantage of their intelligence and creativity. If you are not hiring intelligent people, you need to look into why you can’t trust the people you hire.

For your teams to be successful, they need access to their customers. They need data. Find ways to instrument your product to give data on real-world use back to your teams. If that isn’t possible, share the data from your user research, industry and market trends, your user testing, competitive analysis and your product focus groups to your whole organization.

Data can also help establish accountability. Work with your teams to develop real data-driven business metrics that they can be uniquely accountable for. Avoid vanity metrics or non-objective ones. Every team should be able to tie what they do back to the core business of the company, even if what they do is support the other teams. Empowering other groups to be more efficient will help drive your core business outcomes.

If your company isn’t data-driven today, you may need to train your teams to understand and utilize data. This training will not be a wasted effort.

At Avvo, we created a data-driven decision framework. We trained everyone in the company in its use. It was our version of a Kaizen card. It required the employee to validate their thinking with data and validate their decision’s success or failure with data as well. As a deliberate side-effect of this effort, data became a central part of our processes and discussions.

Teams armed with the context they need to make smart decisions, and tools they can use to measure outcomes objectively against the broader business goals, can be given more autonomy.

There is one more thing that is needed though before the organization can truly embrace this model: ways to limit the risk of failure.

Innovation requires failure. You can’t do something genuinely new without making mistakes along the way. If we want our companies to be more innovative, we need to reduce the risk of failure. Data reduces risk, but it alone isn’t the answer.

You need to find areas where each of your teams can experiment in the market in limited ways with actual customers. With rapid prototyping tools and limited run manufacturing capabilities this has become increasingly easy over the last decade. Giving teams this ability lets them experiment and learn rapidly by giving them the knowledge they need. In turn, they can innovate without putting the whole company at risk.

What of governance, compliance, oversight, quality and process control? These things are still as vital as they ever were, but the way that they function will need to evolve in an autonomous enterprise. They need to be integrated and intrinsic, part of the DNA so that teams incorporate them naturally into their experiments, and for the areas where this is most critical, the groups may need that expertise integrated into the team structure as opposed to externally applied.

I discuss this with you as a thought exercise, a different way of approaching innovation in your organization. It is working wonders for us over in the software industry. I have spoken with high street banks in the UK, large department stores in the Netherlands, multi-national financial institutions, heavy equipment manufacturers, personal grooming appliance makers and others looking into these ideas of autonomous teams to bring more innovation into their practices.

If it is possible for them, then it is entirely possible for you.

Thank you

Slides from my talk on Distributed Teams

Compare the Market was nice enough to invite me to speak at their tech managers’ off-site about distributed teams. This talk reflects my own experience leading distributed teams.

I was presenting to them over video. Their meeting included people in two different offices and also folks dialing in from home. Ironically, in the middle of my talk, I got disconnected from the video conference. Because I was sharing my slides full-screen and had my speaker notes on my second monitor, I didn’t notice. So I spoke to myself for about 15 minutes before I realized what happened and dialed back into the meeting. It was a bit mortifying, but the folks in the UK were extremely nice about it. I can’t think of a better example though of the challenges around working with teams who have to communicate over electronic means constantly, so it was a good illustration of the issues I raised. 🙂

Talks: 1st half 2017

I’ve been remiss in posting since I’ve been back in Seattle. Readjusting to life in the states, and adjusting to the new role has kept me busy. I hope to rectify that in the future. I have been lucky enough to be invited to speak several times this winter and spring in the US and Europe. If you’ll be there or live nearby and want to meet up, drop me a line on twitter and let me know!

How Spotify Builds Products – my slides from May 2016 talks

These are my slides from the talks I gave at infoShare in GDansk and to ao.com and Think Money in Manchester. The talk in Poland was a shortened version of this content. This is a sort of mega-mix of many of my previous talks. This talk ends up presenting a bit more of a coherent picture on how Spotify’s culture and organization go hand-in-hand with it’s data-driven product development.

As with most of my talks, the majority of the content was in the spoken parts instead of the slides. I will hopefully have a video to share soon from one of these talks…

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.