Formatted Text
Speaker A Our next session, excuse me, is designing Governance Ecosystems and interorganizational relationships for creating value and innovations. All about thinking about design in terms of improving performance. And our first speaker will be Carlos Baldwin. She is a William L. White professor of Business Administration at the Harvard Business School. And I'm sure most of you know her work. She studies the process of design and its impact on firm strategy and structure of business ecosystems. Her work on modularity is extraordinarily well known. We're very fortunate to have her.
Speaker B Carlos Baldwin I want to say this is quite raw work. It is really fresh off of the pen and transcribed into PowerPoint. So I apologize in advance for any deficiencies in the presentation and the logic. And I also don't really know the length of this presentation, but I'll try to get through it. Yeah, okay. John is going to give me the high in the classic method of newspaper work. I will cut from the bottom and leave the rest to history. So I and others have argued here in this forum and other places, that the challenge for organizational design today is to understand and use distributed innovation systems. And that's what I'll be talking about today. Like, this is a distributed innovation system. This is a schematic of the Android ecosystem as sponsored by Google. The color coding is, let's see, yellow is what Google controls, not very much. Green is an outside supplier. It's like in a supply chain. None of that. Purple is complementors who voluntarily provide complementary products. And blue is open source. And this is just showing the flows of hardware and software from various places to the end user Google's ecosystem. This is only a piece of Google's ecosystem. This is android. So Google has a much larger ecosystem that bundles the imagination. And the first thing we need, I want to do this really quickly is in this context of distributed innovation, I think we need to clarify what we mean by design. Because one of the issues I have in the book, Design Rules, people think that when I say design rules, I'm talking about hierarchical design rules that a central designer reads out to other people. And that concept really is not sufficient to explain design in these distributed innovation systems. The classic notion going back to Chandler and many others, is that visible hands design organizations, managers, however, modular technologies decentralize both innovation, the technical design and the organizational design. And so in this ecosystem, there are many designers, and you can argue about whether anybody at Google's a central decision maker, but there is no truly central decision maker designing this organization. It is, as William said this morning, emergent. You put out some possibilities, some design rules, some APIs, and people voluntarily come and contribute and join. So inside each of these boxes, technical design, this is just a little bit of semantics. Technical design is the design of the task network. What work gets done. And organizational design is the design of a social system that can carry out the task. So that's a way of separating two parts of design as needs to be done to get any work done in our economy. So for purposes of analyzing large technical systems, let me define design as the intelligent matching of form to function. So a visible hand, these are always artificial systems. A visible hand proposes both a technical design and a contract structure. And invisible hands determine whether the match is good or bad. And when I say invisible hands, classic invisible hand going back to Alex Smith is the marketplace, the consumer generally. But here the invisible hands could be a market, could be a crowd, could be a bunch of complimentors, some set of agents not under the control of the designer who did the initial proposing. So today I'd like to make a very rough and preliminary argument as to why some matches are good or bad. I want you to imagine the economy as a vast network of caps and transfers. So this is actually a map of a subset of caps and transfers in the design R D organization of a single firm, Pratt Whitney. And you can see these are decision and information decisions made by different groups, teams, 54 teams that have impact interdependent impacts on other teams in general. In this one, the rows affect the columns. When I do these maps, the columns affect the rows. So the transfers go from column to row. There is a potential slow path of transfers. So you can go from the diagonal element to the off diagonal element. That's a sign of dependency to there, this element depends on that decision. But then that decision creates has an impact on another decision up in the very top and that decision has another impact and another impact and that can go on for quite a while in the process of converging to a working engine. Importantly, these transfers are not transactions in a classic Williamsonian sense. They are simply movements of information, material and energy between various parts, in this case inside the company. So transactions will take place within the task network. So here's a very simple schematic of a Smithy that makes a pothook and the kitchen uses the pothook. And there are lots of tasks and transfers within the Smithy and lots of tasks and transfers within the kitchen and only one very simple transfer of a pothook from the Smithy to the kitchen and then a transfer of consideration of some form of payment in the backward direction. So the reason that the transactions are few is that they are expensive and slow. So you need to do extra work to make a transaction. And therefore I would contend most productive work is done within transaction free zones. And I think that's very consistent with classic organization theory. In fact, we're in a transaction free zone right now. It was designed by our organizers. Thank you so very much. John and Manny and Simon. Fraser and Thompson observed that productive work must be protected from random disturbance. So we're meeting I thought we would meet in a classroom. We're actually meeting in this lovely conference room. We are face to face and we are physically bounded. There are also membership boundaries. We don't have two conferences going on simultaneously in this same physical space. And there was a transaction required to join the organization design society that presumably everyone in this room has engaged in that transaction. And we have resources to support our work. We have coffee, we have computers, projectors and lunch. And with respect to intellectual property, this forum is open. We did not sign MBAs to get in this room, and we are bound by the norms of scholarly recognition. So there is a kind of governance going on here. I submit that organization design is in essence, the design of transaction free zones and their boundaries. And this is a social undertaking. So the design of a system of production is a design of a social undertaking. And you need governance within each zone and across the zones and some modes of governance. This is a list of some possible modes of governance. So there's corporate governance within a legally constituted corporation. There's platform and contest governance. And that's something we're seeing increasingly today. So Hila was describing the challenges of setting up contest governance by NASA of a bunch of outside solvers, and that applies across legally separate transaction free zones. There's contract governance, which has been studied as infinitum by the transaction cost economies. So go see Williamson on that. And there's commons governance, which was described by Eleanor Oxtrom. And I would submit this forum. This transaction free zone is pretty close to commons governance with a little bit of hierarchy in the form of John and Maggie. And then there's open governance, which is, I think, on a spectrum of common governance. But we have membership and physical boundaries and open source societies. And many online communities do not have formal membership and physical boundaries, and they on purpose don't want such things. So I want to contrast corporate governance, which is hierarchical, and platform governance, which is the new form. I so love this notion of the zoo that Hanish and Dorothy are talking about, because what I'm trying to propose here is we should be expanding our views of species. And this is a provisional list of maybe some divisions of the zoo. I may have not have time to go into these two, but I do want to contest hierarchical and platform governance. Hierarchical is a Changlarian bureaucratic firm. Williamsonian hierarchy, what Simon was talking about way back when. And I want to start with a task structure consisting of a sequence of steps in a strict order aucdef, and at the end, outpots a product with value to users like this would be an automobile supply chain and assembly line series of steps very you must do them in order. You don't have a lot of choice about what comes 1st, second or third. They've got to be done in synchrony and that's a technology that is a task structure. We can represent the revenue function for this process in the following way. Revenue, as always, is price times quantity. And because of the strict sequence and the interdependency between the stages, the quantity is going to equal the minimum of the capacity of each stage. So there's going to be a certain flow through in this system and the total flow through is the minimum, it's the maximum flow through of the stage with the minimum capacity. The cues represent the stage capacities and the capacity. As I said, the minimum is combining. That's the bottleneck. The minimum capacity is the bottleneck. And in operations management, people spend lots and lots of time and resources and their endless models of how to find bottleneck and you've got to design the organization. So this is my contention, taking account of the task structure and in particular the existence of the bottleneck somewhere in the sequence of steps. And that has some consequences, I maintain, for organization design. So let's think about that min function for a moment. You do not want consummate performance, efficient performance, the most output for the least input from every stage because extra production anywhere but in the bottleneck translates into working process inventory. It's not going to be able to pass through the system and working process inventory. My training was in finances of that thing that's capital, Toyota calls it waste muda, it's expensive. So the operational task is to get production out reliably and in a balanced way. And the adaptive task is to find the currently constraining bottleneck and increase its capacity. And then you go on to the next currently constraining bottleneck and increase its capacity. And over a long period of time you might get a pretty efficient system. So consider bureaucracy as an organizational form here. Well, it's reliable, meritradic, rule governed, low powered incentives so it has no extra reward for producing more information flows, can manage coordination on a large scale hierarchy provides rapid and coordinated response and you want to drive individual variation out of the system. And I've had my five minute mark, so I'm going to speed up and get to the next thing. In contrast, a nexus of contracts really is a terrible way to design the organization. Nexus of contracts, everything's controlled by a separate firm. Each stage has high powered incentives that makes every stage unreliable and a potential bottleneck if they're all trying to make as much as possible and diversify their customer base and switch to the highest bidder. And each stage also has incentives not to disclose its true capacity or cost structure. And that's not good for the adaptive task of finding the true bottleneck. So you can derive a large transaction free zone governed by hierarchy from the property of strictly sequential tasks and a constraining min function. It's not the only solution. I'm not arguing for technological determinism, but it's better than what was the pre existing form, which was a bunch of separate firms doing all the different pieces of this sequential process. And that is exactly more or less what Chandler argued in the visible hands that these large hierarchical bureaucratic organizations evolved as an emergent and design form to address the technical issues incumbent in sequential high flow through production systems. So let's fast forward because I think I'm down to two minutes.
Speaker A I'm sorry, three minutes.
Speaker B Three minutes. Okay. So we have a new set of information goods with the following properties. All parts need to interoperate on the basis of shared code. Very high rates of potential improvement in components, but the improvement requires trial and error, experimentation and learning. The change rates, this is important. What we saw before was completely synchronized. The change rates in these large technical systems are asynchronous. The different pieces want to be changed at different rates. Hardware is high at high change. Software is slow. Hardware is very amenable to modularization. Software is amenable to new stuff being built on top of old stuff. And really large systems can be built using layered stacks like this one. Different stuff goes on at each level of the stack. And so the new challenge is not to balance and synchronize flows, but it's to provide for efficient experimentation and recombination of modules. So there are lots of small pieces loosely joined and we individually pick and assemble the things we need. So this is just a schematic of my life in computers, hardware, communication, operating system, browser, search engine, native apps, cloud apps. I could have expanded any of these columns, but I have choices. And I'll combine my tablet, which is Macintosh, with an operating system, iOS with the Internet, with Wi Fi, which I can't get to work here. But you know, I don't use a browser usually with my tablet. I do use Google. And the color codes here are Google is everything pink, and let's see, open source is everything blue and Microsoft is everything green and Apple is everything yellow. But the point is, I combine yellow, blue, green, pink the way I want to. And I expect these things to be interoperable and I expect to be able to recombine them at will. This value function for one of those blocks can be written and this is what Kim and I derived in design rules as this function where I'm going to define the pieces and then I'll be out of time. The sigma measures uncertainty and as opposed to the sequential technology, uncertainty enters in a positive way. It's now a good thing, more is better. M measures the size of the system, j Star measures the number of modules, which is a choice. And K Star indicates the number of experiments per module, which is also a choice and Q of K indicates the value of the best experiment. And just trust me, this is a value function and the value increases in sigma, in J and in K. So this is a new organizational challenge. And if you like the biological metaphors of seeking levels of performance on a fitness landscape, the fitness function by which an organization is evaluated. If you go from sequential classic mass production to recombinant modular technical systems, you have changed the fitness function from the min function that we talked about above to this complementary sigma JK function, which gives you the value of running more experiments on more modules. So there's no Min functions. And the bottleneck common to every block. So every block in that ecosystem has its own bottleneck. The bottleneck is the ability to formulate, run and evaluate experiments and that needs new capability, modularization experimentation and testing and integration. And as Hila showed us, none of those capabilities are endemic in bureaucracies that evolved and were designed and reacted to a fitness function that was a revenue function with a minimum in it. So there would be no reason to expect the organization selected for in the old technology to necessarily be even competent in the new technology. The pitch I want to make is a deeper understanding of the exigencies of technology and then a matching of the governance of the transaction zone to the needs of the technology can be a way to take organizational design into these business ecosystems. And I'll end there. Thank you. A modular design for external experiments is a platform business ecosystem. So that's what a platform is. And anyway, that's deriving platforms.
Speaker C Carlos, first, I find this fascinating framework. Have you thought about parallel processing? So where you talk about the sequential aspect and the minimum, the addition of parallel processing to reduce that bottleneck.
Speaker B Oh, yeah. And that is a classic solution if you can find the bottleneck. One of the critical things about these complex production systems, however, as you read Operations Management and Goldblacks who write so nicely about the problems of running plants, people don't know where the bottleneck is. It's obscure. First you have to find it. Once you find it, then parallelization is one of the ways of expanding capacity. But it's all a question. Both the modular recombinant systems and the sequential production systems are very complex and those tax structures are lots of transfers going on, not always mapped, not always obvious. And that's why the organization designs. If what you have is the minimum of a lot of things, you really would like to control all of those things. Because once you find the minimum, you don't want to be negotiating with a hold up agent about whether you can fix it. But in a modular system you are going to be doing your own thing, protected by protocols. Very different proposition.
Speaker D I was kind of curious with the system, it seems like it's a great resource system that's set up. But what is it that drives or maybe serves as an attractor in that system for it to become productive?
Speaker B I'm sorry, could you say?
Speaker D Well, I was seeing like when you have all the resources set up into modules, there's potential, but what is it that with dry production, which tended to go on linear paths, okay. In complex systems, it would even be in a tractor that would pull together some type of what a phone system would be. When you're using your example of your.
Speaker B Is actually, Chandler wrote his book calling it the visible hand, but it was the visible hand proposes and the invisible hand of the market disposes because the attractor is fantastic amounts of cash flow to these more efficient organizations. And Chandler's pretty clear about that. The attractor was they were more efficient, they offered a better value proposition to the marketplace and they became incredible dynamos of cash driving out the alternate forms that were not as efficient. So again, in the modular systems, the whole of design rules, which is built on that function I showed you, shows that if you can get more modules and more experiments per module, there is an incredible value proposition there that will drive out less modular, less experimentally friendly alternatives.
Speaker E Carlos, could you put down uncertainty is a good thing?
Speaker B Oh, I'm sorry.
Speaker E You started your, I guess ended with uncertainty being a good thing.
Speaker B Uncertainty is a good thing, yeah, not in a linear, not in a sequential.
Speaker E Right, right, I got that. The other one that's a little less intuitive, but let me just add to that. Maybe you can explain that. But the second one is you had in certainty experiments and then integration and you kind of left integration hanging there, perhaps for time, say a little bit more about that.
Speaker B Yes. In the fuller version of my notes that got transcribed to PowerPoint and vastly condensed in the process, I took each of the things, separate each in process and thought about what the best way to organize them would be. But let me start out with the question of uncertainty being a good thing. That is a fundamental result of option theory. You can think of it as positive risk. And what it reflects is the fact that if you truly create an option which is the right but not the obligation to take some action in the future, then your best investment is in the most variable technology because you have the ability to fall back on your last design. So you run an experiment on the basis of something you already had. If the experiment turns out well, you take the new. Otherwise you've got the old to fall back on. And in these modular systems, the ability to fall back is really, really important and it completely changes the game because in the old days when everything was interconnected, it was all or nothing. And so you didn't want to take a lot of risk. But in the new game it's not all or nothing, it's module by module.
Speaker C So this is where on that point, is it the firm level or at the market level? Because can firms actually optimize and succeed or is the market going to do that in terms of the choices?
Speaker B Well, the invisible hand will dispose, the firm will propose. And if you think about this being the task at hand and what a firm needs to do, it needs to pila talked about defining problems. That's separating a given problem from all the other problems ongoing. The better you can do that, the more modules you're going to have. So that's positive for value. Are big integrated firms good at separating problems? No, they're terrible at separating problems. It doesn't come naturally. We have data that shows open source software is much more modular than closed source software. So modularization is something you might have to learn to do experimentation. Experimentation by definition involves failure. There's only going to be one best and there are going to be a lot of trials. So that's the nature of these concepts, I think. Large integrated firms, even medium sized, even a drop, they're terrible at failures. So if you can put that failure, if you can put all of those experiments outside the boundaries of your firm, then you won't have to deal with compensating the teams that didn't make it to the top. You can just sit there post your contest challenge and pick the team that won. And everybody assumes because it's an invisible hand regime that up to now, that if you lose, you'll lose. Losers don't fry on testing. That's something where you could actually invest a lot of resources in establishing what you think the gatekeeper should look like, what gets integrated into the system and the nature of platform businesses. They let the consumer decide what to put in the final system. So they may do some quality assurance. Apple does some quality assurance on the entries in its store, but they're basically letting the end user be the system integrator. But in a contest, the modular design plus external experiment plus control of IP equals a contest. You've internalized, you've taken back the screening function into the focal firm and that again is something the question came up for. HeLa, well, how do you screen? The answer is you have to build capacity to screen. But it's a place in this new world where you can imagine a large firm with some of the properties of large firms becoming quite good. All of the lead firms out there that acquire entrepreneurial businesses and fold them in are doing just that. They are letting the market run and then they pick the best and acquire them.
Speaker A Thank you.
Speaker B You it.