Where Digital Transformation Fits In: A Q&A with First Round’s Howard Morgan

Recently, Early Adopter Research’s (EAR) Dan Woods had the chance to sit down and have a conversation for the EAR Podcast with Howard Morgan of First Round Capital about digital transformation. Their conversation covered the history of digital transformation and how it fits into the larger story of technological change in general. This is an edited version of their podcast.

Woods: Can you tell us about your background?

Morgan: I’ve been in this crazy computer field for 60 years. My first computer experience was in 1959. I was a professor of computer science for a number of years at Cornell and Cal Tech, and University of Pennsylvania’s Moore School and Wharton School, where in the ’70s and early ’80s we started to apply big databases and computers to various parts of digital transformation—we didn’t call it that back then, but businesses getting onto computers. Then, in the ’80s, I started in the venture capital world working with a number of different companies, eventually leading to two that I’m associated with today: First Round Capital, which is the leading seed-stage firm, which has invested in everything from Flatiron Health, using big data for healthcare; Uber, which started in our San Francisco office; and also, more recently, as chairman of B Capital Group, a slightly later stage fund that’s a partner with the Boston Consulting Group—which itself is partnered with a venture firm because of their clients wanting to do digital transformation.

Digital transformation is a vague term. It’s not exactly clear what anybody means when they bring up digital transformation. What is the meaning and actual implementation possibilities for what is called digital transformation today?

It is the understanding that if you can get all the information about all the things that are happening to your business into a database form, into digital form, you can then manipulate that in ways that allow you to then manipulate the real world more efficiently, and spend less money. You can put things together that you couldn’t put together before. It could be in manufacturing processes, where we’ve seen over the last 30 years supply chains collapsing because you have the information about where inventories are at your suppliers, so then you can get to the kaizen, you can get the just-in-time, integrating with the outside world.

It can be transforming the way you interact with your employees in HR, being able to provide benefits and information to them in an online way so more of them take advantage of, for example, better wellness—so your healthcare costs go down. It’s a whole bunch of related things that say that, if I had all of the information about my business accessible in real time, then I can do things differently. I can create new processes and get the benefit of them. And that’s both internally and interacting with suppliers and interacting with customers.

I agree with you that data is at the center of this. I think that when most people are attacking digital transformation, there’s a process going on that starts with evidence, that leads to awareness, that then allows optimization and innovation of something, and then eventually is put to work as much as possible through automation. This needs to happen under two general properties. One is of agility, to be able to move fast, and incrementally and get evidence. And then the final one is to also at the same time be involved in making sure that at every stage you are in an operations environment. At the higher level, what goes on top of that, that’s very different for each of the businesses I’ve seen. What I’d like to do now is I’d like to go back to some of these previous ideas that we’ve seen in past eras of business, and I’d like to talk to you about what you thought was learned in each of those eras and how those compare to digital transformation. Let’s start with business process re-engineering. You lived through that era in the late ’80s, early ’90s, and so what can you say about it?

That era was one where we were just starting to get this integration of suppliers and companies, for example, and so a lot of processes around ordering, around supply chain management, around ERP allowed us to change the business processes that we were using. Once we were aware of the problems, we could optimize inventory levels of working capital inventory, working parts, and cut down working capital needs. It took a long time, because people had to look at their entire manufacturing processes. At the same time, we started seeing business process re-engineering in the sales area, where when we got tools like the earlier versions of the Salesforce, we were able to now manage sales teams and sales people and how they interacted with customers and figure out how to re-engineer those processes to better focus the right sales people on the right customers, to see what the norms were, to get better metrics to figure out who were good and not so good sales people, not just by some numbers, but by a lot more detailed measures along the way.

So that business process engineering took us a little bit of the way, but it was two or three links in the chain from a raw material, whether it’s data information raw material or physical raw materials, to the product and service delivered to a customer. Now, with what people have called digital transformation, they want to go the whole way. They don’t want to just re-engineer a piece of the process, but they want to re-engineer the entire end-to-end piece.

I think that the lesson of business process re-engineering, which, was about saying let’s look at our processes with a fresh eye, let’s see what how we could work differently and perhaps more optimally, was that the IT systems underneath it were just not agile enough; they were not flexible enough. It was really hard to change what they did. And then the software development wasn’t nearly as easy, and the amount of analytics and other capabilities were all much harder to work with, so you couldn’t create a halo of information and automation around a new process very easily. When you could, you got tremendous benefits from this approach, but when you ran into IT transformation issues, it was much harder.

I agree, and one of the issues was when you had to put together separate systems, when you had to put together, you know, the purchase order system and the inventory management system and so on, it was very hard in those days. When you tried to do joins on multiple databases, it was very hard. And you didn’t have real-time information in many of these systems; they were still batch-processed systems, so that you couldn’t do it in a manner that gave you a real-time view of what was going on. And that has changed with the advent of both data warehouse capabilities and systems like Looker and Tableau and so on that let you pull together a lot of information from separate—what are seen to be separate databases, but pull them into one view for management to help work on that transformation.

The next development I’d like to discuss is Total Quality Management from Deming. Deming had so many things to say underneath the umbrella of Total Quality Management, but the main one was that the highest quality product was also the lowest cost product, and was really about focusing on quality at every level and trying to make sure that no stone was unturned.

Deming is a god in the auto industry and led to the whole Six Sigma revolution. Both TQM and Six Sigma get at the same thing, which is, if you make things right the first time, then you don’t have to go back and fix them, and you don’t have all the costs of going back and fixing both the outputs but also the processes along the way. And it also looked very heavily at statistical quality management, so that you saw things were moving out of norm early in the process. And using statistical quality management, which led to TQM, and then the Six Sigma world, which GE was a gigantic proponent of and trained people all over the world in, had a huge impact.

Because it really was true that if you had high quality, then you could have lower cost, and you have lower cost because you didn’t have re-dos, you didn’t have scrap, you didn’t have wastage, and that quality came by huge amounts of inspection of everything moving into the process, huge amounts of statistical quality control of whatever process itself was—whether it was bending a piece of sheet metal, whether it was soldering components onto a printed circuit board—but when you are monitoring the components coming in to be put on that printed circuit board, and then you are monitoring the welds and the soldering that was going on, making sure that you ended up with 99.9999—the Six Sigma—percent of your products working the first time out of the gate or first time off the production line. And that was a huge savings, because yields went up, and if yields go up, the costs essentially go down. That was a revolution on the manufacturing side.

We didn’t see the same revolution in things like insurance claims processing, for example, or places where there was still much more human judgment in the process, until 10 or 20 years later. I think we started to see that in the early 2000s, where people started to be able to monitor human activities.

I agree with you. One of the things I think that GE did that was really important was extend the idea of statistical analysis and Six Sigma beyond the manufacturing world, and to apply it as a general management principle. Now, of course, when they did that, you could never do as well as you were with all the data in terms of creating really precise models that you got in manufacturing, but you were able to get a better view of what was going on from the data that did give you new ideas and new ways of optimizing processes. And you said that this happened in a variety of industries; it took a longer time for this to be something that actually paid off.

I think it started to be applied in areas like insurance claims processing and in financial decision making, credit decision making, where you could use the same statistical techniques and the same Six Sigma ideas, but the quality control pieces weren’t quite as simple as they were in getting precise measurements of a part coming in to make sure it was within spec. It involved people processes, it involved figuring out what the norms were. How long should somebody take to make this kind of a decision? What factors you want to make sure that they look at, if it’s a car insurance claim, how do you make sure that they actually looked at all of the costs associated with fixing that particular problem in a car, and they went—they did the analyses of all the costs there. But it did lead to Six Sigma being extended into the non-physical goods world, into the human decision-making parts of the world, and starting to then collect the data that can be used to drive statistical measurement for decision-making.

Those two things led in a way to the definition of the Toyota production management system, and the way it was described by American academics as “lean manufacturing,” and with associated practices like kaizen. This became codified in manufacturing first but then it became generalized and led to stuff lean startup and the entrepreneurial operating system. How have you seen that transition take place, and what do you think we learned from it?

Well, I think Eric Ries’ Lean Startup was around the idea of, “move fast, build a minimum viable product, incrementally improve, and do that over and over again in a very rapid cycle.” And that started to be adopted by very large companies in innovation, allowing their people to start building changed systems, new systems, particularly when they had information that they could use to interact with customers. For example, one of the big companies I’ve done some work with over the years is John Deere, and they started having their folks use agile software development in their finance insurance agencies and John Deere finance companies about 10 or more years ago, and that completely transformed how quickly they could respond to changes in the needs of the farmers and the dealers that they had as they wanted to put out new financial products. And that agile development and scrum methodologies and that meant that they could run through and test and put into production four or five times a year versus once a year or two-year cycles for IT that were the norm before that. So it has had a major, major impact.

And I think now we see lots of large companies have these innovation units, particularly with the advent of mobile apps, and saying, “why can’t I do this with our company information?” And the initial reactions were, “Well, they’re insecure, you can’t do the security, we don’t have an easy way to connect this database so that you can access it from a mobile device.”

The way I see it progressing was that the lean manufacturing concepts were abstracted in a meta form that then became lean startup type activity and the other ideas that are related to it. I think it’s probably accurate to say that the agile and scrum development methodologies that you mentioned emerged separately as well. I don’t think they generally saw their roots in lean. But they used the same philosophy and amplified the idea of being suspicious of requirements and being able to reduce things to the smallest possible implementable chunk and then getting evidence. And that idea I think, you know, is really what eventually powered the innovation programs and made them much more successful.

I would agree. All of that really is part of the growth and the ability for software and software development to change. And when we changed from classic SQL, C++ development into development that really created reusable pieces of code—which was something we always had wanted and always talked about but could never do—but when you got chunks of code that you could reuse and plop in and you build things very quickly with very high-level subroutines, you could do development much more rapidly.

This brings up another point and that is the idea of how you organize larger efforts that involve many different teams and many different programs. And agile and scrum really doesn’t have an answer for that. Most of the digital transformation efforts that I’ve seen going are very much informed by the idea of agile and scrum or lean startup, minimal viable product, iterations, keeping things implementable and not having everything be off in a separate area where you’re not getting real evidence. But what’s lost in that and what I think has been not really emphasized enough in the agile/scrum community is, it’s not like you iterate yourself to some perfect design or perfect product. There is still a design sensibility that needs to guide where you want to go.

Without that design vision, you don’t know what the limits are for what you can pull together, so I would agree with that. Design vision is an important piece of it all. But I also would say that the design vision has to understand what kind of scale you’re going to get to, because one of the biggest changes in the last few years have been things like the Lambda architectures, the server-less stuff, where you build scalability in from the very beginning; you build the ability to go to massive scale, which most of the consumer companies have had to do, but we’re now starting to see industrial companies having to get to much bigger scale than they thought once they allow their customers to get into the systems, and look at their orders, and look at where their order status is, and look at all the other pieces of it.

I’d like to now talk about three other trends that are mostly about that design vision. We don’t hear as much about in digital transformation, because I think digital transformation is fundamentally about imitating that rapid innovation cycle and making technology and data more important in what you’re doing. But I do believe that there is a proven need for coordination in a flexible way. One way of doing that is the methodology called the Balanced Scorecard, where you set a set of metrics that you’re trying to achieve and you devolve that down into smaller metrics and various programs so that eventually, at every level, you have a unified tree of metrics and goals that you’re trying to achieve and metrics that track them, so that you can keep an organization running and measured according to a larger master plan. Have you seen that work well, and how would you say it relates to digital transformation?

I haven’t seen it used directly that way. I do think that at some companies, like Goldman Sachs and a few other places, where they have this broad vision for how all their information is going to be used and shareable across the organization, they do have metrics for how shareable it is and how much is used by which people and how they can create in interfaces so people can get at that data without really being responsible for the data—that is, groups are responsible for getting data into the database, and then other people who just want to be users of it and pull it back out for analytics or various kinds of decision-making. But I’m not as directly familiar with the Balanced Scorecard method.

The idea of it is that you have a vision that’s an umbrella at the top that you devolve down so that you essentially have a design vision for what you want the performance of the business to be. Now, I think that that’s been transformed and re-invented in the tech industry, and most prominently through Intel’s Objective and Key Results, the OKRs, that were introduced to Google and used as a way of organizing and coordinating the larger-scale efforts and coordinating across larger, multiple groups of programs. Are you familiar with the OKRs, and have you had any of your companies use them to good effect?

Very much so. John Doerr has his book, Measure What Matters. It goes into a lot of detail about the whole OKR process, which he kind of pushed into Google, which has then spread it throughout the vast startup technology world. And yes, OKRs are really a good thing. The issue has been at Google and other places, they try to do some of it on a quarterly basis. You just can’t do it on a daily basis. You’ve got to do it on big enough chunks that the measurement isn’t taking up much of your time.

But it is a great technique. We’ve put it into a number of our startups, particularly between the C-suite level and the next two levels down, really having good sets of OKRs that they have to meet on a quarterly basis has been a terrific thing for helping people understand what to be focused on and what to stay focused on, and whether or not they’re achieving. And if they’re not achieving it, why aren’t they achieving it, and should it be changed for some reason, or should they be changed.

How would you describe what OKRs are and how they’re used?

What you do is you set a set of goals which have measurable outcomes for the next quarter—typically three—that, if they’re achieved, will really advance the organization’s objectives. And an OKR might be to launch a particular product, it might be to get a certain number of customer wins if you’re on the sales side. And then you look at what key results are needed along the way so that you can monitor it during the quarter and you and your manager go over those OKRs at some regular intervals. Could be monthly, could be weekly sometimes. And then everybody in the organization looks at them all at the end of the period and says, which ones did we get, which ones didn’t we, what do we have to change? But it keeps people focused on a few key objectives, and when they’re doing something, they can always look up and say, “Is what I’m doing today helping me meet my OKRs for this quarter? And if it isn’t, why am I doing it?”

This provides that umbrella, that design vision for the organization, in a way that is practical and actionable and can keep people focused without having to have some massive document or some other method. It just seems a very simple way of expressing a design vision for what a company should do. I believe that the digital transformation efforts that I’ve seen are weakest when they are talking about this larger vision and how to enforce it and attract it. I think that the OKR method could be profitably used in most of the digital transformation efforts that I’ve seen. I also wanted to talk about the way that Amazon brings a lot of this to life in its API and service-based structure. What has become known as the Yegge rant, that was a leaked document from Jeff Bezos many years ago demanding that everybody at Amazon make the services of each department available to each other through APIs. And it was essentially a very strong forcing function in which the CEO pounded the table and said, “I want you all to think of yourself as services, and I want you to expose those services to people, using APIs,” and that, I believe the idea was to reduce friction and to reduce prior restraint so that the organization could take advantage of what each part of it had to offer without so much conversation. That has led to an organizational structure that is based on looking at the organization essentially as a bunch of services that are constantly optimized, evolved, extended, refactored, and it’s almost like a service-oriented business architecture. Are you familiar with the way that Amazon does that?

Yeah, I am, and I also know Werner who basically created AWS as part of that, which is to say, make all the hardware available as an API, which led to the whole cloud world that we know of today. And I think that’s been very important because it allows different groups to interact without knowing the innards. I mean, over the years, what we found in programming was, you had a subroutine, and how tightly did you have to bind to that subroutine, and when was the binding done? Was it done at the compiled stage, or could it be done later on, at the execution stage? And the more we’ve gotten to be able to defer binding by having good, clear APIs so you don’t need to know what’s going on inside a root set of code, the better. You just need to know what are the inputs to that, and you can take the outputs and feed them to something else. That’s how programming has advanced from taking years to build things to taking minutes. And what Amazon did was making not just the coding in that organization act that way, but everything the organization did, whether it was HR pieces, whether it was acquiring additional pieces of hardware to run things on, whether it was warehousing goods so that they could also then externalize warehouse, and now you can store your stuff at Amazon if you’re a small business and you don’t want to deal your own inventory, Amazon will store it and ship it for you. And that all came about from that change, which was not forcing everybody to deal with every other part of the organization, because that would have led to chaos, but to create its interfaces, its APIs, that anyone in either the rest of the organization internally or later on, as with AWS and Amazon storage, externally. And that meant that you could really expand your company, and obviously, Amazon’s done that in spectacular ways.

What do you think the lessons for digital transformation are for all of these past programs and transformation methods?

The more you can encapsulate a piece of what your organization does and have and then have the interfaces to that encapsulated piece be available to the rest of your organization, the faster you can get to this total transformation—which is to say, where your internal players, your customers, your suppliers, and everybody can interact with you in a very efficient way, cutting down working capital costs, cutting down time, cutting down people costs. I spend a lot of my time working for other companies. How do I do that? I put in information in their databases online, rather than talking to somebody there who’s entering it. I do my ordering—I go to the restaurant that I want to make a reservation at 3:00 a.m. when the restaurant would normally be closed because OpenTable lets me do that. So I think for organizations, the more you can encapsulate your functions in ways that can then be exposed to the rest of the world safely, the faster things and the bigger your customer base becomes and the better your interactions with them become.

Author: Jennifer Walker