An evening with Jeff Gothelf

Last night I had the pleasure to hear Jeff Gothelf, author of the wonderful book “Lean UX – Applying Lean Principles to Improve User Experience“, give a talk on the topic “How to build innovation teams”. I thought I’d give a brief report on what Jeff had to say and offer a few reflections of my own. I’m also very happy to report that Jeff’s thoughts that you’ll read below are basically all fully implemented in our shop. You can read more about that here.

You can also see the talk for yourself here, courtesy of Valtech. 

Jeff starts by setting the stage with a few powerful messages.

First, he wants us to understand that innovation is important, and provides a few examples of why this is so. I agree.

Second, he wants us to understand that everyone is in the software business. “Software is eating the world”, is a pretty powerful quote (quote is from Marc Andreessen)

He is right about that too I think.

Third, you cannot build software using industrial era management tactics. There are simply too many unknowns in the software game. You need to have a continuous conversation with the market place and use short feedback loops in order to manage the uncertainty. Here too we will agree.

Fourth, you cannot sprinkle innovation on top of your muffin, you have to include it in the dough, so to speak. Again, I agree with this.

Fifth, software is never finished. It’s continuos. Agreed.

The conclusion from Jeff is this important message:

In order to survive we need a culture of innovation and experimentation. 

Now, if you like me find yourself in agreement with the views expressed above and the powerful conclusion, this leads to a few questions. One, is a question of strategy:
Jeff describes how there seems to be two types of business strategy:

First, we have the deliberate strategy. This is old school, where the top executives decide on the way forward because they’re supposedly better at looking into the future.

Second, we have the emergent strategy, where we push as much as possible in terms of decision making down to the teams, and provide them with enough slack so they have time to experiment. The emergent strategy is for those who understand both the power and the risks of the unknowns in our industry, and grasps the intelligent way to address this reality.

This was only touched upon briefly, yet in my experience this is a core question. That which happens strategy wise at executive level can make the deployment of balanced cross functional teams a rather useless exercise. Without top management buy in and without the necessary change of mindset, any experiment with cross functional innovation teams is doomed from the get go. We are happy to have that support at my shop. Without it, we’d be completely unable to operate this way.

Moving on: Jeff says that at the centre of a culture of innovation we find the team. This is the business unit, so to speak, where the magic happens. This poses the question, the reason why we’re here: What then makes up an innovative team? To dive into this, Jeff turns to three fundamental points:

1. The anatomy of the team
2. How do we task the team?
3. How should the team work?

1. Anatomy of the team

To answer this Jeff starts with a few anti-patterns. This is how not to build innovative teams.

1. Work in silos
2. Treat the team as service providers (i.e code/design monkeys)
3. Make sure the team has no view of the whole and force people to make keyhole decisions.
4. Prevent collaboration

On a brighter note, what then should you do?

1. Keep the teams small (6, 7, 8 ppl)
2. Make sure the team is collocated (actually sitting next to each other)
3. Make sure the team is dedicated to ONE project
4. Make sure the team is self sufficient. That all the necessary competencies are represented.

2. How do we task the team?

Again, some anti-patterns: How not to go about this:

1. Write detailed roadmaps and commit to them – you’re fixing time and scope. Not good.
2. Have annual planning process – change happens a lot faster than you think.

Here Jeff pulls a wonderful quote from Kent Beck, well worth repeating:

“Product roadmaps should be a list of questions, not features”


But then, what to do?

1. Task teams to achieve business outcomes. Not incentive them for creating output, which risk leading to a bloated product impossible to love.
2. This means giving teams a problem to solve, not a solution to implement.
3. Let the team own the solution. Too detailed roadmaps leaves little room for this. Use caution.

3. How should the team work?

Again, some anti-patterns: How not to go about this:

1. No cross functional collaboration
2. Fixation on job titles (engineer, designer, project manager)
3. Fear of failure (learn to tell difference between actual bad failure and good failure which leads to valuable learning)
4. Use arbitrary deadlines
5. Destroy possibility of team ownership

What to do then:

1. Take smaller risks – work in small batches – move incrementally from uncertainty towards certainty
2. Have clear definitions of success – make it objectively measurable
3. Promote competencies over roles
4. Support self organisation

And that’s about it. It was a great evening and Jeff’s book is a good read for sure. My thank’s to Valtech for making this happen.

Leave a comment

Your email address will not be published. Required fields are marked *