Jeff Gothelf: Building Successful in House Innovation Teams

Jeff Gothelf left college to run away and join the circus. Not only does he have some great thoughts on keeping innovation fresh within larger, established organisations, he also spills the beans on how the human cannonball works.

A great talk from BoS USA 2013 that looks at the three core elements you need to consider to give your in house innovation teams as much chance of success as you can in your company.

Transcript

Jeff Gothelf: Morning. Audience: Morning. Nice. Excellent. You have this sense that reminds of the psychology 101 course, I signed up for my first semester in the freshman year. It looks just like it. It’s probably this many people in the class and it was on the other side of campus at 8 am. So, I never made it. I’m glad you made it. So, I’m glad you all are here. Speaking of college, I graduated from college on a beautiful day of Saturday in May 1995. And two days later, on that following Monday I joined the circus.(Chuckles) we’ll get to that. Just a sec. My running joke for you is, was that I joined the circus to be a bearded lady. And you know, back in 95 that actually made sense that’s me on the left. These days it doesn’t make sense anymore. It was the Cole Brothers Circus. It was the largest three ring tented circus in America. And I got on in May and I toured with them for 6 months. We worked every day, two shows a day, no days off and we travelled up and down I95.

So we came through here, went up to Hampshire, we came back down. And I met a lot of really interesting and strange and bizarre people over the course of that six month tour. That’s Steven Tyler right here, Massachusetts’s native, Boston native. He would come to the circus with his family and you know he posed with circus folk for pictures. One of the more interesting characters, more interesting than Steven Tyler, that I met was the human canon ball. That’s him, being loaded into the truck mounted canon right there. This man a pretty sweet gig of all he worked 4 minutes a day. Two minutes for show, 2 shows a day, 4 minutes a day, thousand bucks a week. Not bad, not bad for 95.

And this is the way it worked. The canon is mounted on the truck. They drive the truck into the tent, they aim the canon, he goes in, and they fire him. Its spring loaded. There’s a little flash bulb that goes and makes it seem like it’s an actual canon. But its spring loaded, it fires him out and there’s a net at the other end that catches him. That’s it. That’s the show. And so in conversation you know you know I again fascinating people you wonder how they become, how they become the human canon ball. Alright. Not exactly a LinkedIn page for that. And so I ask them. I said,”how did you become a human canon ball? ” one day. He told me, the story actually begins with the guy who was the human canon ball before him, previous human canon ball. And he tells the story like this.

He said the previous human canon ball did exactly the same thing, the same contraption, and the same apparatus. And the way that they would know where to put the net to catch the human canon ball was that they had a dummy that weigh the same as the previous human canon ball. So they drive the truck into the tent, they’d aim it, they’d put the dummy in, they’d fire it. Wherever the dummy landed that’s where they put up the net to catch him. And they did this day in and day out and it worked.

Day in and day out, except for one day. There was a storm and the trucks lot got late to the circus that evening. We travelled overnight, we get there late and we would set up. They didn’t have time to set up and they couldn’t set up because it was raining. And so they decided to set up in the morning but they accidently left the dummy outside in the rain. The next day, they drive the truck into the tent, they aim the canon, they put the dummy in, they fire it, they see where it lands and they put up the net. That afternoon the previous human canon ball gets in the canon, waves goodbye, they fire him and he sails way past the net. That was the end of his human canon ball carrier. He did survive. And this gentleman was actually his pool boy in Florida. And so this was an upgrade I guess for him from being a pool boy to being a human canon ball.

Now what’s interesting about that story is that the human canon ball and his team, the previous canon ball and his team they made the same assumptions everyday that everything would be the same about how they ran their business, how they ran their act. That act was their business. They assumed that nothing would change from yesterday to today. And so they went through the motions everything they did the day before and hope that they would work the same that particular evening without checking their assumptions.

And the reality in their case and in our case as software creators, as makers of products and services is that yesterday’s assumptions don’t work in today’s realities. Now in their case they had tragic consequences. In our case if we can realize that our assumptions don’t necessarily stay the same. Don’t hold water day to day to day. And we can adjust what we’re doing to make sure that our software business is far more successful.

In 2011, Marc Andreessen famously said, “Software is eating the world”. What he meant by that is that everything is software these days. Regardless of the business you are in, regardless of the product that you make even if you make physical products everything is software. Most of now, all of you are in a software business today. And if you don’t think you’re in the software business you soon will be or you actually are. You being in the software business in the software of the manufacture and the distribution and the sales of the product that you make. What business in Amazon in? Right? They’re not in the book business, they’re not in the movie business, they’re in the software business. The software of distribution, of customer intelligence, of e-commerce, of hosting etc.

The same goes for Ford. This is a quote from Ford’s magazine article by Venkatesh Prasad, is one of the tech leaders at Ford. And he says, “There’s an opportunity to now look at software playing a role in really shaping those automotive experiences of tomorrow.” And he continues that article to talk about Bill Ford and how Bill Ford doesn’t worry about making more cars anymore. He worries about making sophisticated computers on wheels. And same holds for FedEx again from that same article.

David Zanca who runs IT at FedEx said, “I run a software company inside of FedEx.” We don’t think of FedEx as a software company but that’s what they are. And that’s the business that we’re all in. And we’ve seen this come along with software comes along they are in combat place and refuse to admit that software is going to change the way they do business or the way that they sell services.

Ten years ago it was Napster, came along and the industry refused to accept it, refused to, they thought it as a threat. And they tried to litigate it out of existence. An artist saw it as a threat. This is Lars Ulrich from Italica and he waged very public PR war an illegal war against Napster to shut them down. Because he didn’t believe that software was going to affect the way that he ran his business. Guess what? Now available on Spotify. Right?

That’s the reality. Same thing happened with Netflix. And the incumbent refused to pay attention. And this is our opportunity. Our opportunities that software is eating the world and that’s the business we are in. And this is also our new reality. This is our old reality. This is how we used to build products in the assembly line industrial area model. And this was great because everything was known. We knew exactly what the end product is going to look like; we knew the components that were needed to build that product. We knew exactly how much it cost. We knew exactly how people would use that end product. And nothing changed. And so this was a process we could optimize.

We could build an assembly line and we could optimize this until it was the most efficient way to produce product. And we build rigid company cultures and company thinking and company processes around the assembly line area. And when software came along, we took that industrial area model and we translated it to software. We took that assembly line model and we built silos. Discipline specific silos, design, engineering, project management, marketing, QA. And we simply structured our projects the same way. We started at the end of assembly line and worked it straight through. With each discipline as the project came through their silo applying their unique code of paint to the product.

But in reality software doesn’t works this way. Software is different. In our new world software is never finished. There’s no end state to software. It’s continuous. And we have to think of ourselves as a part of this way, software is continuous. We don’t deliver a finished product at any given moment anymore. And we have new technologies that allow us to continually improve and iterate on our products.

We build continuous integration systems that allow creating conversations between the disciples the teams work for us, between our companies and our customers in such a way that we continuously get feedback from the market place at a pace that we’ve never been able to before. And because we can get that feedback we can learn. Amazon which is code live every 11.6 seconds. Every 1.6 seconds they push some kind of software live. They taking these tiny bytes of risks. They’re assuming that this may work, testing their assumption, they are learning from it and they are iterating, every 11.6 seconds. If it fails the scope of that failure is tiny. And for companies like Amazon that do this, that continue to deploy product and do continuous integration, there’s no clear sense of what the end state is going to look like. And we all have this capability today and still we are thinking like this. We’re thinking about model years. How many features can we pack into the next release? One is the next release is annual, is it bi-annual.

Reality is that we don’t have to work towards one annual release anymore, for which everything must be perfect, because we’ve got this continuous delivery system. Look, I’ve directed experience with it. How many of you remember getting one of these in the mail? Alright. A few of these in the mail. Sorry. (Chuckles) I was responsible for that. A decade ago I worked at Aiwell. And this is what we worked towards every year. The annual release, the gold master, the GM release right? The gold master used to be in audio business, which is actually what I did in the circus. The Gold master’s the disk from which all the other discs are copied. And that’s what we work towards every year was the GM release of the client, of the software. So that we can package and send them to you. And we worked for year to make sure it was perfect and bug free and that everything was in there, all the new features were there and all the new content. And then we had a year to wait until we get a chance to update our software.

And year’s worth a learning to put back into the next release. And that’s how we delivered software ten years ago. It was shrink rat, it was in a box and you went into a store to buy or we put it in your mailbox. But the reality is in the industry where everything is changing, these tactics don’t work anymore. When you know exactly what you’re building, what goes into, what it looks like and how people are going to use it, that’s terrific. The assembly line model is terrific. The Waterfall model is terrific. But in the software industry everything is unknown. The technology changes regularly, we can’t predict complexity, that’s why we call them estimates, right? We can’t predict costs and we can’t predict the usage of our product. We assume people will use our product a specific way but we don’t know until we actually put it out there.

And when you ask your teams to define its work upfront, to commit to it, and then to work toward those fixed scopes and fixed timing deadlines, you’re setting them up to fail. Because this project is not going to be identical to the last project. Our assumptions have to be tested each time we go through this.

And so as the leaders of software companies, we have to ask ourselves a few questions. And the first is this. Q: What does this new continuous world mean for our business? If we can deliver software every 11.6 seconds, how does this change the way we do business? How does this change the way that we inform our teams, our employees, our customers? Q: How can we take advantage of all of this new information? Holy crap! If you can get feedback from the market on a minute by minute basis, even on an hourly basis that’s a significant new intelligence show. What do you do with that? How do you use it? How do it change the way you build products and what you build? And finally: Q: How can we take all of this learning, all of this new technology and maximize the creativity and the learning and the productivity of our teams? How can we empower them to build the best products possible using this new reality?

And it’s not about asking your teams to innovate. Who knows what that word means anymore? Everybody uses that word all the time. It’s about building a culture of innovation. It’s about putting the foundations in. The infrastructure allows your team to shift into a culture of experimentation and a culture of validation and then ultimately a culture of iterative improvement. A culture of innovation is a culture of experimentation. That’s how we learn. We take a guess, we have an assumption, we run an experiment, we take a guess and we learn whether that’s true or not.

And if we fail that’s okay because the risk is small. That’s how we learn. And with each failure and with each learning we are nurturing our teams in a more accurate direction of the service, the product or the widget that we should be building. It’s okay to admit that we are taking a guess upfront. But let’s learn quickly and as cheaply as possible that guess is accurate or inaccurate. Instead of taking really huge bet and building for a year and then launching and hoping that it will work. One of the books up at the book table is Dave Gray’s, The Connected Company. If you haven’t read it highly recommended.

And in that book Dave discusses the difference between two different ways that become strategies in your company. One is called Deliberate Strategy. The deliberate strategy is the industrial area model of determining corporate strategy. It’s where the executive views the business, sees the problem. Executive is the creative person and the executive hands the solution down to the teams to implement. It’s determined by the executives. That’s who is creative in the company. Now Emergent Strategy shifts that on a tip, flips that on its head. And it lets companies learn and continue to develop new strategies by encouraging an ongoing culture of hypothesis, so guesses and experimentation.

And the key is that Emergent Strategy is all organic. They are bottom up. The teams are empowered to try to fix the problems. The teams have the autonomy to make the right decisions. And the organization has built enough slack in the system so that the failure of these experiments doesn’t disrupt the mainline of business. Now Jeff Bezos buy into this. He talks about how you have to set up to run as many experiments as you can per unit of time. Eric Schmidt has been quoted about taking as many swings as it can with time. Jack Welch the same thing. Using the scale that they have to take as many swings with back as they can.

And so if you’re going to empower your teams, if you’re going to build this culture of innovation and allow them to run these experiments, how do you structure the teams, so that this works. Again, underrated, it’s an underrated flick. The atomic unit of the culture of innovation is a team. This is where it starts. This is the core of, it‘s the team.

And I want to talk about three different ways that we can build and structure the teams in this culture of innovation, to make them as successful as possible. And the three things that we’re going to look at, the three core elements of creating the right team culture for innovation are

1. Anatomy of the team What’s the team made up of? Whose on the team?

2. How do we task the team? How do we tell them what to do?

3. How should the teams work? What process should they use?

We heard a lot yesterday about lean and agile and scrum and SixSigma, lean lights and fragile and these things right?

Let’s talk about how these teams should work once we build them. Let’s kick off with the anatomy of the team. I’d like to start off with (laughs). We’re a few hours from lunch now. Let’s start off with the series of Anti-Patterns.

Four Anti-Patterns of how not to build an innovative team?

See how many of these you recognise.

The first we have talked about is siloed. Discipline specific siloed failed because they isolate team members into their own world. I’m a designer; I’m a developer, I’m a marketer, I’m a product manager. And that diminishes communication between the folks working on the same project which enforce them to rely much more heavily on written communication. And when you rely more on written communication, it takes time.

It takes time to create that documentation, it takes time to read it, it takes time to digest it and it takes time to negotiate over whether that’s the right thing or the wrong thing to build. If you’re working in that discipline specific silo you seem as a line worker. You’re on that assembly line. And things pass through which is sort of you just sort of you know have the pretty picks also. The ones in zeroes or the requirements or whatever is it that you’re discipline does but there’s no feeling that you own the whole thing.

Again, service providers. If you are a silo and you feel like you’re a service provider, there’s no product ownership. You just applying the coat of paint and the product moves through. Teams that work this way don’t have a view of the whole. And what I mean by that is that they don’t really know who they’re building products for. They don’t know what pain points they are trying to solve, they don’t know whether they are building the right stuff. How do we know that these things actually solve the customer’s pain points and so they are making key hole decisions based on the view they have into the world. Without a broader view of how the idea that they are adding to the mix fit into this product, into the product portfolio, into the vision of the company.

And then finally silo team don’t collaborate. They don’t learn from each other, they don’t build on each other’s ideas and they are inevitably implementing someone else’s vision. Not their own solutions. They don’t feel like they own it.

Now look I have direct experience with it. For four years I was the director of user experiments at a company called The Ladders in New York. It’s a job board. Still around today. And when I started there was no design practice. And so I built a design practice. And that design practice was an issue structured like a silo. We were an internal agency. We were the designers; we sat by ourselves and had our own area. And every time somebody needed designed work done, they’d come to me. I was in the centre of this. There I am. Everything kind off come through me. I was the bottom like he needs to design; Bob’s got some bandwidth, terrific. He needs a designer; Bob got a little bit bandwidth. You need a designer; Bob got a little bit more bandwidth. Everything came through me.

That’s how we assigned work, who was available at that time to do the work. And so we are staffing people too in three projects jeep. And what happens is, it doesn’t matter like this is a design example but this can be true for engineering or product management or marketing. When you are staffing people with two let’s say three projects that they work on simultaneously , they are coming in to work every day and you are forcing them to piss people off every day. Because they have got to decide whose broth is not going to work that day? And that’s the situation that I had set up. We’re staffing based on bandwidth. The teams weren’t learning. There was no cohesion; they didn’t want any of the work they were doing. They were simply doing drive-by. I’ll just add some design here. Some design over here. And in the products they reflected that quality.

And what’s the team structure that actually facilitates the culture of innovation? What are the characteristics of successful innovative teams? The first is small. Small teams. Keep your teams small. Six, eight, ten people max. There’s a famous chef pizza teams called the two pizza teams for the British folks in the audience, are these American pizzas? Not British pizzas. So American pizzas not British pizzas. Two pizzas, if you can’t feed your teams with two pizzas, the team is too big. Small teams are great for communication. You know who everybody is and you know how to get a hold of them. They’re great for management. You know what everybody is doing and because they are small, the accountability of small teams sky rock. There’s no one to hide behind. If I’m the designer on the team, the designer, there’s no other designer whose going to work on that. And if you’re programming and not pulling your weight, there’s no one to hide behind. Small teams.

The second is co-location. Now I know Scout was here yesterday and talked about distributed teams, how well they work most of the time. I’m here to tell you that co-location is one of the most important strategies for innovative teams. Everyone’s in a same space. Not just in the same building or the same campus, not in their department but co-located in the same area. They share a space a wall room, whatever it is. I realize that most of us work with distributed teams. I work with distributed teams too. This is the ideal. But if you work with distributed teams and you like to build innovative, collaborative, high- performance teams, they need to be awake at the same time. That’s the minimum. You can work with the tools that that Scout talked about yesterday, you can add in Google Hangouts that’s one of our favourite like Skype etc but you have to be awake at the same time.

I have colleagues in Singapore. Fantastic colleagues. Hugely talented. I never get to work with them ever. And sad, because when I wake up they are going to bed and the opposite is also true. You simply can’t collaborate if you’re not awake at the same time. The third quality of the anatomy of the dedicated teams are that they are dedicated. They’re working on one project at a time. You can actually get work done faster if you work on one project at a time. No one is getting stipend off the fix bugs, no one is getting stipend off to work on another project or the CEO’s pet initiative. Everybody’s working on the same thing at the same time.

And then finally perhaps more importantly is that the successful innovative team is self sufficient. Everything that team needs to do can be done by the competencies on that team. If he did engineering, design, develops, QA, marketing whatever it is, it’s on the team. And equally it is important that the team is empowered to make its own decisions. So, now they can do what they need to do and they can do it without consequences. They’re empowered to make decisions to launch products and to learn from that. Those are the four qualities of successful innovative teams from anatomy of successful innovative teams.

The next thing I want to talk about is tasking the team. How do you tell the team what to do? We talked about emergent strategies, we talked about deliberate strategies. Let’s start again with a series of Anti-Patterns. My favourite is this one. The road map. How many of you make product road maps? Yeah, I make them too. Sometimes. Roadmaps are great. They tell a compelling story. We’re here and we’re going over there. Right? It’s easy to see progress. There are 12 steps between here and there and one step three, nine more to go. See delays, you can tell the delays out of clear vision. And more often than not, roadmaps commit to a fixed scope and fixed time. We’re going to launch in November with all of these features.

In reality this is what most roadmaps look like. Because when we think about it, when was the last time a fixed time and a fixed scope project actually met both the deadline and the initial scope that you laid out? One of those things typically moves. Back in May, Kent Beck whose one of the office of the Agile manifesto, he tweeted this. He wrote, “Product roadmaps should be list of questions, not list of features.” This should be hypothesis about what we believe will solve our business problems. Not a list of features to go and build. Because if we blindly, heads down and go forward and just build features based on this roadmap, we end up incentivizing our teams for creating output. And if the teams are just blindly creating features, you end up with bloated products. They don’t meet the needs of a broad customer these days. This guitar can only be played by one man. That’s Pat Metheny.

But again, as you start to build features into this the product becomes useless to a majority of your organisation. And so what we need our teams to focus on- our outcomes. We need to task our teams with figuring out, how we choose specific business course. Because again you can launch all the features in the world and they can still suck. Alright. And so the questions we have to ask ourselves is we task our cross functional team is what role they help in determining what features to build? And what changes when you give a tem an opportunity to pick its own solutions. And then how do we build customer insights into determining what to build. The final Anti- Pattern I want to cover is The Annual Planning Process. Many companies that I work with today are walking down 2014 now. They’re locking down features, budgets, resources what they need without any idea what actually happen next year. And the truth is we can’t predict the future and yet we continue to fix our processes and our timelines for next year. I give you an example of that.

This is from my time at The Ladders. The Ladders have been in the business for long time and it assumed a couple of years into my ten years there growth having flat line. So subscriptions had flat line, revenues had flat line, retention had flat line, everything had stayed the same. The CEO of the company being the founder of the company did what he had always done. And he brain stormed by himself. And when one day he came down and said, “I know how we are fixing this.” And he shut down entire consumer facing division of the company. And he turned his almighty axe and said head in this direction. And the direction that he picked for us was that he said we are going to provide a person in New York, a job search assistant for every paying subscriber to The Ladders.

So if he paid us money, which everybody did to read and apply to jobs, you’ve got a person in New York through which all your communications went, emails, phone calls etc. They’ll provide you good insight and how to improve your job search and how to be more successful. Now to do this, we had to re-design the website, re-design the acquisition flows, rewrite all the emails, redo all the marketing, buy new phone systems, install them, higher staff, train them.

We spent nine months and 50 people worth of time to find out that this ides wasn’t going to work. Because six months after we launched it, we shut it down. And again the deliberate strategy mentality is how we initially react. I know how to fix this. Instead what we should have done in this case is we task teams to achieve business outcomes. What were the business outcome we were trying to achieve? Let’s increase retention. Terrific. Let’s put a team on figuring out how to increase retention. Let them come up with ideas and wrapper the experiment through this. And when you give teams these outcomes you need to get granular. You can’t task a team with moving customer satisfaction or revenue. There are too many factors that affect those high level matrices.

Instead ask the teams to increase retention. To increase the log and success rates at the home page. To increase the number of times a customer visits each month because you can directly tie what a team small cross functional team is doing to one these more granular matrix. Task them with the outcomes and then give them the opportunity. Give them an opportunity to come up with their own solution and not to implement your solution or the boss’s solution. Let them guess how to solve this and give them the freedom to get it wrong. Don’t fire them if they fail. Make it okay for them to push back and say that okay this is not a good idea and we should do something else. And what happens is that they imprint themselves on the work, they own the work, they become far more passionate, far more productive and far more successful. And we should give them an opportunity to figure out what a good solution looks like, they own the solution. This might be a good solution or not. They learn if let them what solutions are potentially ridiculous and shouldn’t be implemented.

Now the final of task the team is how do we fund them? How do we fund the team? We put together this small cross functional team, they’re self sufficient, they’re empowered. We’ve given them a business problem to solve; we need to figure out how to fund them. And the way that we do is through iterative cycle, not unlike the way the team is working. You’ve got your small team. They are trying to figure out how to validate specific business model, they’re trying to figure out which products and features actually service that business model. And they are doing this quickly, on a regular basis.

Now around that you have to build the funding infrastructure that allows that team to come up for air periodically. Every two months, every three months in front of the organisation, in front of the stakeholders to say, we’ve been working from three months to increase the login success rates of the home page. You task this with carrying the 40 percent we’re currently at 27, we started with 14. Can we have another three months? And the organisation then decides, yes you can have another three months. You’re making good progress. You know, we have decided this is not a priority for the organisation anymore. But you doing the same things with your budgets that you’re doing with your features is you are taking small risks. And you’re deciding continuously if you need to deploy funds in this direction.

The third thing I want to talk about is how these teams should work.

So we have described who is on the team, we have described how we give them work to do. the last thing I want to talk about is how the teams should work. And again, Anti-Patterns to look at. One of the biggest Anti-Pattern of how these teams don’t successfully innovate is no cross-function collaboration. These are more pictures from the circus. That’s the elephant act on the left, in the middle there are these amazing women who walk on these giant balls up and down ramps. That was the trick they did and the gentleman on the right served our food three times a day, should we have chosen to eat it.

But what’s interesting about the circus. It was a very linear experience. There was no collaboration between the acts. Everything was very guarded. And this is what we do, we are the elephant trainers and this is what we do. logistics was the only thing that determined the order of things in the circus. We have to build the lion’s cage before the elephants come out. Actually how things determine. But imagine what could have been if the tiger trainer would have collaborated with the human canon ball. Or something along the line. Amazing things. He could have flown right over the cage. Anything. The ability of these acts to think together wasn’t there. It wasn’t something that they would do. This was a traditional conservative circus.

And the same thing happens with software silos. When teams feel like service providers and there’s no cross functional collaboration. The next Anti- Pattern of how these teams should work is Fixating on Job Titles. We like to put people in boxes. We like to put labels in people that help us tell them what they can and can’t do. And by doing that we limit their creativity and we limit that contribution to their team. In some cases I’ve the heard the folks being reprimanded for stepping outside of their boundary of box of their job. My business card says designer, that’s all you can do is design. My business card says engineer, that’s all I can do.

Anybody knows who this guy is? This is Jeff ‘Skunk’ Baxter, legendary guitarist and

Jeff Gothelf

Jeff was the Principal UI Designer at AOL and other Internet companies in another life before becoming a consultant, author (Lean UX, O’Reilly) and co-founder of  events including Lean Day and Agile UX NYC.

He now works with companies of all sizes training them in Lean at scale, the intersection of agile and user experience and great team collaboration. He is writing a new book in collaboration with Joshua Seiden, Sense and Respond.

More from Jeff.

Next Events

BoS Europe 2025 🇬🇧

🗓️ 31 March – 1 April 2025
📍 Cambridge, UK

Spend time with other smart people in a supportive community of SaaS & software entrepreneurs who want to build great products and companies.

Save your Spot

BoS USA 2025 🇺🇸

🗓️ To be announced soon
📍 Raleigh, NC

Learn how great software companies are built at an extraordinary conference run since 2007 to help you build long term, profitable, sustainable businesses.

More Details