Book
Authors: Jez Humble , Joanne Molesky and Barry O’Reilly
How high performance organizations innovate at scale
[Podcast] Delivering innovation at scale
Brief summary
Lean Enterprise was a landmark book, exploring how large enterprise could learn from start-ups and deliver innovation at scale — how they could respond to changing market conditions, customer needs, and emerging technologies when building software-based products. Thoughtworks Technology Podcast catches up with two of the book’s authors to hear about its genesis, its impact and why there’s not likely to be a second edition.
Rebecca Parsons: Hello, everyone, welcome to another edition of the Thoughtworks Technology podcast. I'm one of your recurring hosts Rebecca Parsons, the Chief Technology Officer for Thoughtworks and I'm joined by another one of my hosts.
Mike Mason: Mike Mason. I'm also one of your regular hosts, and I work closely with Rebecca at the works as the Global Head of technology.
Rebecca: And we are joined by two of the three co-authors of the book, Lean Enterprise. The third declined to participate. She's decided that being retired is far more important than being on a podcast. She's having quite a nice time being retired. Thank you very much. I will let you two gentlemen introduce yourself up. Barry, do you want to go first?
Barry O’Reilly: Yes. Hi, Barry O'Reilly. Currently, I'm a co-founder of Nobody Studios, which is a venture studio. Our mission is to create 100 new companies over the next five years. I'm having lots of fun trying to build new companies and launch them. That's what I've been doing for the last little while.
Rebecca: And Jez.
Jez Humble: Yes, I'm Jez Humble. I am an SRE at Google and I teach at UC Berkeley and I've written some other books, including most recently Accelerate with Dr. Nicole Forsgren and Gene Kim.
Mike: Joanne is happily retired, so good on her. Let's shout out to Joanne wherever she is in Vancouver Island enjoying the sunshine I'm sure.
Jez: Well, she posted a photo on Facebook of her-- or John, her husband posted a photo on Facebook of her on the beach this morning. I think she's doing great, but hopefully, she'll come up in conversation, but obviously, an integral part of this book and we miss having her here.
Rebecca: Well, so why don't you tell us first a little bit about where the book came from. How did you decide that this was something you wanted to write about?
Jez: I'm going to start with this because I think my story goes back slightly further on this one. I wrote Continuous Delivery with David Farley back in 2010 and that was a surprise success. We sat to write what we thought was going to be quite a boring niche book on build and deployment automation. The DevOps movement came around and suddenly it was like the book of the moment, which was fantastic but unexpected. We talked about this a lot and a bunch of people at Thoughtworks from whom the ideas in the book came also were talking about this a lot.
What we would find again and again is people would say, "Well, that sounds great, but I've got problem x or problem y." There was all these more structural problems that we found in the companies of the people we were talking to that were preventing them from doing this. It was everything from their product management practices to their change management practices, their budgeting. Over the years, I came up with a list of this stuff and a reading list of stuff that I read in order to help people work through these problems, and it just came up so much that we ended up writing a book about it.
I was on the lookout for domain experts at Thoughtworks in these areas, and so I hit up Barry because Barry had done a bunch of successful work in the UK on helping people adopt new product management practices. Joanne who was working in IS who had this amazing history in governance and change management and had done work at big enterprises, WestJet notably, I think, before joining Thoughtworks. It was basically putting together a team of people who were best placed to be able to address these questions.
It took us, I think, a couple of years to write, which we cut in half the time it took to write Continuous Delivery. Continuous Delivery was four years, Lean Enterprise was two years, so that was a great success, I think, from our point of view. I like to think of Lean Enterprise as the book where I keep all the stuff that I want to remember like all the quotes and there are references in it. It's like, Oh, dear, I'll just look it up. I kept all the stuff I want to be able to refer to in there. That's how I'd like to think about it. Barry.
Barry: I noticed. It's funny, I remember getting an email from you. You invited me to have lunch with you. I really had no idea like, "Why does Jez Humble want to have lunch with me?" It was super fun we got to write the book together, get to know each other really well and with Joanne had a lot of fun writing this and I think, as you say, amazing that we went from four years to two years to create another book, so yay for us. We're getting better. [laughs]
Rebecca: What is surprising is Neal Ford often says that books always take longer to write than you think they would, and it's a minimum of two years is what his benchmark is. Have things changed much since the book came out? Do you feel like it's still as relevant today as it was when you first started putting it together?
Barry: It's a great question. In some ways, some things have gone faster, but other things have gone slower. In many ways, I feel like a lot of the ideas still aren't adopted today. I think it's still maybe a smaller minority of companies who have truly embraced the idea of experimentation or taking more innovative practices to, not just product development, but budgeting to the way they do performance management, to really all aspects of the company. As Jez was saying, that's what we were trying to encourage people was to give people a perspective of when you build products, how you do it more iteratively. When you think about your budgeting, how can you do it in smaller chunks and more iteratively and even building your culture and hiring people, talent sourcing. I think it's probably fair to say when we look at most companies, they're still very much trapped in a legacy industrial area mindset and behavior where we still do big, huge planning five-year transformation plans. I'm sure that you see that all the time walking into clients in Thoughtworks in there got their five-year transformation plan that if they just executed correctly they'll finally take Moscow or whatever it is they want to do.
I think it's great that it inspired people, but I think there's still more work to do. Obviously, Jez and Nicole and Gene further showed in Accelerate their work around the DevOps movement and trying to make that more measurable and understandable, but even I'm sure Jez shared now is even the adoption of a more systematic approach to improvement and making work better and a happier place for people to be. We're still not there.
Jez: Yes, I totally agree. But the whole problem with all this stuff is that you have to be holistic about it. That's really hard because you've got to get people, especially in big organizations, but frankly also I've seen a 100-person, 200-person startups which have huge problems with a lot of this stuff. Unfortunately, every year a new group of people enter the industry who in many cases still have been taught the old way of working. This problem isn't going away anytime soon, I don't think. I've still got a copy of McGregor's, The Human Side of Enterprise from 1960, where he talks about Theory X and Theory Y, motivating people based on things they care about versus the current stick approach where what? 60 years on from that and it's still fresh. These problems aren't going away anytime soon.
It's just a constant thing that we see at Thoughtworks now. New tools and technologies come along, Kubernetes and Docker and all the latest stuff. Then every time that happens, I get really frustrated because it feels like we've started from scratch every time. We have to learn how to do the thing that we learned 10 years ago, but with a new tool and the same thing seems to happen with frightening regularity in organizations. I'm interested. I don't do consulting anymore. Mike, Rebecca, you must have these experiences as well.
Mike: My experience with transformation is that people always seem to want to know exactly what the destination is. Like transformation is a thing that you can time box and you know where you're going to get to. We always try to emphasize that the point is to get yourself into a state where you can be more adaptive in the future to whatever comes along. The notion of a plan where you can get to the end of it just doesn't actually make that much sense. I certainly find that and I think when you talk about the technology changing, people find new ways to apply bad old ways of working to new tech. Whatever it is becomes some new tool for centralizing command and control and realizing that that creates yet another bottleneck, but on some new technology stack. I think we see quite a lot of that.
Rebecca: We also see the fact that experimentation isn't really well understood. By definition, you don't know how an experiment is going to turn out. Punishing people when their experiment fails, well, but you didn't know how it was going to turn out. If all of your experiments succeed, then you're not taking enough risk. We can't understand this thing and it is so hard to get that through people's heads because they want it very clear, either it's successful and therefore you were a good person or it failed and therefore you were a bad person.
Well, there's this middle ground that said it was a perfectly sensible idea that didn't happen to work out and now let's try to figure out what we've learned as a result of this not going right. People organizationally do not understand how to deal with a constructive failure. It's either good or bad, but there is a middle ground there and that has been so frustrating to try to see-- It's frustrating because people don't just understand this concept.
Jez: People want to take risk and they want to innovate. Everyone bangs on about innovation and disruption, and that means taking risks. Taking risks opens the possibility of failing because if you can't fail then it's not a risk. People really don't want to follow that train of thought.
Mike: Even something like metrics seems to be very difficult for a lot of organizations. I talk about four key metrics all the time because it's a really nice packaging of what metrics can do for you. Even things like understanding what work in progress do you have as an enterprise right now. Do you actually know that? Do you know things like your cycle time? Do you know even what revenue or a particular feature or thing is actually getting you? Even those things can seem to be pretty murky.
Jez: I think that just reminds me of one of the things that we did in the book that I really liked, which was at the end of every chapter, we put a bunch of questions. When I reread those, I think that was a bit of a quirky off-or-the-cuff decision that we made at some point. In retrospect, I think that was really nice because so much good consulting is just going around and asking potentially quite innocuous questions that you know are actually not innocuous because you know that [laughs] person's not been able to answer them and maybe get a bit cross.
Rebecca: Is there a part of the book that you feel is most misunderstood that the people just don't seem to be able to wrap their head around it?
Barry: Well, it's funny now that you're talking about this. I think actually the aspects of innovation accounting is one area I think that is often talked about, but not done very well. I think the interesting part, the classic when you ask somebody when they have a new idea that the automatic response is always, "How long is it going to take? How much is it going to cost? and how much money is it going to make us? when you've just written something on the back of a Post-it Note. They're all the wrong questions to ask at the last stage of the process.
I think this notion of thinking what makes really interesting metrics when you're innovating or outcomes you're aiming for are leading indicators to tell you you're on the path to making money, or you're on the path to people using your product more frequently. Or you're cutting the time it takes for tasks to be done. Like, what would you see people doing?
I always thought that was a interesting space where it sounds like really nice as a word innovation accounting, but I think the metrics people tend to use there are, they still talk quite output-based, like how many times have people done something rather than thinking like a change in behavior that will tell you you're on the path.
A classic example I think at the moment is that banks are constantly saying that they're worried about losing customers and how do they keep up their revenue, which again, are all liking indicators. When you drill into what the problems the banks have at the moment is 18 to 20 five-year-olds are not going into your high-street bank to open accounts. They're going onto the internet and popping open Robin Hood and playing games all day trying to invest 10 bucks and see if they can turn it into 11. Because it's a game for them, and really a better way to start thinking about innovation is saying, "Well, rather than how do we make more money, is how do we start identifying some of these segments that we're losing traction on, and what would be some of the early behaviors that we would see if this 18 to 20 five-year-old segment was actually interacting with us?
Do we want growth in that market, and what would be a leading indicator for that? Would it be that they'd be engaging with us? Would it be that they'd be tweeting about us? Would it be that they're following or downloading our application and using it? I think trying to get people to that level of detail and specificity is hard so people don't do it, but it's easy to count I spoke to five customers today, or I deliver 12 story points this week, or we release 10 new features, but not talk about the effect you're shooting for. That's probably one just listening to you both now just prompted in ahead of an area. I don't know. What do you think, Jez?
Jez: I'm going to pick the last part of the book Transform because it's the last part and if you're anything like me, you never get to the end of the book because--
[laughter]
Barry: Did anyone get there? We need to be able to run a poll in the audience, that's a leading indicator. How many people got to chapter four and beyond?
Jez: We start that section with a quote from Leo Tolstoy that I'm quite keen on. He says, "Everyone thinks of changing the world, but no one thinks of changing himself." I think apart from the awfulness of my Russian accent, and it is normally a dude, let's face it, we don't focus enough on how we can improve our culture. One of the things we showed in the research program behind Accelerate is that culture matters and it's important.
It's difficult to change because your culture is basically built up with the things that you did the work and you're basically telling people, "We'll take all that stuff that you institutionalize that worked and change it." People don't like that very much and it's crucially important. There's this key piece around psychological safety, making it safe to fail and everyone's nodding vigorously along as [laughs] I'm saying this because it is so important and I think people often get that wrong as well. This is something I think about a lot. Psychological safety is not about making all the white dudes like me feel like they can say whatever they want, it's about creating an environment where everybody can say things that they feel, that critique the mission at hand and the concerns at hand and making it safe for everybody on the team to be able to do that.
That can be uncomfortable and this is kind of a paradox of psychological safety is you can't make every conversation comfortable, that's not the goal. You've got to choose which conversations you want to make comfortable and which ones you don't, and be very thoughtful and strategic about that. Often, the conversations that are easy for people to have can be quite exclusionary and cannot be focused on innovation. That, I think, for me is something that comes up over and over again, because it's so hard to do and people think about it wrongly, I think.
Barry: Yes, I do like when you say that because I think sometimes when people hear psychological safety or just safety in general, they think being nice to people versus I think there's a difference between nice and being kind. Kind is when you have that piece of green things stuck between your teeth and you're eating dinner where you actually stop someone and say, ''Hey, you might know this. I'm really enjoying having dinner with you, but you've got a bit of green thing stuck in your teeth. You should probably take that down.''
It's a bit uncomfortable to do it, but everyone feels better as a result of it. Or the nice thing might be to say nothing and let it just persist and then the poor person is going around with things look on their tooth. I think have been the ability to have productive discomfort. Being able to say things where people feel that you genuinely care about them, but you're telling them some tough things that they mightn't want to hear. That is a really high-performing environment for me versus where people are afraid to speak off. They don't say what's on their mind and are passive and feel like they can't say, or they'll be shut down.
That's a very poor environment, I think, because you never get the data, you never get the information, the reality to make better decisions. I think the teams I've worked on where you could separate those two things I think it makes for a fun place to work because you're challenging the ideas, not the people, the quality decisions get better, the conversations don't feel so personal. They feel focused on the work, especially with experimentation as well where you're learning as you go. You have to do things to generate the information to take your next step. I think it's really important to be able to have those conversations in a candid open just manner and you definitely don't see it that enough. It's interesting.
Jez: I think the other pathology is environments where some people feel comfortable saying whatever's on their mind, but not necessarily in a way which is kind and respectful of other people or considers their viewpoints or encourages people who might not normally speak up to speak up or is respectful of differences between people. That's something else that I think I see a lot more than I'd like.
Rebecca: If you were going to give people one recommendation for something that they could do immediately to make a difference, to start moving forward, what would that recommendation be on the basis of the thoughts that you've put into the book? If it's two, that's fine as well. It doesn't need to be the talked one.
Jez: I think, again, the research shows that the way you change stuff is by doing your work differently. It starts with experimentation and exactly what you talked about, Rebecca. Getting that mindset of experimenting and having it fail and that being okay and learning as a result. Back in the day when I used to go and do workshops, I'd start by trying to get people to think about some key feature of their products that they cared about and then think about, ''Well, what behavior do you want to change from your customers?
I'd get them in the workshop to come up with a bunch of experiments to try and validate that outcome they wanted to achieve. I'd say, okay, you got 20 minutes for an experiment and people would freak out a bit but then you'd always find few people in the group who would go and actually do something cool. I remember there was one group where they wanted to test. They had this argument over and over again and it was something quite trivial like whether they should have a spinner when the application was waiting for more feedback. They did this cool experiment where they just made a slideshow with a spinner and without a spinner and they advanced it at a fixed pace and asked the person looking at the presentation how long they thought had elapsed between the slides.
They got this very counterintuitive result, which is that it seemed-- I can't remember what it was, I think it was that it seemed longer when there wasn't a spinner, and hence that they shouldn't actually do that. I think just thinking about what's the outcome we want to achieve? How could we do a cheap experiment to validate that? By starting with something like that just to get people out of their comfort zone in a way that they can see results quite quickly and try something quite quickly? That's step one. Then the tricky bit is taking that and then institutionalizing it so that it becomes habitual.
That is really hard because it's one thing to go in and do a workshop and everyone's like, oh, cool, new stuff, and then you go into the work the next day and it's like, nevermind that, here are my stories for this week. We have a target velocity of 14, let's go. That, in many ways, is the tricky bit and that really depends on effective leadership and having leaders who are prepared to reduce the number of things that they commit their teams to and fund them and follow through on actually making those things that are important and a very small number of those actually take root over the course of months and potentially years. That's my little rant.
Barry: That's good. There wasn't as much hand waving as usual there, Jez. You should bring more hand waving to the podcast. It's very important. This is all great stuff and I think maybe just a simple one as well for people it's just start where you are type notion as well, and that's actually how when the last parts of the book actually. I knew you were alluding to this, Mike and Rebecca too. It's like when people have this five-year plan and it's all laid out in front of them and they have to do all this upfront work, and you probably saw this in your Evolutionary Architecture book as well. People have to have the perfect target architecture before they even start on the journey. Again, it's just like burning time where it's coming up with ideas and not really knowing if they're true or not. I think just encouraging people as Jez even showed in his example, you could just start experimenting in five minutes. You can just do something small like something that you did yesterday. Could you tweak it a little bit and try and do it differently today and see what the results are. That gets people started and talking about that you're trying to do something different. Sharing it with people and sharing the results, whether they're positive or negative. The thing to really encourage is not really the results people get initially anyway. It's just the attempt. Is encourage people to just keep attempting because the results are variable. Sometimes you'll succeed, sometimes you won't. But if you can get people trying stuff, eventually they'll get better at trying and they'll actually more desirable results over time. They will probably be the things I suggest there.
Jez: I think there's two key bits for leadership here. Firstly, leaders have to lead in this way and say, "Look, here's something we tried. I was in charge of this. It didn't work. Here is what we learn." So leaders are going to model the behavior they expect, and then when people working for these leaders do that, the leaders have to celebrate it. [chuckles] We have this thing at Google where you can just give someone a peer bonus based on what they did, and so seeing people be rewarded when they take risks and fail and learn, it's important for that to be seen as well, I think.
Barry: Do you think the incentive drives the behavior, Jez? Do you see people trying to do more stuff, or does it help that folks are recognized for it? I'm always curious about those sorts of things.
Jez: Yes, I think it's a bit of both. One of the things that we used in our research is this model of transformational leadership, and I'm just going to quickly get it up on my screen so that I make sure I don't screw it up when I talk about it. One of the things that we talk about-- There's five different axes on this model of transformational leadership. Vision understands where the team is going, and where they want the team to be in five years. Since you just liked that offered as a technique, I want to be clear that it's the outcomes you want rather than the fully developed plan that matters here. Inspiration communication like says positive things about the team, says things that make employees proud to be a part of their organization.
It encourages people to see changing conditions or situations for the opportunities, and again, it's hard not to read this in my sarcastic voice. I'm doing my best here. Intellectual stimulation challenges team members to think about old problems in new ways and to rethink their basic assumptions. Supportive leadership considers others' feelings before acting, behaves in a manner that is thoughtful of other's personal needs, sees the interest of the team members as given due consideration, and then personal recognition like commends team members when they do a better than average job, acknowledges improvement in the quality of work and personally compliments team members when they do outstanding work. People notice that. The personal recognition, people notice who gets rewarded and he doesn't get rewarded, and what they get rewarded for, and then they copy that behavior, and that's just as strong when it's informal as when it's formal.
Barry: Yes, and when it's good and bad behavior as well. That's one of the things that's always interesting. It's really hard. I always keep thinking like I'm making mistakes all the time in what I'm trying to do and like how can I show up when I make a mistake in a way that makes it okay for other people to understand that? That's one of the things, and it's really interesting in this remote world. If I make a mistake on a phone call with just like one person, how can I recognize that not only with the person, but with the wider team? It's actually really hard to disseminate these situations, because when you're used to being in a team or with people in a room or many people in a room, it's interesting to think about how I can talk about those things.
Like, "Here's something I did wrong and I want to do better at," or normalizing negative results from experiments that what we will do differently next time. You almost have to organize a meeting at the moment to do that. It's weird, right? Everyone's calendar is already pretty booked up, so where am I going to get the chance to talk about these things? It's interesting to even try and build this stuff, especially if I were also remote at the moment. I don't know if you've seen any fun things or what you're doing in Thoughtworks even. Do you just live on slack channels where people send emojis of like-- I just send facepalms most of the time to people because I'm just doing stuff wrong all the time, but I don't know if that's really the level of accountability we're aiming for here.
Jez: There's definitely some stuff that is much harder to do remotely. I personally think that initial relationship building is very difficult, and then anything that you want to be informal where if you were in person you would have just informally caught up with someone, suddenly you do have to schedule it, and so it almost makes it so that nothing is informal because I fired up Zoom to talk to you so I was intentional about it. We're not just on the way to another meeting room when I'm just chatting.
Rebecca: If you were going to write a second edition, what would you include?
Barry: This is a fun answer, this one, right? On that famous lunch that I sat down with Jez Humble. You talked about writing this book. If anyone knows Jez, he'll tell you that there is no second edition. There will never be one. It's a moment in time and I've fairly subscribed to this philosophy because some of my friends are onto edition 12 of their books and I'm like, ''How can you go back and keep rewriting this?'' It's fun to think about, but our ideas have moved forward. As Jez said, he wrote Accelerate with Nicole, and Gene and I went down to write and learn, and they're all different perspectives.
What inspired me to write and learn was more of this-- I kept seeing while learning new things was tough, getting people to let go of their existing behavior was actually more limiting than teaching people new skills. That was just like an aha moment that hit and I was like, Oh, maybe there's a way to teach people how to adapt their different behavior or experiment with behaviors. That's what inspired me there and I'm sure Jez will share what inspired them to keep going with Accelerate and drove that. I didn't know what you think Jez, but I feel like books are just your best current thinking at that time. The weird thing about a book is it's such a waterfall process. We spent two years talking about this stuff and then you release it, and to the world, it's like, ''Oh wow, look at this, it's this thing,'' and you're like been living in it for two years, which I know you two have both felt with your Evolutionary Architecture stuff.
You're always thinking like the next thing as you're releasing the thing just like in software. You're thinking about the next sprint when the software goes live. I feel like it's just nice to think of these things as your best current thinking on time. They're never perfect. There's always things that could be better, but it's nice to go on and create maybe another thing after that as your thinking evolves. I don't know what you think, Jez, or I'm really keen to hear what Rebecca and Mike think actually too, as well. Given it's called Evolutionary Architecture, I feel like there's going to be an evolution in this.
Jez: Our thinking has evolved.
[laughter]
Yes, second editions. All these moments will be lost in time like tears in the rain. Time for a second edition. It's almost you're going to be rewarded more for doing a new thing than for maintaining the old thing, I dont know. So many bad metaphors we can use from product development here. Lean Enterprise in particular I feel is-- maybe I'm just out of touch, but there's not that much innovation in the things that we chose to talk about that would require it to be substantially revised, which is why we chose to talk about those things. That was kind of the point was to talk about the more or less timeless topics. No second edition from me. But yes, Mike, Rebecca what are your feelings about the second editions?
Mike: I completely agree with you about your best thinking a moment in time and the fact that the state of the art has not really evolved, so what would you do in a second edition? I think to me the shame of it would be if people had missed the book and now thought, I don't know 2014, 2015 publication, is it still relevant? There's been a number of books, Pramod’s Refactoring Databases book being I think the canonical example of something that the entire industry missed, or, well, not the entire industry, but not enough people saw that book. So to me, there'd be some I guess it's a marketing argument that you do a second edition and therefore it's up to date and therefore you can connect with some people who maybe you didn't see it the first time around.
Rebecca: Well, we're actually in the process of starting the second edition of The Evolutionary Architecture book.
[crosstalk]
A lot of that is what we have learned watching people try to adopt this different way of thinking and apply it. It's not so much the way technology has changed. I'm sure that might change our examples, but it's what are the things that people have found hard to understand, and is there a way that we can present the material differently in a way that it is easier to understand? Probably because of the background I have in genetic algorithms and evolutionary computation, for example, fitness functions make perfect sense to me, but people really struggle with how a fitness function can actually do all of the things that we're saying it can do, and so what can we do to make that a bit more concrete and demonstrate how it can be used for governance as an example. Because that's a big question for people is, okay, well, what does this do to my governance process? I do get what you're saying. I really wasn't looking to do a second edition of the book, but that's a lot of what's driving it is as we look back on it, the core ideas are still there but there are things that are just harder for people to understand than they should be. We want to see what we can do to rectify that.
Jez: Yes, that makes sense. I'm in no position to throw rocks because we are going to at some point probably do a second edition of Accelerate because we have more research from 2018 and 2019, which wasn't in the first edition. I think there has to be room for learning. I do think at some point though, I think what Mike is talking about is right. You've got to find new audiences.
Sometimes I think a lot of continuous delivery was just extreme programming but repackaged and with some other stuff thrown in and Kent Beck was like, Oh, shit some other grifter making money off extreme programming. He didn't say that out loud. He's actually very nice to me out loud. I think at some point there is also value to taking things and repackaging them and updating them and having different people talk about them. That's a way to get people to think about it in new ways and need people to think about them who haven't thought about them before. I'm fine with people doing that. That's a sign. If someone, as Kent once said to me, there's this whole thing about progressive delivery and both me and Dave were a bit like, well, we talked about this in Continuous Delivery would do to which delivery and Kent, he DMd me and he's like, Listen, that's the sign of success is when someone's taken one of your ideas and repackaged it. That means it had something worth repackaging. I'm a fan of that too. If people restate things in new ways and reach new audiences, I think that's great.
Rebecca: Okay. Well, thank you both for being with us today and it's been great seeing you both again, as well. It has been far too long. Thank you, Barry. Thank you, Jez. Thank you, Mike. I hope you all will go out and buy a copy of Lean Enterprise if you don't own one already. No need to wait for the second edition.
[laughter]
Jez: Thanks for having us.
Barry: Thank you.
Want to find out more?
We're delighted to offer you this opportunity to download a free chapter of the book, so you can try it before you buy.
We hope you enjoy this taster.
In the authors’ own words....
Why did we write this book? <br> All of the authors are experienced working in both enterprises and startups, and we have set out to present a pragmatic and systematic approach to innovation and transformation that works effectively in an enterprise context. We have addressed not just how high-performing organizations develop products, but how companies that are working towards higher performance can adopt these techniques in an incremental, iterative, low-risk way.
Business advisor, founder of ExecCamp, and faculty at Singularity University
Barry O’Reilly is a business advisor, entrepreneur, and author who has pioneered the intersection of business model innovation, product development, organizational design, and culture transformation.
Barry is author of two international bestsellers, Unlearn: Let Go of Past Success to Achieve Extraordinary Results, and Lean Enterprise -part of the Eric Ries series, and a Harvard Business Review must read for CEOs and business leaders. He writes for The Economist, and is faculty at Singularity University.
Site reliability engineering at Google Cloud
Jez is the co-author of the Jolt Award winning Continuous Delivery, published in Martin Fowler’s signature series (Addison Wesley, 2010), Lean Enterprise, in Eric Ries’ Lean series (O'Reilly, 2015), the DevOps Handbook (IT Revolution, 2016), and Accelerate (IT Revolution 2018). He spent his career tinkering with code, infrastructure, product development and consulting in companies of varying sizes across three continents, including working for the US Federal Government at 18F. He is a developer advocate at Google Cloud, and teach at UC Berkeley.
Thoughtworks alumni
Joanne Molesky was a principal consultant at Thoughtworks, where she worked on internal IT Risk and Compliance, and provided consulting services to clients in the area of continuous delivery and process improvement, particularly as it applies to controls, risk, and compliance.