<iframe src="//www.googletagmanager.com/ns.html?id=GTM-TT8R4P" height="0" width="0" style="display:none;visibility:hidden">

“Competition used to be based upon physical and mechanical things. It's all of a sudden being based upon software, firmware, the ability to make things happen.”

RECOMMENDED RESOURCES

Projects & Presentations 

Leading the Transformation: Applying Agile and DevOps Principles at Scale

DevOps Chat with Alan Shimel: Gary Gruver, Leading the Transformation

Goto 2015: Leading the Transformation with Gary Gruver

Goto 2014: The Lean Enterprise with Jez Humble and Gary Gruver

People Mentioned:
Jez HumbleGene KimArjan Eriks

Companies Mentioned
HP EnterpriseMacys

Gary Gruver: An Innovator's Journey

Gary Gruver’s passion is transformation of IT in large enterprises. When I say large, that means working with companies such as HP and Macys to transform their software supply chain through automation and cultural change. In his book, Leading the Transformation: Applying Agile and DevOps Principles at Scale, he lays out what it takes from an organizational level to make long term, meaningful changes within DevOps inspired organizations.

In this Innovator’s Journey, I talk with Gary about his path to discovery of DevOps, how his vision compares to others in the field and what he hopes to accomplish through his work with large organizations.


Mark Miller: How did you get started? Did you do technology as a kid? 

Gary Gruver: No, not really. I was into doing other things. Gymnastics and different things as a kid and working up through that path. Not really technology until I probably got in college.

Mark Miller: Training wise, did you learn on the job or did you do some schooling?

Gary Gruver: Yeah, I learned on the job. I'm a mechanical engineer by training. I always tried to figure things out differently. I started in in a large QA organization and moved myself into manufacturing. Spent some time in manufacturing. Did supply chain for a while and then went into RD on the product side and eventually moved over more into the software, firmware stuff and that was definitely on the job training and learning.

Mark Miller: Time period for that. When was that?

Gary Gruver: I spent 22 years at HP and started in '89 in QA and spent a couple years there. Probably a couple more in manufacturing; maybe 3. Then a bunch in RD and the last 5 years there, I managed parts of the firmware organization for a while, earlier on, but I never really had the ability to influence and change it until probably the 5 years.

Mark Miller: Your mainly known for transforming large enterprise scale. You started that at HP?

Gary Gruver: Yes. There was a problem that needed to be solve. It was our biggest constraint is to have a software firmer when we got done. I sat on the outside and got frustrated trying to release products by not being able to get it done. I interviewed and got a chance to lead the organization, I think there had to be a better way.

Mark Miller: You are now making a living as a consultant based upon ...

Gary Gruver: The experiences. I felt like the organizations that I worked with to help transform how they did software development, taught me so much and what I realized is it's easy for engineers to go into organizations or to go to a Velocity Conference or DevOps Connect Conference and learn about what they need to be doing differently.

If the executives can't figure out how to engage the organization and take them on that journey to transform how they do development, the change is going to slow down or not happen very well. The engineer will come back with a spark of enthusiasm that the damp rag of organization resistance will put the spark out if the executives can't be there helping ban the flame and get the energy and start to create the momentum and start to get the change to happen.

What I realized is there's not a lot of resources out there for executives. I didn't have much. There's some consultants that have worked and helped them figure out how to transform it and how it works from the team up but there aren't that many executives who've done and been there who can offer advice. It's like, "As you get to this, make sure you remember to do 1, 2 and 3 because you're going to run into those challenges." There's going to be new and unique things that they find but there's no sense in repeating the mistakes I've already made and the bruises I've gotten along the way.

Mark Miller: Do you remember the first time you heard of DevOps?

Gary Gruver: Probably about 6 years after I started doing it. I didn't know it was DevOps. I published the first book and went back and forth …

Mark Miller: What year was that?

Gary Gruver: 2012, probably. That book came out and it was the journey that we'd lead for the last 4 years. I went back and forth. I met Jez Humble over it as I was looking for something different to do. He went back and forth.

He goes, "Oh yeah, this is great. I love it. This is a deployment pipeline.”

“It’s a what? We're just doing large scale continuous integration with a lot of automated testing” 

“No, no, no this is continuous delivery. It's everything. It's what my book’s about. It's a great example." He started telling the story and I probably didn't hear the DevOps turn until I met Gene Kim.

Gene Kim started talking more about DevOps. Then there was this confusing period of time whether it was continuous integration or whether it was continuous delivery pipeline or it was DevOps. There was a period it was confusing as to was DevOps just a cultural piece and continuous delivery was all a technical. I tend not to get stuck too much in the names but I think it's finally come down to DevOps is the umbrella that's all the technical and cultural but when you get into a lot of the details how to make it work, it's continuous delivery.

I started looking at it and I started mapping where do you get large organizations to go and how do you get them to get better. I tend to think about mapping continuous deployment pipelines because that is how organizations get code from a business idea to customer. It flows through that.

If you're thinking about where your biggest barriers to success are, what are the things you need to improve, you need to look how code flows though the organization. When you look at changing how it flows through the organization, you're going to have technology changes. You're going to have people who need to embrace it in their cultural change. It's all combined. That framework gives you the ability to think about where to start with the biggest improvements and how to show where to go look in your organization to figure out your biggest inefficiencies and ways to go fix.

Mark Miller: It seems like you're really in alignment with Gene Kim.

Gary Gruver: I am in a lot of ways. I think this idea of DevOps is how do you get it out there more frequently on an ongoing business. I think I'm a little bit different just based on my experience.

He spent a lot of time researching and spending time watching what the world class leaders of the world do in terms of getting it down and getting it out. I think a lot of those cases you either have very small organizations or you have large organizations that can work like they're really small in terms of having 10's of people that can work together to develop, qualify and deploy code.

A lot of my experience, though, has come from leading large organization where you needed to coordinate the work across more like 100's of people or 1000's of people as opposed to 10's of people. When you do that, I think you need different approaches. 

My impression is that Gene has spent more time working with enterprise organizations lately but I don't know that he's had that experience of how do you really get into an organization where you're coordinating work across 100's or 1000's. My impression is DevOps is really about coordinating work across teams and getting people to work together better to deliver value to the customer and you do that differently in the approaches you use is different for 10's then 100's of people. I think Gene, just based on his experiences and his backgrounds, tends to think more about applying the best practices that are happening with 10's of people and trying to figure out how to flip those on top of 100's of people. My experience from doing it is I tend to take a little bit different approach for the larger groups.

Mark Miller: It's interesting, I was talking to our generics yesterday. One of the things he said is he thinks that Gene is the missing link when it comes to being able to talk to the sea level suite. I thought that was an interesting observation in that Gene is actually the evangelist that gets to the top level of the company. Where most of the people, who we're talking about with DevOps, are starting at the bottom talking to the developers and moving up.

Gary Gruver: I spend my time at the top because I've been an executive. I know what it's like to be on a staff of a large organization trying to drive change and making things happen. Where I get my most value is in executive workshops. Where I get them setup and I get them started. I coach executives and that's where I spend my time. I think there's a lot of people that can tell you technically what to do in the details but getting an organization heading in the right direction, getting them heading there quick and starting were the biggest issues are I think is where my unique skill set lies.

Mark Miller: That leads to what are you most proud of that you've done so far?

Gary Gruver: I think the biggest change that I was most proud of was the biggest change at HP but I don't think it's what I've done so far. It was having the opportunity to be with a really strong group of people that changed how the platform development worked for an organization that fundamentally had a big impact on the business. I didn't do anything. I didn't write any codes. I didn't make any changes. I didn't do any of those sort of pieces. I was around a great group of people that did some amazing things and it was fun to be a part of it. Fun to watch people grow. Fun to watch people develop. Fun to watch how they transformed how the business could work. Most proud of what I did? I don't know that I did anything. Most proud of being part of the team. That was a pretty good team to be a part of.

Mark Miller: What do you see as your mission now?

Gary Gruver: Everywhere I go you get engineers that are getting excited and you don't see ... One of the biggest barriers I see is executives. They don't get it. They don't know how to do it. I'm trying to be that resource out there for executives. I'm trying to write books that really ... Wrote down everything I wish I knew before I started doing this and spending time coaching them because I wish I'd had somebody to help me and there's not a lot of resources out there.

I really fundamentally believe the opportunities for dramatic productivity improvements are there. At HP, we've got 2 to 3 X. I think as you look at other organizations who are developing software, are more likely were before transformation than after. I think that potential's there and if executives understood, the could get a 2 to 3 X improvement in productivity. I can't imagine anything else more important for them to be working on. Either they don't get that, that's possible or they don't understand the role or they don't understand how to make it happen.

I'm passionate on trying to fill that hole and help people. If you're a good manager, good leader, what you enjoy is watching other people become successful and I've done that within companies and now as I'm going to different companies, I'm really passionate about trying to help people and trying to help make them successful and starting to see the improvements that they've been able to make.

Mark Miller: You're new book is resonating. You've gone over 10,000 on the books, right?

Gary Gruver: Yeah, yeah. It's actually gone really well. Leading the transformation, it's resonating with a lot of people that are reading it. It's a 100 page book. It's not thick. It's not technically detailed or complicated. It's something that executives can read if they're on a flight. They should go pick it up when they take off and be done by the time they land and have a concept for what it takes to make this happen. Hopefully that's enough to get them engaged and start to try some great transformations into their organization.

Mark Miller: If somebody is in a large corporation at that level, that's what they need, I think. Give me the highlights, give me the cliff notes and then I can decide conceptually whether it works or not. 

Gary Gruver: Sometimes it's nice to get a few copies and spread them around the office because even if you know what to do and you're trying to drive the change, if you're the only voice out in the wilderness screaming, it's going to get discounted over a period of time. If you can get it spread around and get some of the leaders of the organization [inaudible 00:12:09] common terminology, common thought process to really when they get together and discuss it, when they say words they're talking about the same thing, can do a lot to align the organization.

One of the key challenges is where to start. Next one's, how do you get everybody on the same page for what you're going to go do and how you're going to go on this journey. I think common terminology and thought process helps there a lot. 

Mark Miller: When you look back on your career, say you're looking back on the future, what do you want your legacy to be? When you walk off, what do you want the legacy to be? 

Gary Gruver: That I was able to help a lot of large organizations figure out to modernize their software development processes so the world can see the benefits of all the great leading edge ideas that you can do with software these days. 

Mark Miller: Are we really in a transformation era right now? Is it going to be that big of a change? 

Gary Gruver: I think so. Look at cars. You go out to buy a car, you no longer look at the engine. You no longer look at any of those other things. You look at the software and that. If you look at tractors, from what I understand, in some cases, people don't drive tractors. They program them and they go out and run in the field. Think of the benefits.

Think of the ever rising cost of healthcare and the fact that in the US, healthcare costs keeping going up faster than anything else but we can't necessarily provide all the services to our entire society. What's the opportunity to fundamentally change the healthcare industry? Ever industry, automobiles, healthcare, farming, manufacturing. Everywhere you look competition used to be based on physical and mechanical things and it's all of a sudden being based on software, firmware, the ability to make things happen.

I think the opportunities are huge and it's much easier to come up with quick ideas then it is to get them out and done. I think we've got to change that. We've got to make it much more efficient and easier to get ideas done and get them in front of customers. Learn what's not working, what's working and adjust and then figure out how to make that happen. That's the whole [inaudible 00:14:27] what that's about but if you haven't taken the efficiencies out of your processes from going to idea to get in front of the customer, you're not going to take advantage of those concepts. Where a lot of organizations are still stuck is the time it takes to go from a business idea to the customer in the customer's hands is way too long and more efficient. That's where my passions and energies are.

Mark Miller: It seems as if, if you could codify or document the process in a way, you personally could change an entire industry retail as an example.

Gary Gruver: Right, yeah. Where I'm getting down more and more as I work with more and more companies and I'm going in and I'm seeing common patterns and different things, there's opportunities for ways. I'm spending more time trying to come up with using the deployment pipeline is how do you take an architecture and break it into small pieces. How do you create the deployment pipelines because if you're going to develop code and deliver it on a more frequent basis while maintaining quality, security and everything else, you need to take a lot of waste and inefficiencies out of the process. I think the processes are the deployment pipeline and once you understand how that comes together, you can start mapping it with some metrics that go tell you where to go find the biggest opportunities for improvements and then you can start improving that over time and continually improving that process.