We provided data on things that we've been talking about for years.
Nicole Forsgren and Jez Humble talk about their new book "Accelerate", and about backing up DevOps practices with data and research.
Welcome to the Masters of Data podcast, the podcast where we talk to the people on the front lines of the data revolution about how data affects our businesses and our lives.
The DevOps movement is one of the most consequential, cultural, and technological ideas to hit information technology and software engineering teams in the last couple of decades. At its core, DevOps is a grassroots movement to reduce the friction between the people building applications, developers, and the people keeping those applications humming. This decreases the time to market for innovative products, all while maintaining quality.
DevOps combines some of the best elements from other movements before it- like lean manufacturing and agile software development. This episode, we talk with two of the co-founders of the DevOps research and assessment LLC Dora’s Nichole Forsgren, CEO and chief scientist, and Jez Humble, CTO. Nicole and Jez are two of the key thought leaders in the DevOps movement and have done more than most to evangelize and legitimize DevOps best practices.
Through their extensive research surveys and in-depth analysis at Dora, they, along with co-founder Jean Kim, have built a strong data-backed foundation for DevOps. We will discuss their brand new book Accelerate, where they bring this research together and present fascinating conclusions about DevOps and the impact it can have on organizations when implemented well.
Can you, Nicole, start off and explain what do you guys try to do, and tell us a little more about the mission?
Nicole: Sure. Myself, Jez, and Gene, have been working together as a group for the last four years on the state of DevOps reports. If anyone here isn’t familiar with that, for the last four years we’ve collaborated with a group at Puppet to do a giant research project. When I first got started, I was a professor and we were digging to find academically rigorous ways to understand how to drive efficiency, excellence and high performance in software delivery and organizational performance.
We wanted to know of technology actually makes organizations better, and how do we make it better. A couple years ago we started Dora to help continue that work, to help organizations understand how to measure what they’re doing, how to benchmark against the rest of the industry, and how to understand what pieces they should focus on. This helps drive strategy and accelerate their transformation.
The Journey Into DevOps
You’ve both been involved in this space for a long time. Jez, you’ve written a couple of books and you’ve both have been thought leaders for a while. I’d love to hear how you got involved with DevOps, especially since you were there at the beginning.
Jez: I got involved in DevOps by doing it before it was a thing. When I graduated from college in ’99, I got a job at a startup in London. There were only two of us doing technical stuff so we had to do everything, whether it was racking servers, doing systems configuration, or building the software and operating it. We used to deploy from our machines into production by just FTP, no files. We didn’t have version control, it was very scrappy.
I joined Fulworks in 2004, which is a now pretty big IT consultancy firm. I got put on a really big project where there were many developers building stuff on Windows laptops. The first time we tried to deploy to a production-like environment, the whole thing just went horribly wrong.
It took us two weeks to get it deployed. The software didn’t work properly and we had all these problems trying to get it working in a production-like environment, let alone actually getting it deployed to production.
A lot of the problems that we had and ways that we fixed those problems went into the continuous delivery book, which Dave Farley and I based on our experiences and those of our colleagues. We started it in 2006 but it only came out in 2010, the same year that the very first DevOps Days conference happened. The DevOps movement just happened to come along at exactly the same time. We were there because this is what we’ve been doing for the last several years.
The reason that the devops movement became popular is there was a confluence of different parallel threads in the IT industry, in startups in Silicon Valley, and in larger companies that were trying to solve this problem that the DevOps movement is about.
The question we’re still trying to answer as a movement is how do we build, evolve, and operate rapidly changing, secure, reliable, distributed systems at enormous scale? But, it turns out that a lot of people have that problem, which is why the DevOps movement has become so popular.
Yes, that makes a lot of sense. Back in the early 2000s, I was doing some of the same things, and I remember I was working with a development group to try to get their code to production more quickly, and they actually caused 30 days of downtime for an application.
Ever since then, I was so excited to see this. I’m kind of like you, I was doing DevOps before it was cool and it was hard. It’s amazing to see how far we’ve come. Nicole, I know you came at it from a completely different direction. So, how did you get involved in this?
I got into tech in the late 90s as well. Then in the early 2000s, I was in a similar environment which Jez just described. I was racking servers, laying cable, and configuring all my systems. My very first job was in mainframes, so we definitely didn’t have version control. That was crazy! Then I went on to be a software engineer at IBM. Later, I went out to do some consulting work where we were building workflow management systems. Then I went on to get a Ph.D.
I wanted to help companies, teams, and organizations understand how to do this in repeatable, generalizable ways. Because as a consultant, every time you go in, you tell a team the answer. Occasionally, you would have someone say that it won’t work for their team. So, I wanted to find answers from a research standpoint. I thought I was going to be doing database research because I loved databases and ways to organize things. But I ended up stumbling into maintaining large-scale systems. I was full-time at IBM at the time.
I stumbled into a usability study for sysadmins. I walked away from that thinking that even IBM is working with people who are maintaining and managing these really large, complex systems, yet they don’t realize that these people need slightly different ways of interacting with and using systems.
So I completely pivoted. I changed my dissertation research to try to understand how we make and design systems, and how we study the work of sysadmins. You know, the back half of DevOps, to help make their work more effective, more efficient, and to deliver value in the best way we possibly can.
My postdoc expanded that to go into the development side so that we could look at development and the handoff into operations. If I think about it, that was DevOps, right? So, how do we design all these systems to optimize effectiveness and efficiency, and delivering value to organizations and customers? That was ‘07 or ‘08. It’s really interesting because the timing was right on, it was right about the same time the DevOps movement was coming up in industry.
Then when I hit academia, I was a professor for a few years, pushing this research, and going to industry conferences to try to make sure I understood what was happening. When we joined forces with Gene, Jez, and the team at Puppet at the end of 2013, it was this big movement. I was one of the few people who’d been studying this already for several years, and they were the ones that were in the heart of it for several years. It was this perfect storm which was nerd-fun for me. It was great.
It’s like trying to get into the data and understand the people. How dare you! Who would think of that?
Nicole: Right. At the same time, I was building systems, digging through log files, and trying to make sense of all of this craziness. So yes, it was fun. I think that’s one of the things I’ve always loved about the DevOps movement in general, how grassroots it was. It was full of people trying to understand what was going on right in front of them and how to do things better. I think that’s one of the reasons why it’s been so effective. It seems we all developed the skills at the same time. Because I remember actually putting in expense reports on the mainframe.
Every once in a while, one of my old clients calls me up and they’ll ask for help with something. I tell them I shouldn’t, and they say, “But you still have access!“ Then I say, “Revoke all of that access!”
Never, ever again.
Nicole: Take it all away.
I love hearing these stories. It seems you guys came at a burgeoning moment where everything was kind of coming together- architectures, cloud, new technologies, this drive to build applications differently, the competitive pressure.
Writing the DevOps Book Accelerate
We brought up the book Accelerate before, and I’ve been a big fan of Gene Kim’s for a while. The Phoenix Project really actually helped me think through DevOps and also reading this book. I think you guys did an awesome job. Tell me a little bit more about how you got to writing this book, why you wrote it, and what was driving that process?
Nicole: For me, it was sort of a perfect storm. We had four years of research under our belt, so we had a significant body of data and results to tell a good story. We had a lot of people coming up to us at conferences or emailing us with questions asking us what we thought about different things. I wished there was a polite way to ask them to download the last four reports and stitch it together. Then others would come hit me with so many science methodology questions.
I realized it would be great if I had a platform where we could go into much more detail. The thing that finally spurred me into action was going to the Agile Singapore Conference and DevOps Days Singapore, and I finally met Martin Fowler in person.
When the first report that I was on came out, he said, “You make all these assertions and I don’t believe it. I’m pretty skeptical. You can’t just come up with these numbers.” And Jez said, “Oh, but wait. Nicole is on this project.”
So we had this long, lovely phone call where I outlined all of the really rigorous statistical methods we used. And so, Martin said, “I took really careful notes during that phone call and anytime someone comes to me, I pull out these notes, or sometimes I refer to them at a talk. You really should put those together in a book, and if you don’t…I will.” I was like, “Whoa!”
Way to force your hand.
Nicole: I know. I decided that no one else was going to write my book. I came back from that trip and I said, “Hey y’all, we’re writing a book, let’s go!” We sketched it out and we got going. Is that a fair recollection, Jez?
Jez: Yes. I have nothing to add to that, except that I think that was probably an empty threat on Martin Fowler’s part, but a very effective one.
Nicole: I was giving Martin a hard time, and he said, “No, I don’t think I was going to write it. I think I was just going to nudge you, or do a blog post. I wouldn’t have written the book.” I could be misremembering it, but my recollection is that I got off my keister.
Well, that makes for a good origin story Nicole, remember that.
Nicole: I started writing.
And you’re writing the history, so that’s always going to stand. That’s all that people remember, that’s all that matters. How long has the book been out now? It’s been a few months now, right?
Jez: Two months.
Okay how’s the reception been? Has this actually helped you? Because it seems part of what you guys are doing over at Dora is you have a mission around improving the way people are implementing DevOps. Did you find that having this in book form has helped you get your message across?
Jez: Yes, the reception has been great. We’re on the fifth printing now. We just did a printing of 15,000, which for a book into the second month is pretty extraordinary. There’s definitely a success from the perspective of IT books since any IT book that publishes more than 10,000 copies is considered a success. We’ve exceeded that in our first two months so we’re obviously delighted and very grateful to everyone who’s bought it and spread the word.
There’s obviously a big market for this and I think it’s because people want to know that what we’re doing. The things we talk about actually work, they want data and evidence. That’s really been lacking in our industry.
Now, for a long time, you talked about how Agile is an empirically-driven movement, but it’s very hard to gather data. You can’t do randomized control trials in the context of software development. There are so many variables and they’re incredibly difficult to control in the context of teams building software.
A lot of the studies have been done using small teams of students where you can’t generalize the results. Some studies were done using open source projects, but, again, it’s very hard to control these variables. Then, if you did want to do a randomized control trial in a commercial context, you can’t really do that. It’s very hard to induce companies to create two teams and try and control the variables, given that one of them might fail and cost a bunch of money.
We have a fundamentally different approach to studying these systems. It was a chance. I remember Nicole telling me that she found it very hard to actually find someone to supervise her thesis because what she was doing was so innovative.
I think the results that we’ve been able to produce really speak for themselves. They’ve been very widely and happily received because we were able to actually provide real data and research on these things that we’ve been talking about for many years now.
That makes a lot of sense. When having conversations about DevOps, it seems like you’re basically giving them a platform of results and data that they can use to drive that adoption in their own teams. I mean that’s great, because otherwise it’s a lot of people talking about opinions, and that only works in Silicon Valley. That won’t work where we are at. You guys have shown that that’s not the case, and that’s great.
Nicole: Or they’ll say something like, “Well, that only works in startups, that doesn’t work in highly regulated fields.” Which we’ve also shown isn’t true.
That was one thing that I found really interesting as I was reading through the book. Because you have basically shown that it’s not only one type of architecture like microservices, or that they have to be cloud. You’ve actually seen high-performing groups across the board, right?
Jez: Absolutely. People tend to look at the wrong things in terms of the elements for success. It is natural to do, but architecture is really interesting because people think they have to re-architect, and then they buy all the latest technology, or they re-platform to Docker or Kubernetes. Not to bash those technologies, they are really amazing, but it’s the outcomes that those technologies enable that’s critical. They allow teams to perform deployments on demand and skip complex orchestrated deployments.
It seems like the outcomes that are really important are being able to run tests locally and getting comprehensive test results without having to wait for a complex integrated environment that takes days or weeks to provision. You can achieve those outcomes with mainframes and you can do all the latest stuff with Docker and Kubernetes and not achieve those outcomes. So, that’s something we’ve been able to show very clearly.
People tend to look at the wrong things in terms of the elements for success. The outcome is the most important thing.
That makes a lot of sense. It often seems like the tendency of us technologists to go towards technology.
Measuring Culture in DevOps
It was easy to describe early in DevOps, like how you’re automating with Puppet versus Chef. All that was really important, but, from my perspective, it came down to the culture. You guys spend a lot of time on that in the book. I remember right, there was one place where you said, “Culture could be measured.”
Which I just found fascinating because that’s one of the things I thought would’ve been a struggle in this process- how do you measure the impact of culture? Maybe talk a bit more about how you approached that and the impact of culture.
Nicole: Anytime you want to measure something, you first have to start by defining it. We need to understand what it is we’re talking about when we say “culture.” Because so often people say that culture is important when we talk about DevOps, but often people are talking about very different things. Are you talking about national identity and culture, because that has been shown to have big impacts in certain types of literature, like in financial research?
Well, that’s not normally what we’re talking about when we talk about DevOps transformations. We hear phrases like, “breaking down silos,” and “fast feedback,” and “accepting failure,” and “doing post-mortems.” We tried to keep that in mind as we thought about the type of culture that we were going to be researching.
We came across a definition of a culture that was defined by a sociologist named Dr. Ron Westrom. He had been researching human factors in system safety, particularly in high-risk complex environments like healthcare and aviation. This particular definition and kind of typology was found to be predictive of performance outcomes in these environments.
This definition of culture from him included things like the level of cooperation among three different kinds of groupings: low, medium, and high. Dr. Westrom calls them pathological or power-oriented, bureaucratic and rule-oriented, or generative performance oriented, or maybe even mission oriented. He talks about if the messenger is shot, you blame the person who brings you bad news. You want that person to bring you bad news, you can uncover bad things that are happening. Responsibilities are shirked, you have narrowly defined responsibilities, or risks are shared. Talk about bridging is discouraged, bridging is tolerated, or bridging is encouraged.
That sounds a lot breaking down silos. Failure leads to scapegoating, failure leads to justice, or failure leads to inquiry. That sounds a lot like implementing post-mortems. Novelty is crushed, novelty leads to problems, or novelty is implemented. This sounds a lot like encouraging experimentation.
This was resonating with things we heard when people said culture was really important. We used psychometric methods and turned it into questions like information is actively sought.
So you can say on my team, “Okay is information sought?” I can either agree or disagree, or I can strongly agree. We say responsibilities are shared, because cross-functional collaborations are encouraged and rewarded and failure causes inquiry.
Then we collected a bunch of data, and I went through several different types of statistical tests to see if all these questions together actually measure one core idea of culture and if they don’t measure anything else. I wanted to see if everyone was reading them in relatively the same way. What we found is that it does indeed capture a really good, latent construct.
Because it’s all the same thing, I’m going to call it culture. Now there are several teams around the industry that are doing this six or seven-item measure on a quarterly cadence so they can see what their team culture measure is.
I found that absolutely fascinating. It’s like reading through this pathological bureaucratic and generative system.
Jez: We find that it really resonates.
Nicole: Yes. Dr. Westrom’s research gave us a really nice definition of culture that we found was applicable to technology. Or research also gave us a nice way to measure that. We extended Dr. Westrom’s research that way. Our research also gave us a nice way to see how culture impacts software delivery performance and organizational performance. And, it showed us how we can impact and change culture.
Jez, I know this is one of your favorite things to talk about so maybe I’ll let you talk about this, how we can act our way to a better culture.
Jez: I’ve been interested in the lean movement for a long time. The lean software development movement was pioneered by Mary and Tom Poppendieck in a series of books on lean software development, which I read when they came out in the early 2000s when I was working at Thought Works. So, this is something I’ve been interested in for a while. As a result, I got interested in the history of lean manufacturing, which happened very close to where I currently live in California.
The NUMMI factory was a joint venture between General Motors and Toyota. That was a factory that’s about 30 minutes away from my house which is now the Tesla factory. The NUMMI story is really interesting. I’m not going to cover it now, but if you’re interested, and I really recommend listening to podcasts on This American Life, which talks about the story of NUMMI, and how the people who build that joint partnership changed a workforce which was producing really bad cars for GM. Worker management relationships had broken down. They took that workforce and basically completely turned it around to produce the best cars in GM North America’s whole manufacturing capability, and as good as the cars being produced in Japan.
John Shook, the guy who designed the training program for that team was the very first American employee of Toyota Japan. Shook is very important in the history of the lean movement, which came from that joint partnership. The term “lean manufacturing” comes from the people who worked in that NUMMI factory.
John Shook then went on to write about their experiences. One of the things he says is the way to change culture is to change behavior and to change the way that people work and what they do.
So our hypothesis was, well maybe that’s true in technology as well. Maybe you change culture by implementing technical practices like test automation, or lean practices like working in small batches, using visual displays, and lean product management. Implementing practices like building MVPs and working building prototypes can change culture, and that’s indeed what we found.
Changing the culture impacts not just software delivery performance, but also organizational performance both in terms of commercial measures such as profitability, market share, and productivity, but also non-commercial measures, such as the quality the products produced and the ability to achieve mission goals. So, we know that changing the way you work changes culture, which changes performance. Which is a pretty big result.
Changing the way you work changes culture, which changes performance.
Absolutely. It reminds me of some things that I read about in Skunk Works, and how Lockheed Martin developed these kinds of amazing aircraft in the in the 50s and the 60s. I remember reading that and understanding how they structured teams and worked together, putting engineers and mechanics together on the floor. Then I read about how Elon Musk was doing it at Tesla and then reading how you guys are doing it here.
In this industry, there’s a tendency to think this is the way we’ve always done it, so we don’t really need to think about how others are doing it. But, I love how you guys have pulled in these threads and strands from different parts of the industry and realized you can learn something from each of those pieces. I think that’s a really great contribution to how we’re doing technology. Because a lot of times in the technology industry we tend to ignore what goes on in other places.
Jez: I’m so glad you said that because it’s something that really winds me up. I’m not going to go on a big rant now, but I absolutely could.
Nicole: Now hold on. “Research Nicole” is going to have to step in, because not everything applies the same when technology is introduced. For example, we know that communication patterns can change. So, early on in my academic career, I studied nonverbal communication. As an aside, this is interesting when people lie face-to-face, their communication patterns change in certain predictable ways.
But when people lie using technology, their communications patterns change in completely different ways.
Jez: Can you give an example of that?
Nicole: Okay. When I lie to you in person I do things like hedge and my word count changes. I can’t remember if it goes up or down, but it’s one of them. Now if I lie to you over chat, or over email the opposite happens. So, there is a very real thing that happens once you introduce a technology. Even if you think there’s a presupposition that the technology context looks similar, we really do have to test it out. Because sometimes technology throws a wrench in the game. It really does change the way people act and behave and interact with things.
Here’s another thing, and Jez is going to be smiling and nodding his head. Manufacturing is a case where we know what happens, like queue times and WIP limits. I was an accounting professor for years so I could talk about the way people behave in the case of manufacturing. However, when we’re talking about technology, we’re dealing with inventory that is completely invisible.
In some ways there’s the case for thinking that this is just inventory, the same principle should apply. However, people may act and behave completely differently because there is no way to see inventory. There is no way to see the assembly line behave in the same way. So, we actually really needed to test a lot of these things out.
One example is WIP limits. We looked at lean principles, and we drew from WIP limits. WIP limits help predict and support software delivery performance, but they don’t have the strong effect that we would normally assume. Until we combine WIP limits with other lean accounting or lean principles, such as visual display boards, and a combination of monitoring to drive business decisions. Then we see the amplified effect in technology.
Jez: A theme of our work, in general, is you can’t ignore things in other industries. I really don’t like how we say we are evolving a completely new way of doing things, and think nothing else supplies from other industries. I find this insufferably arrogant because, in many ways, what we’re doing in technology is repeating the mistakes of generations that came before.
My favorite example of this is in a book called The Human Side of Enterprise by Douglas McGregor. It came out in the 60s and talks about the start of management. He talks about a theory where there are two ways of managing people. The first is the carrot-and-stick ways of managing people. The other one is you assume that people want to do good work, and help encourage them to do that work.
The thing is, you get what you expect. If you treat people as fungible resources who are interchangeable and who respond to carrot and stick incentives, they all behave that way.
If you treat people as real human beings, then they will respond that way. However you behave, your predispositions will be confirmed.
This was written in the 60s, and we’re still learning that in management more than 50 years later. I find that really annoying.
I want to affirm what Nicole said. You can’t just take these things that have been shown in other industries and just apply them willy-nilly. You’ve got to retest and revalidate it. They’re complex social systems, and technology has an impact on complex social systems.
I think what the Poppendiecks did with the lean software development was amazing. They took something from a completely different paradigm and said, “What happens when we apply this to the context of software development?”
It was hugely influential, but I think for us to be able to come along and actually take a scientific approach to studying what really works and what doesn’t has been huge. Going through this project has taught me an enormous amount and, hopefully, that will be true of people reading the research as well.
If you treat people as real human beings, that they will respond that way. However you behave, your predispositions will be confirmed.
I couldn’t agree with you more Jez, on the fact that we tend to ignore what has come before us. There’s also a tendency to idolize those before us and think nobody can do better. There are some core cultural changes that need to be accepted about grassroots small teams that have devolved decision-making. They are opposed to this kind of command and control structure like you might have had earlier in the twentieth century. It’s endlessly fascinating. Nicole, I do have to ask you one thing. Is “Research Nicole” an alternate personality that comes out every once in a while?
Nicole: Yes. I mean there’s a joke there.
Jez: I have to say that Nicole has been hugely influential in helping me understand how all those things about the application of new research methods to old ideas works. How you have to test those hypotheses, that’s not in my nature. I just think if something obviously works, we should run with it.
Nicole takes this very rigorous analytical method to test those hypotheses and looks at these nuances which have huge impacts on what actually happens on the ground. It has completely changed my way of thinking about how to apply these theories to what’s going on in the real world versus in practice. I just wanted to give her a shout-out for that.
Nicole: Thank you. It’s been lovely working with the team. Jez was much more familiar with the lean movement than I was, even with my accounting background. It’s been a fantastic experience working with the team and I also have to say thanks for your patience. I’m really lucky I didn’t get kicked off the project that very first year when I kept saying, “No you can’t do that. No, that’s not how this works. No, that’s not actually a hypothesis.” It was great though.
Jez: It was enormously frustrating, but if you hadn’t done that we wouldn’t have proper science. This is hilarious because I’m doing science projects with my kids right now, who are six and eight. And I’m saying, “Okay, before you design the hypothesis you have to create a theory.” And my kids are rolling their eyes and my wife’s rolling her eyes. And I tell them “Listen, I’m just channeling Nicole here. We’ve got to do it right!”
Nicole: Sorry y’all.
Jez: I’m passing it forward, what can I say.
Nicole: Love it.
I like that. I have a 7-year-old girl and a three-year-old boy. Yesterday, we went to Maker Faire, and I loved seeing them discover these things. I think it’s amazing to see how their mind naturally understand this whole experimental thing, and the scientific approach if you just find a way to explain it to them.
To wrap-up the culture discussion, there’s another thing that I found really interesting. Having worked for enterprise companies for a long time, I don’t know how many leadership classes I’ve either willingly or unwillingly been forced to go through. I was really interested to get to the point in the book where you guys talked about transformational leadership. I was not actually expecting that. So, I’d love to hear a little bit about how you came to that idea and where have you seen that come out in the research.
Nicole: I think this was sort of the culmination of a couple years. We’ve been looking at the Westrom culture typology for a few years. We’ve been batting around what leadership might look like. I’ve been digging into the literature. Lots of people at conferences were asking how to make a difference, and wondering if it was with org design or something else.
Traditionally DevOps was a grassroots movement, but now that it’s getting all of this traction, organizations are trying to make a difference. So what does leadership look like? I started digging into the literature. I wanted to see what might be a really good application and set of hypotheses to test. Some people were saying, “Maybe it’s transactional leadership, maybe it’s servant leadership.”
But it turns out servant leadership is nice, but that doesn’t tend to have predictive results. It doesn’t tend to have outcomes that really drive something for an organization. But, transformational leadership does, particularly in contexts that look like something we would be looking for in an obviously transformational sense. In technology transformation, you’re trying to move from one state to another.
I pulled up a model of transformational leadership from a paper from Rafferty and Griffin, that had five different dimensions. It has these five characteristics of a transformational leader that at least looked like it was really promising.
- Vision: a clear understanding of where the organization’s going and where it should be in five years.
- Inspirational communication: you can communicate in a way that inspires and motivates even in an uncertain or changing environment, like tech.
- Intellectual stimulation: you can challenge followers to think about problems in new ways, which is exactly what we want our teams to do. We want our teams to be able to do it, not just the leaders.
- Supportive: you can demonstrate care and consideration of your team’s personal needs and feelings.
- Personal recognition: you want leaders that can praise and acknowledge achievements, goals, improvements, and work quality. Leaders can personally compliment others when they do outstanding work.
We tested this in the 2017 study. I was really excited about the results because we found that leadership does play a role. It does have an impact. But what it does is it has an impact in supporting all of the rest of the work that happens.
It has this bolstering and amplification effect. It helps support the technical and process work, which, in turn, has follow-on effects to everything else that happens. Which, in turn, helps with software delivery performance, and helps organizational performance. However, leaders alone can’t do it themselves. So, it’s definitely worth investing in creating and building strong leaders.
It was interesting that you said you’ve been to a whole bunch of leadership classes, which is great, but I’ve also seen companies where they’re in this hyper-growth stage. They have to build up their tech team quickly so they’re just promoting team leads and technical leaders as fast as they can, but they never learn how to be leaders.
Or you’re still in this grassroots movement stage, and you’re not totally sure what to do. Like what does it mean to be a leader? Maybe you don’t even have people reporting to you. You don’t have to be a manager to be a leader. What types of things should you be focusing on?
Jez: Again, this is something that we really see a lack of in the tech industry. Firstly, this idea that you don’t really need management or leadership, you just need to hire the best people. I think that’s completely false. This is one of the things that our study on culture and on leadership echoed. For example, Google’s Project Aristotle research where they looked at how to build great teams at Google, found that what’s important is the relationships between people on the teams, not just the individuals themselves.
The “cult of tech” says if you hire the “A” player then it takes care of itself, but that’s not borne out by the evidence. The other thing that Nicole talks about is the idea that we’re just going to find the great technical people and promote them. It becomes the Peter Principle really quickly. The same things that make you a great engineer are not the same things that make you a great manager. I just wanted to call that out in particular, because it does adhere to things that people in the tech industry believe are true that really aren’t.
Nicole: Oh, and that’s such a great point, Jez. Technical skills are important, but they are skills, and so are leadership skills. This is something that you should absolutely try to learn and grow, and it is something that can be taught. This is an investment that organizations should be making in their people and in their leaders, if they really want to be excelling, growing, and amplifying the rest of the efforts throughout their organization.
Jez: By the same measure, technical skills are things that you can learn. The idea that you’re just going to hire these people who were born to be brilliant is completely false. Technical skills can be learned just as well as any other skills. I think that the third problem we see in our industry is companies want to hire people with the right skills, rather than investing in helping people develop the necessary skills. This is tremendously short-sighted in an industry where technologies and skills change on such a frequent basis.
Nicole: It’s short-sighted, it’s expensive, and it’s crazy. I mean we quote Adrienne Cockroft in our book. When he was at Netflix still, everyone would ask him where he hired his amazing engineers. He responded, “Well, I hired them from you.”
You can spend a ton of money by going out and poaching incredible engineers for an ungodly amount of cash, or you could grow your own people. Then they know your company, they know your infrastructure, they know the context and they’re loyal.
As the transformational leadership research shows, just hiring the best people and setting them free isn’t enough. This was actually what McKinsey tried to do for a number of years in the 90s. There was a very big and very famous organization that followed McKinsey’s research very rigorously and just hired the best people and let them go on with it. That company was called Enron.
Nicole: They did. They made a ton of money. Didn’t go so well.
That’s definitely one of my hot-button issues. Just as the idea of management, hiring, and promotional practices within technology. Because it tends to be attached more to performance in your current job than this idea.
There are characteristics that really can drive performance from a leadership perspective, and there are characteristics that can drive performance from a team perspective, an individual perspective. It’s good to see that technology is an industry that is moving in the right direction, and starting to think about these type of things.
DevOps Makes Happier People
I was just listening to an interview about Netflix a couple days ago and talking about the culture that they developed there. This is so important because you can make all these technology changes, but if you don’t think about the culture you can end up deadening the impact of all you invested. One thing you said too, that was a little unexpected for me, was the idea of the correlation between this DevOps culture and job satisfaction.
I’ve heard about Agile and job satisfaction in other places, particularly having been on the product side. I liked how you guys pull that in as well. That you did an NPS survey about how satisfied people were with their current environment, right?
Nicole: Yes. We did surveys with satisfaction, happiness, and identity as outcome measures, and NPS was one of them.
It seemed to be a strong correlation in the ways that I’ve encountered. You know, the argument for DevOps is usually that if you implement devops, you’ll be more effective and you’ll get code out quicker. I mean that’s great, but if you want to attract better people, retain the people that you hired, and have a high job satisfaction, you need to implement this. It seems like you can make an argument that this is one of the most effective ways to job satisfaction for the companies that are trying to go in this direction.
Nicole: Absolutely. So many companies right now are trying to hire. We found that in high-performing teams and organizations, their employees were 2.2 times more likely to recommend their organization as a great place to work, which is huge if you’re trying to hire. Then we reference other research that found that having a high Employee Net Promoter Score (ENPS) drove revenues. I think that was researched by Bain & Company. So it ends up having this double effect of also driving revenues. It’s a smart investment.
What we’re finding is revenue from investing in smart technology transformation, whether you want to call it DevOps, tech transformation, or digital transformation. This involves more than just tech. It’s tech, it’s process, and it’s culture. This gives you a strong ability to transform your technology so you can delight your customers, and drive.
It also makes the work better for the people. It decreases burnout, it decreases deployment pain, and it makes your culture better. It makes your ENPS better, which makes it easier to hire. It has this great turnaround effect. It’s almost like creating a halo effect that makes a lot of things better. It does require some investment though. It is an investment in technology, but at the end of the day, it’s an investment in your organization.
Jez: Teams know that they need to invest in improvement work. Whether that’s building test automation, refactoring, improving the design of the software, or doing things which are not just delivering features. They’re told that there’s no time for that, that the focus needs to be on delivering the features.
But what the research shows is that that’s a really false economy, even in the short term. There’s definitely an argument for getting things to market quickly in the knowledge that you’re going to incur some debt, which is often called technical debt in the literature.
Martin Fowler has a good blog post about this. He calls it the technical debt quadrant diagram. But, when that keeps happening and you never have time to do anything, it slows things down. Because it becomes harder to change the software, which is the reason why you can’t get things done, by the way.
If you continue down this path of not doing improvement work, you’re going to end up with your feet stuck in concrete. Also, it makes people miserable. Imagine you’re living somewhere and it’s covered in garbage, and say that maybe we should go and clean up the garbage. Except people tell you that you can’t do that and refuse to give you any resources. The garbage piles up and it makes you more miserable.
So investing in improvement work will not only make it go faster and improve things, it will also make people happier, and then they’re more likely to enjoy their jobs. It’s a virtuous cycle. I used to work on projects where I would get rolled off the project and onto another project before the first project actually went live. And that’s fundamentally a miserable experience.
When you’re practicing things like continuous delivery, you’re getting feedback from customers and you see your features go live. That’s really motivating. No one who will practice continuous delivery, continuous deployment ever said, “Let’s go back to releasing every six months,” That’s just not something that happens. These things are all self-reinforcing, and it’s very dumb to continue down the path of say, just building the features, and thinking that you won’t have anything other than the worst possible outcome.
I like the way you describe it and it’s a great note to wrap this up on. DevOps is making the world a better and happier place one life at a time. I really appreciate having you on the show, thank you for this great discussion.