There is a peculiar habit in innovation ecosystem work: we use governance, orchestration, and management as if they were the same word.
Watch any three people discuss an ecosystem intervention long enough and you will hear all three often used as substitutes. A regional innovation director calls for better governance. A corporate innovation lead wants better management. A consultant helpfully suggests that what is actually needed is better orchestration. Everyone nods as if they are talking about the same thing. Most of the time, they are not — but the meanings sit so close together, and the situations they get used in overlap so much, that the difference feels academic. In casual conversation, it usually is. I have watched this pattern for a really long time, and — I will admit — never quite bothered to sit down and pull the three concepts apart. The boundaries were fuzzy, but the practitioners were seniors and live-and-let-live seemed like a reasonable position. If a regional director wanted to call orchestration “governance” and a consultant preferred the reverse, no project was going to fail because of it. Which is a defensible position, until it isn’t. And in innovation ecosystem management it has now stopped being defensible.
The discipline is being built right now. Standardization committees are settling terminology. Policy programs are being designed with language that will govern how they get evaluated. National innovation strategies are naming their coordination instruments. If governance, orchestration, and management collapse into a single fuzzy word cluster during this formative period, the vocabulary hardens with the fuzz still in it, and every later attempt at clarity turns into a polemic rather than a definition. Quality management, project management, and agile all fell into exactly this trap during their own formative decades. Each of them then spent the next generation excavating precision out of a vocabulary that had set too soft. Innovation ecosystem management does not need to repeat the exercise. And with a little discipline now, it does not have to.
So here is the distinction, laid out at the level of definition rather than of feel.
Governance refers to the rules. It answers who has the authority to decide, and by what process. It sets the boundaries of decision-making, the accountability structures, the mechanisms of dispute resolution. When Michael Jacobides, Carmelo Cennamo, and Annabelle Gawer wrote their 2018 Strategic Management Journal piece defining ecosystems as sets of actors with non-generic complementarities not fully hierarchically controlled, they were writing about governance — about how coordination can happen without full hierarchy. Keith Provan and Patrick Kenis, in their 2007 network governance paper, mapped three canonical modes: shared governance, lead-organization governance, and network-administrative organization. Governance is prior to action; it defines the space within which action happens.
Orchestration is the act of alignment. It answers how the different actors get synchronized to create value together. Marco Iansiti and Roy Levien introduced the term to strategy in their 2004 Keystone Advantage, and Pia Hurmelinna-Laukkanen and her work with Paavo Ritala — have systematized what orchestrators actually do: mobilizing resources, shaping expectations, managing knowledge flows, resolving conflicts before they surface. Orchestration operates through influence more than through rules. An orchestrator does not sit above the ecosystem; the keystone works from within it.
Management is the execution. It answers how the work actually gets done, day by day. Planning, resourcing, scheduling, monitoring, correcting. It is what ISO 56002 defines when it specifies an innovation management system: the set of interrelated elements that a single organization uses to establish and pursue its innovation ambitions. Management is what most of us learned in business school. It is the least glamorous of the three, and probably the one we have the deepest vocabulary for.
The reason the three feel similar in ordinary conversation is that all of them involve coordination, all of them involve some form of authority, and all of them can be exercised by the same person on a Tuesday morning. But the moment we try to design an actual innovation ecosystem — when a regional development agency, a cluster office, and a group of firms have to work out who does what — the three tend to collapse into a soup. Programs get funded to solve orchestration problems using management tools. Governance is redesigned when what actually needed changing was the orchestrator’s authority. Consultants deliver management frameworks in response to governance requests. Everyone works hard and nothing quite lines up. The result is a condition I have started calling coordination limbo — everyone knows something needs coordinating, but nobody quite knows who has the authority to do so, who has the responsibility to act, or what the rules are for either.
Even the standardization work has been quietly struggling with this. ISO 56002 is a management system standard, so its language is clear on execution. ISO/TS 44007, published in 2025, uses orchestrator-and-members language explicitly, giving orchestration its own vocabulary. ISO 56012, currently in development for innovation ecosystem management, has to hold all three — governance in its structural clauses, orchestration in its process clauses, management as operating background. Whether it succeeds in keeping them distinct is work in progress. But the challenge is real, and the work is genuinely difficult. The framework on which I am currently working separates the three into distinct architectural layers itself. Governance sits with the layered model — public, business, organizational — where the question of who decides what across the layers, and by what rules, actually has to be answered. Orchestration sits with the actor model, especially the keystone role, where coordination across the actors within the layers happens through influence rather than rules. Management sits with the process model, where what gets executed inside the substeps of the innovation journey is planned, resourced, and monitored. Three questions, three separate models, three distinct sets of design decisions. Which is, on reflection, how it should have been all along.
So there it is. Three coordination acts, three institutional homes, three sets of design decisions. Sorting them out now — while the discipline is still setting — will save us from spending the next decade excavating the confusion out of the vocabulary, as other management fields have had to do. If you have ever sat in a room where three people were solving what looked like the same problem with three different vocabularies, and nobody realized they were solving three different problems, you know exactly what this is about.
This is one of a series drawing on ongoing work at Novelty Quest on innovation ecosystem architecture, in preparation for a book. Earlier posts on the composition of innovation ecosystems, on where projects actually stall, on the three death valleys, and on how clusters and hubs relate to ecosystems as coordination layers are on this blog.
Be the first to comment