Ep 8: Why The Best Business Process Wins with Former General Electric CIO Gary Reiner

Evan: Hi there and welcome to Season 2 of Enterprise Software Innovators, a show where top technology executives share how they innovate at scale. In each episode, enterprise leaders share how they’re driving digital transformation, and what they’ve learned along the way. I’m Evan Reiser, the CEO and Founder of Abnormal Security.

Saam: And I’m Saam Motamedi, a general partner at Greylock Partners. 

Evan: Today on the show, we’re bringing you a conversation with Gary Reiner, the former CIO of General Electric. Gary was an executive at GE for almost 20 years, where he spearheaded the use of SaaS applications to modernize business processes. 

Evan: ​​Today on the show, we’re bringing you a conversation with Gary Reiner, former CIO of General Electric. Gary was an executive at GE for almost 20 years, where he spearheaded the use of SaaS applications to modernize business processes. Today, he is an operating partner at General Atlantic, a leading global growth equity firm with 79 billion dollars of assets under management. He also sits on the boards of multiple GA portfolio companies including Atera, Zoomin, and JumpCloud.

Saam: In this conversation, Gary shares why he believes the best business process wins, his surprising take on packaged solutions, and the meaning behind “lean before digitize”.

Evan: So Gary, one of the really interesting things about your career is just the length of time you spent at GE during a very transformative time in technology. Can you talk about some of the moments when technology really changed the way the business operated?

Gary: When I took over sourcing, one of the things that became clear was that our engineering teams were too often specifying what the sourcing people had to buy and it gave them no ability to negotiate. And so we really encouraged each business to dedicate about a third of their engineering to create specs for things they were buying in such a way that they would at least have two or three suppliers for every component they were going to buy.

Now, once we did that, we actually created what I think was the first ever E-auctioning tool. And what we did was we basically had our suppliers who were competing for GE's business, agree to all the other specs. And then the only thing remaining was price. And that's what the technology was for is to create a bidding auction for price. 

And so we rolled that out and every one of our businesses use it. I want to suggest that we probably had about 4% deflation on a $50 billion buy, which is about a $2 billion a year savings.

I'll tell you one that's outside of GE that I was just so impressed with. It was Jeff Bezos at Amazon. And this was about three years ago. He announced that Amazon was going to spend a billion and a half dollars more than they planned for technology because they wanted to get from two day delivery to one day delivery. And their stock went down that day, because their expenses were going to go up. And all I could think about was that is such a home run way to think about technology spend, which is figure out what's important to you.

And in their case, what was important to them was that a consumer be able to order and get a product in a day, that that would be an enormous competitive advantage. There's a lot one should be willing to spend on technology to go from two days to one day. And they did it and it's successful, and it continued to allow Amazon to grow. That's to my mind, the right way to think about technology. Not do I put an ERP system in or something like that. I mean, all that's great, but technology should be there to support a business process that's going to give you a competitive advantage as seen by your customers.

‍Evan: Are there specific moments in your career that you deployed some new technology that maybe had an unexpectedly big impact on the company? And in hindsight, it was more transformative than you originally thought?

‍Gary: Yeah. This was in 1999, 2000. And we were at GE a very global company, and we were looking for ways to collaborate better. And this was before the era of Box and Dropbox and OneDrive and the like. And so we put together a team and said, "Let's build a collaboration tool." And it seems so obvious now, right? With the success of all of those companies, but at the time there was nothing there. And so we created something called SupportCentral, which was something where people could post, save files into folders that they could create and then allow permissioning in terms of what people could do with it. In terms of reading it, editing it, deleting it, so on and so forth.

And we thought it'd be a fun thing for a few people to use. It ended up getting like, I don’t know, 10 million hits a day in terms of people using that technology. And it became totally embedded in the way in which GE employees worked and collaborated.

‍Saam: I'm curious, by the way, did you all interact with the file sharing companies like Box and Dropbox as they emerged? And did they look at you at all as a reference example of what they could build?

‍Gary: I don't think so. Coincidentally, when I joined GA, we invested in Box in 2011 and I joined the board of Box. And one of the first things they wanted to do was use me to help sell Box to GE, which it did successfully. And as a result, SupportCentral was shut down. So that's the end of that story.

‍Saam: I didn't know that. That's quite interesting that you actually spearheaded building this at GE. And then were on the other side of the table on the board at Box and kind of helping evangelize and successfully deploy Box inside GE. What are the learnings there both on GE's side and also on the vendor side in Box?

Gary: I think when you go in with packaged software, you're selling to thousands, sometimes tens of thousands of customers. The economics of a packaged solution, assuming it meets the bulk of your needs, is going to be dramatically better than having built something just for yourself, where you have to maintain it. And all of the cost of it has to be incurred by you yourself as that company.

One of the reasons why IT is such a outsourced industry is because the needs of so many different companies are common. And because they're common, you can have a very horizontal approach to delivering software as a vendor. And as a customer, you can get the value of those economics, because you're basically sharing the cost of having developed those economics with a whole bunch of other customers that have common needs to you. And so to your point, I'm a huge believer, as are most people, in using packaged software wherever you can.

Saam: Maybe to ask the flip of that, are there examples where the consensus view was one should use package software, that at GE you decided not to use package software, you actually thought building and investing in-house ended up being the right decision?

Gary: I can think of none. And that was over 20 years of looking. I mean, if you took the most proprietary thing that GE did, it was developing the inside of an aircraft engine. It was the single most sophisticated thing requiring incredibly high IQ people doing very, very sophisticated things. And yet when you looked for software that they needed, in order to develop those engine parts, there was at least three different software solutions they could use. Now, someone who was more NIH would say, "We need to build this, because it's strategic to us." That's not the strategic part of it. The tool was not the strategic part. The strategic part was the knowledge of the engineers that were designing it, not the tool itself. So I found nothing in 20 years where someone needed to build it themselves.

Saam: That's really interesting. I wouldn't have expected that. Especially the concrete example you just gave now, because to me on the outside looking in, to your point, it feels so proprietary and so related to the core competency of the business. If I think about some of your peers who are CIOs at other large organizations who make decisions to build things internally, why do you think those decisions get made? And what's the common mistake pattern?

Gary: The common mistake pattern is one, when you talk to the functional person, the salesperson, okay. Or the engineer, they believe their needs are unique. They're not willing to accept the fact that the tool that's going to support their approach is pretty common. And so the functional leader who in too many cases has a little more power than say the IT person in an organization would say, "I don't want to use that solution. It's packaged. Everyone else uses that. I want something where I can create my own competitive advantage." And that's the dynamic. It's not so much that the IT guy wants to do it. It's that they are told or strongly encouraged to do it by the functional leader for whom the solution is being built.

‍Saam: And so now that you're on the boards of both private and public technology companies, and you're talking to teams who are having to navigate these dynamics. As a vendor, how do I actually navigate that tension between the functional leader and the IT leader and successfully convince the customer to adopt my packaged solution in an area that the functional leader might view as kind of core to their business?

Gary: I'm going to answer your question, but I have to give a little bit of context. You know, my bias is to start with what business process that's really important to you, are you trying to improve? And then think about the technology that's going to support that. 

Technology is there to support processes. We used to have a saying at GE, which I still think is correct, which is lean before digitize. What that means is you need to do a ton of work improving the process, or at least improving your intended process before you roll out technology. 

We had actually looked at a lot of successes and failures within the work that we had done in IT at GE. And it was pretty much binary where if we had leaned processes first and then attached technology to it, it was successful.

And if we had tried to just take the technology that was there and support an unimproved process and an unstreamlined process, it was a failure all the time. It was over budget, it was beyond schedule and it was a disaster. And we had a few of each, so we could see both. So if people agree to that approach, then you lay out, say a sales approach, or a new product development approach. And you lay out exactly how it should go rather than how it goes today. And you get agreement from the relevant functional leaders that that's how it should go. It's pretty likely that the commercial packages out there will support that lean and improved process. It's when they think they have a unique process that is their competitive advantage, and it's not that they then insist on the bespoke and homegrown application.

‍Evan: What you said really resonates with me, of like - we've learned this lesson the hard way I think at our company. One of the challenges we've had is that when that process is not well defined, right? But we know we need something there, we buy the software and then the process becomes what the software best enables. 

How do you know when you should be designing the process that's kind of really right for your business from first principles versus you should try to let the tools influence what your process is? Given what you're saying about packaged software kind of generally being the general best practice. 

‍Gary: It is the hardest question and what you hope is that when you've laid out that leaned process, and then you look at what the package offers, you lay out the gaps. Like what are the gaps between what our approved process is against what the technology has to offer. 

We didn't find very often, Evan, that you needed to customize for those gaps. We found very infrequently that was the case. And we actually put a very high hurdle on teams customizing, because what we were concerned about was that means they didn't really lean the process as much as they should have.

‍Evan: That really interesting. And I think that if I heard that from a CIO from a smaller company, I'd be like, that's an interesting philosophy, right? But I think coming from you, if that's true at GE, which is a way more complex business than most companies. There's probably a lot more truth to that, just coming from you. 

So what's the implication of that for startups and founders that are maybe listening to the podcast?

Gary: If you're a startup building software to support processes, whether it's a selling process, manufacturing process, service process, make sure you understand what the best practices are in that case that you're supporting, so that when good customers are leaning their processes, they default to your solution. 

Evan: It sounds like you have a strong conviction about this, don't build the internal thing. Absolutely minimize customization, and try to find the right packaged software. How did you get to that philosophy? Was that something that you've always felt? Is it something you kind of learned from seeing it go poorly? What led you to that high conviction?

Gary: Internal failures. As they say, you learn more from failure than you do from success. This came from three or four failures that went on within the company where people tried to customize bad processes. I think a pretty good example. I think I'll just give you one. 

We had tried to build our own, effectively a CRM tool for our medical equipment business. We were selling MRI machines that were basically designed to order machines. They should have been configured to order, but they were designed to order machines. Too much flexibility.

And so we tried to build a solution, a CRM solution, that would support the selling of that. And we realized it was impossible, but we spent a ton of money trying to do that. A ton and it kept failing. And the reason it kept failing is we hadn't fixed the underlying problem, which is that we were a design to order product and it needed to be a configure to order product. I know that sounds a little nitty gritty, but it's so important. 

And we stepped back and we spent a year or two. From scratch we really kind of built up that equipment, that whole equipment design to be configure to order rather than design to order. And then it was pretty easy to build a CRM solution that would support that.

Evan: So you're kind of talking about the difference between technology being the objective versus the means to some other business objective.

Gary: Yes. It has to be that. In fact, I would say that the best companies in the world are the ones that have figured out ways to have the best processes, spending the least amount on technology, because the purpose of technology is to have great business processes. That's it.

Saam: I want to jump in just for a moment, because as I hear you talk about optimizing business processes, my mind jumps to AI and ML, right? As kind of really important secular technologies. And I'm curious if you could just comment on that. Like how you think about where we are in terms of AI/ML adoption in the enterprise.

Gary: The way I think about AI/ML is it is a component, an important component, but a component of allowing you to have a great business process. Okay. 

If we step back and we say, "How do you measure the quality of a business process?" There's three metrics and we use these all the time. The speed with which that process delivers value to the customer, so that's a time dimension. That's number one. Number two is the number of defects that get generated by that process.

And then number three, how much it costs you to deliver that. Those are it. So if you're, I'm making it up, someone applies for a credit card. So it's from when the consumer applies for their credit card until the credit card is in their hand.

Now, if you have a bank that does that in a day, and I have a bank that it takes 10 days, over time, you're going to kill me competitively. 

So back to AI/ML. One of the things that allows you to deliver it in one day versus me, 10 days, is the underwriting process. And one of the things that allows for a really fast and accurate underwriting process is the real time use of AI/ML to grab all the relevant data in real time, and rather than having humans look at it and approve it, that request for a credit card can be approved. AI/ML is a way to reduce defects, reduce cost, and reduce the time in front of customers to deliver value. And it's incredibly important. And it's something that can differentiate one competitor from another, because of their use of it.

Evan: And so Gary, your kind of mental model here is like, the goal of technology is to implement processes that are effective for the business. And some of those processes require complex judgements, which typically, maybe in the old world, were done with humans. And so in your mind, AI is a tool that allows us to now implement one of these sub-process that are focused on human judgment.

Gary: That's exactly right. That's exactly right, Evan. And I think the great companies in the world are those that understand that they are simply a set of business processes, customer facing business processes. And the winner is the company that has the best customer facing business processes. That's how they win. That's how Amazon wins. 

In any given industry, you look at who's the best at managing business processes. They are the ones that win. And oftentimes, Evan, to your point, it's who uses technology as a way to deliver that, that is the winner.

Evan: That's really interesting, Gary. One of the times we've chatted in the past, you talked about using Salesforce in the really early days. And Salesforce, when it first came out was a crazy concept, right? You're not going to deploy software on your desktop, it's going to all be in the cloud. And in hindsight, we kind of now know that's the future architecture, but at the time it was not obvious. What gave you confidence that that was the right path in the moment? And also how did you deal with all the people around you that may would have said you were crazy?

Gary: So we had a little bit of a diabolical reason for moving towards Salesforce and it comes back to what we were talking about. We were using the prior CRM solution, which was on-prem from a great vendor. But because it was on-prem and because we got access to the code, we customized the living hell out of it. And it became an incredibly expensive project in every case. Took much longer than we thought it would. So we could get every salesperson's needs met without leaning the process, our selling process, back to our discussion before.

Salesforce is in the cloud, it had its own source code. You had no access to it. And it was a way to basically say you can't change it. You got to use it pretty much as is. There'll be no customizing and there's going to be a bunch of leaning of processes before you use the software. And that became a big reason why we loved it and it worked. And it worked. Obviously the economics of cloud now are clear. And that was a reason as well, I won't lie about that. But the real reason we loved it was because you could not customize it.

Saam: Gary, we like to end every episode with a lightning round. 

Gary: Okay!

Saam: One thing I'm curious about is if you've read a book recently that's had a big impact on you and what book and why.

Gary: I love physics. And so in the non-fiction area, I read a lot about science and there's an author, Carlo Rovelli, Italian physicist who wrote a book called The Order of Time. It's beautiful. He's almost a poet the way he writes. It's both really enjoyable to read and it forces one to stretch your mind about what we're actually living in.

Evan: How do you think companies should measure the success of a CIO?

Gary: The quality of their business processes. If my business processes have the best costs, cycle time in front of the customer and defect count, I've got a great CIO. Now, I can't measure the CIO in absence of measuring the functional leaders, too. So I've got to measure my manufacturing leader and my CIO together. My sales leader and my CIO together. 

I can't measure my CIO alone, but I've got to measure him or her as how good are the business processes? A big part, I've learned, of being a good CIO is convincing the functional leader of this whole lean before digitize and building great business processes that derive competitive advantage. So there is an evangelical nature of a CIO to be that person, because you can see across processes. You can see across functions as a CIO, to be that person that convinces functional leaders to do that. But if I'm CEO and I'm looking at my CIO, if I've got great business processes, I am happy. If I don't, I'm not, with you as a CIO.

Saam: Maybe to ask the flip of that question, is there a common mistake you see CIOs who are new on the job make?

Gary: Yes. And there's fewer of these now than there used to be because of cloud. So back, pre-cloud, there were some, my view, lesser CIOs who spent their time in the world of infrastructure. And that was what they viewed their job to be. And that is a part of the job or was a part of the job. But the success or failure comes - how integrated you are with the business, how much the functional leaders and business leaders view you as a partner. Not you're off to the side, running technology, independent of what's going on. So the greatest CIOs out there are the ones that work very closely with the business and they just be the advocate for great business processes and for the technology that can support it. 

A large part of what they do is educate the functional leaders about the art of the possible. This is what we could be if we had this technology and a lot of functional leaders, they have other great strengths. They may not know that and this is what a great CIO can do.

Evan: What is a new technology or emerging technology you're most excited about?

Gary: There's technology that doesn't yet work that I'm really excited about. So is everyone. And it's a matter of when will they work, right? I mean, I think of nuclear fusion. Look, there's about four or five companies that are about five years away from - they're about two years away from proving that they can deliver something and about five years away from actually commercializing it. And that will be one of the most productive things in the history of the world in terms of delivering that. In terms of stuff that's available today, most of it's going to be what Saam talked about, which is the value of AI and ML in terms of providing real time offerings to customers that require the understanding of complex data.

Evan: That's awesome and interesting. Gary, thank you so much for taking the time to chat with us.

Saam: Your frameworks are just amazing. I'm really excited to get it out there. Thank you.

Gary: Oh, it’s my pleasure. It was fun.

Saam: That was Gary Reiner, former CIO of General Electric, and current Operating Partner at General Atlantic. Thanks for listening to the Enterprise Software Innovators podcast. I’m Saam Motamedi, a general partner at Greylock Partners.

Evan: And I’m Evan Reiser, the Founder and CEO of Abnormal Security. Please be sure to subscribe, so you never miss an episode! You can find more great lessons from technology leaders and other enterprise software experts at enterprisesoftware.blog.

Saam: This show is produced by Luke Reiser, Josh Meer, and Emily Shaw, and mixed by Jason Mack. See you next time!