Guest post by Lisa Regan, writer for The Lean Startup Conference.
Our fall webcast series concluded on a high note with three extraordinary conversations about the origins and implications of Lean Startup. If you missed these when they went out live, we encourage you to watch them now, as they lay a strong foundation for The Lean Startup Conference, December 9 -11 in San Francisco—less than two weeks from today. You can also listen to any of the webcasts, which, at the suggestion of a webcast attendee, we’ve turned into podcasts you can stream or download (from iTunes or SoundCloud). None of the webcasts included slides, so the audio versions work really well.
Below are just a few highlights from our final three webcasts: 1) Eric Ries’s one-on-one conversation with Kent Beck about influencing other people; 2) Eric’s conversation with John Shook about the origins of Lean, and 3) a conversation between Diane Tavenner and Steven Hodas, moderated by Sarah Milstein, on applying Lean Startup ideas in education.
Eric’s chat with Kent Beck was among our most entertaining webcasts (video; iTunes; SoundCloud). Kent, a veteran programmer, a founder of the Agile method and the creator of Extreme Programming, came armed with anecdotes and lessons from his own experience, as well as a few questions for Eric. For example, at 12:56 in the video Kent describes how he made the move from programming to a role that he at one point describes as “Full Metal Guru”:
“It turns out you can be a bad enough programmer to sink a project, but you can’t be a good enough programmer to make a project successful. So I quickly ran out of gas on projects being more successful, and I was forced to take a bigger, broader view of the context in which programming happens. I started to pay attention to things that worked, and to things that didn’t seem to make a difference or actively harmed development. I’ve always been a contrarian, and so if someone says, ‘X is always true, I always think, then what are the implications of not-X?’ As a reflex, I always think that. So if someone says, ‘You need comprehensive documentation for software documentation,’ I think, ‘Well, what if you didn’t have any documentation at all? Would that really be a disaster?’ And I looked around at projects, and it wasn’t a disaster. So I thought, well, maybe a commitment to communication is good enough and the actual form of the communication is something we could be a little bit flexible on.”
The result of that kind of contrarian thinking was Extreme Programming, a method for running programming through feedback loops, testing and iterating on it as quickly as humanly possible. Nowadays Kent is programming again, this time at Facebook, which he describes: “It’s a laboratory. It’s really smart people working on unprecedented problems at ridiculous speed. So I get to see this hothouse of software design. I get to see generations of technology that last six months instead of lasting for six years. And so I can see many more cycles through the loop of how software evolves, how innovation disperses in a community, and so on.”
The enjoyment Eric and Kent shared in talking to one another comes through clearly in their conversation and led to an interesting exchange when Kent asked Eric how he had made the move from building things (programming) to an interest in influence in a broader sense. At 32:30, Eric offers this candid explanation:
“When I was younger I was convinced that programming was the most fun thing I would ever do and I’d be very happy to program increasingly large systems myself. And I think basically what happened was I kept doing that, and not having the impact I wanted to have. Because in my fantasy I could produce a massive program that’s used by billions of people and has enormous complexity and is incredibly innovative, by myself. Just, you know, with my bare hands. But the truth of any program is, it requires teams, and customers, and it’s this complicated ecosystem…. So the person who’s considered the ‘founder’ or the person who created the complicated system, it doesn’t matter if it’s Linux or Facebook or anything, somebody had to plant that initial seed, and that’s very satisfying.
“But in order for us to remember it and to care about the fact that they are the founder of that thing, they had to do an incredible amount of management of people to get them to grow that seed into something that is significant. And what’s frustrating to me–it was then and it still is–is that as soon as I became a manager and a team leader and an architect and really thinking out how to do that stuff, I was doing human systems engineering and I was no longer making things with my bare hands. And so I’ve also had that frustration. Now, that’s frustrating but also very satisfying, in that I’m very proud of the things that teams that I’ve worked with have built. But for me anyway, that transition from being a team leader to whatever it is that I do now, to try to cultivate this community and try to share these ideas on a wider scale–that was actually a much easier transition than going from an individual contributor to a team leader. Because to me, it’s like, as soon as I was not making things myself, with my bare hands, it’s all about, ok, then what activities will give me the greatest influence to have the impact I want to see in the world?”
The conversation also turned to a subject on everyone’s mind the last month or so–the healthcare.gov website. Kent’s analysis, which is largely political-process-driven, begins at 41:30. Eric offers a different account, seen through a Lean Startup lens:
“To me the great irony of healthcare.gov is that the current healthcare.gov that people are complaining about is actually the second version of healthcare.gov that was built. The first one was built right after the Obamacare law was passed…. And you couldn’t sign up for insurance in those days, it simply gave you information about the insurance options in your jurisdiction. But it was still pretty complicated, and it still required a lot of cooperation from the insurance companies–there was a lot to it. And they did it exactly opposite of this current healthcare.gov in the three dimensions I think of as key: they put a small team on it–a cross-functional small team, I think there was no more than 10 people; they gave them 90 days to deliver; and I think their total budget was so small as to be close enough to zero. Classic minimum viable product. They did it all open-source, so from an ethos point of view it was opposite, and from an infrastructure point of view it was all cloud and modern like you would expect. And they were able from that point to do the build-measure-learn thing and to iterate and get feedback from the insurance companies and from the public. And they turned that from a tiny little seed into a quite useful, complicated project by gradually increasing its complexity in a highly polarizing political environment where everybody wanted Obamacare to fail. Which is what to me is deeply frustrating–thanks to the president’s creation of the CIO and the CTO, he has really great people from Silicon Valley, from our communities, that could have been instrumental in creating this website, but those people were bypassed because of the IT procurement process in the federal government, which is a nightmare.”
For further highlights see Kent at 57:10 and Eric at 59:00 on the importance of measuring team members on impact rather than effort. Eric: “It’s a fundamental waste of human energy and talent to have people working on things that nobody wants and that have no impact. That’s actually morally wrong to have a system that does that. Couldn’t we expand our horizons and see that there’s actually another way? I find that very motivating.”
Eric’s conversation with John Shook, CEO of the Lean Enterprise Institute, covered the origins and applications of Lean principles (video; iTunes; SoundCloud). John moved to Japan in the 1980s to work at Toyota, which at that point had the most advanced manufacturing practices in the world. He took what he learned there back to the US, first to work with American auto plants as part of the GM-Toyota partnership, and then as the founder and president of the Lean Enterprise Institute.
Here’s John at 12:20 describing the turnaround Lean Manufacturing methods were able to make at Nummi, a GM plant that was, as he describes is, “the certified worst plant in the world,” both in terms of product quality and the attitude of the workforce:
“So I joined Toyota really exactly 30 years ago, it was late 1983. We built our first car there at Nummi in the old General Motors plant, in December 1984–so just one year. And with the same workforce–a lot of people don’t realize it was actually the same workforce, the old ‘troublemakers’ were offered their jobs back, and I worked alongside them–and in one year we built our first car. When GM did their first quality audit, it set the record for the very best quality score any GM plant had ever gotten. With the same workforce. And the same employees who were so disgruntled before became powerful advocates for the system, for this way of working. So the turnaround was powerful and in my mind at the time, this just proved that this could work, and this could work anywhere.”
To Eric, the scope of the turnaround is so unbelievable that it can be difficult to draw lessons for it for other companies. So he asked John how he had effected this incredible change in the culture at Nummi. John’s reply has the force of a new adage (at 16:44):
“We changed the way we behaved. That then changed the attitudes of the people that worked there, that brought forth a whole new culture…. Rather than think your way to a new way of acting, try to act your way to a new way of thinking. So how is it we want to think, ‘What’s the culture we want? Let’s try to draw a picture of that, and what do we need to do to get there?’ So we started working on the behaviors, what do we actually need to do? We changed the work.”
In response to a participant question about what you do if the problem isn’t the workers, rather the management, John said (at 26:48):
“It’s always the managers and not the workers, and we have to realize that. So if we are the managers, if we are the leaders, then we have to look in the mirror. That’s where it starts, that’s not where it ends. People often ask where do you start, do you start at the top, do you start at the middle, do you start at the front lines? And honestly, wherever you start, it’s going to be the other areas that are the problem, that have to be somehow brought along. And if you’re working with someone that’s a frontline manager or supervisor, they’ll often say, ‘Well, I could do this if I were one level higher up, because my bosses, those managers, they don’t get it, I get it.’ You go to them and they’ll say, ‘I get it, it’s one level higher up.’ You go all the way up to the CEO and the most frustrated person in the company is the CEO because he or she can’t get anything done that he or she wants done.”
Take a listen to John at 35:00 on what the company of the future will look like, and Eric’s closing question and anecdote at 39:43, a poignant narrative of waste centered around a visit he made to a factory floor and a revelation about his microwave.
Our final webcast of the season was organized in response to intense interest from our community around Lean Startup in education. We brought together Diane Tavenner, founder and president of Summit Public Schools, a network of charter schools in the San Francisco area, and Steven Hodas, who heads the markets initiative for NYC Department of Education, with Sarah Milstein, co-host of the Lean Startup Conference, for a webcast on Testing Lean Startup in Education (audio on iTunes and SoundCloud; we do not yet have the video for this webcast). The conversation centered around a few key topics: customers, bureaucracy, and MVP.
Diane at 5:13 describes her customers as students, but notes that their parents, the post-secondary education system (colleges and universities), employers, and even society at large are invested in students’ public education. Steven at 6:45 describes a useful distinction between customers, users and audiences, where these may be competing as well as overlapping interests. As he puts it, “Teasing out who is the customer is part of the work itself.” In response to a question about the bureaucratic and regulatory barriers to action–barriers that, given the intensity of personal and public interest in education one would expect to be quite high–both Diane and Steven surprisingly agreed that there was more excuse-making than actual obstacles to action (start at 12:18 for this portion of the conversation).
The practical how-tos of running experiments on actual students in an education environment was a major feature of this webcast. Here’s Diane (at 18:30) on the relationship between getting buy-in and creating an MVP, where the two can serve each other:
“Really the key concept here is that to win people over, you have to identify a problem that is particularly challenging for them, or even a small problem for that matter, and then demonstrate that using these processes actually solves that and gets them to a place that’s much more desirable. And one very exciting example for us, an early example and an easy win, was our teachers really needed a way to differentiate and personalize instruction for students, because when you’ve got 25 students and they’re all in different places, how do you meet their individual needs? It’s humanly impossible. And so they came to this idea if we had a playlist for kids that was really intuitive for them, that we could curate all these different resources so that kids could actually choose how they learn best. And if we could collaborate as teachers across different schools and across subject areas in courses, it would be helpful. So taking that wish and seeing that it doesn’t exist out there, we partnered with a software company, shared this wish and ultimately ended up co-developing, co-designing and building an MVP, testing it, involving our teachers and students all along the way, and ultimately this fall launching it as a free product that’s available to every teacher in the world, where they can collaborate and share and use it with their students.”
As a counterpart to the question of how to create and test an MVP, Steven and Diane discussed how to use metrics to measure progress. Steven at this point (34;28) launched a defense of vanity metrics– not to measure student progress, but to help create, again, buy-in from stakeholders:
“Given the public nature of public schooling, and the tremendous political pressure, and this fear of failure that Diane mentioned, which is really ubiquitous and the higher up in the organization you go the worse it gets–in order to get collaborators to come along with you, you need to make them feel good. By focusing on things that matter to them. Not only do you need to identify problems that are important to them, but they’re looking for certain indicators of success that may not overlap with your indicators of success. And so depending on the situation and what it is you’re trying to accomplish, for example, a certain number of newspaper headlines that speak positively about the work can be far more important, for better or for worse, in getting you the buy-in to take you to the next step than some increase in student achievement on a formative assessment. Because those particular people who [are] your audience, who you’re trying to impress at the central level, their concerns are not immediately about student achievement at that moment. It’s about what does this mean for me, and my career, and what is the potential downside, how is my boss going to feel about it. So when I think of vanity metrics I think of things that can be bad because they can be deceiving when you apply them to yourself.
“But I think things that demonstrate popularity–again, in a politicized context–are really important, so we do rely on them. When we do software challenges, for example, participation in those challenges is a really important metric, in fact it’s one of the things we optimize for. And I’m not embarrassed to say that sometimes we’ll optimize more for participation than for the quality of the software that comes out the other end. Because at that stage in our MVP what we’re trying to demonstrate is not that our software challenge produces the silver bullet that’s going to solve all our middle school math problems, but that if we have an open, embracing process, new partners will want to come participate with us.”
–
All of our webcast speakers will be at The Lean Startup Conference, December 9 – 11. Register today to join them and dozens of other speakers, as we explore advanced topics in entrepreneurship.
Guest post by Lisa Regan, writer for The Lean Startup Conference.Our fall webcast series concluded on a high note with three extraordinary conversations about the origins and implications of Lean Startup. If you missed these when they went out live, we encourage you to watch them now, as they lay a strong foundation for The Lean Startup Conference, December 9 -11 in San Francisco—less than two weeks from today. You can also listen to any of the webcasts, which, at the suggestion of a webcast attendee, we’ve turned into podcasts you can stream or download (from iTunes or SoundCloud). None of the webcasts included slides, so the audio versions work really well.Below are just a few highlights from our final three webcasts: 1) Eric Ries’s one-on-one conversation with Kent Beck about influencing other people; 2) Eric’s conversation with John Shook about the origins of Lean, and 3) a conversation between Diane Tavenner and Steven Hodas, moderated by Sarah Milstein, on applying Lean Startup ideas in education.Eric’s chat with Kent Beck was among our most entertaining webcasts (video; iTunes; SoundCloud). Kent, a veteran programmer, a founder of the Agile method and the creator of Extreme Programming, came armed with anecdotes and lessons from his own experience, as well as a few questions for Eric. For example, at 12:56 in the video Kent describes how he made the move from programming to a role that he at one point describes as “Full Metal Guru”:“It turns out you can be a bad enough programmer to sink a project, but you can’t be a good enough programmer to make a project successful. So I quickly ran out of gas on projects being more successful, and I was forced to take a bigger, broader view of the context in which programming happens. I started to pay attention to things that worked, and to things that didn’t seem to make a difference or actively harmed development. I’ve always been a contrarian, and so if someone says, ‘X is always true, I always think, then what are the implications of not-X?’ As a reflex, I always think that. So if someone says, ‘You need comprehensive documentation for software documentation,’ I think, ‘Well, what if you didn’t have any documentation at all? …
