#229: Scaling Corporate Innovation
How to define scale up structures for enterprise and organisational innovation.
In the past few days I’ve had a number of conversations about scaling innovation. This edition is an attempt to explore a key gap in scaling innovation within large organisations.
TL:DR - in a new venture, there’s now a clear acceptance of a scale up stage as distinct from a start up stage. Businesses and large organisations don’t have a ‘scale up’ stage, structure, or process, even though they often do well working with external ventures. New ideas within the business, though, are often expected to go from a successful POC to a business as usual (BAU) stage. They fail because in essence, a successful POC is like a child who has completed primary school, and the BAU stage is like entering the job market. The scale up phase is the structure and process that takes you through secondary school and university. It fills the gap between POC and BAU. In this post I’ll walk through what this is, in more detail.
What’s a Scale Up?
There’s a lot of literature about scale ups, mostly in the context of new ventures. In this universe, a start up enters a scale up stage when its core proposition is proven, it has shown itself to be capable of getting and serving customers, and solving a problem for these customers in an economically viable way - i.e. with a gross profit greater than zero. Typically at this stage the key demand is to scale the business so that overheads can be brought down, and net operating margins can be realised. Usually funds are raised specifically for scaling, and a significant part of this goes into marketing and customer acquisition, as well as building out the business for scale. Often, it involves a new set of skills, specialists rather than generalists, and frequently, new leadership.
Scale itself is a relative term. Given the thousands of hopeful start ups, the milestone of actually achieving commercial viability of any kind is a scaling milestone. The point at which if the business didn’t grow any further at all, it could simply go on being a cash generating business, however minimal, is by itself an incredibly challenging scale milestone that the majority of start ups miss. Boxlab Services is a BASF spinoff that now functions as a standalone start up. A very small number of businesses go on to success beyond viability - which means it actually grows to a significant size in a market, segment, or region. Kraken from Octopus Energy is one such example. An even smaller fraction reach the next order of magnitude where they become enterprises by themselves (think Anthropic, with a revenue of $1bn and a 3m paid user base). And even beyond that, you can aspire for population scale - let’s say when you approach or cross the billion users mark (Google Maps, AWS). Population scale also applies to government led initiatives and the recent success of the India Stack has drawn a lot of attention from across the world.
In the Enterprise Innovation context, scale ups are a bit different. This is down to 3 basic reasons. First, the notion of a ‘start up’ is different in an enterprise. Not every innovation in a large company will lead to a new product or business. Some might improve existing businesses, or existing processes. Some might deliver higher customer satisfaction, or elevate through put, or reduce inventory costs. Second - in my experience, a ‘garage’ or an innovation team will stop at producing a proof of concept (POC). This is also much more nascent than a typical start up’s level of validation. So a lot more needs to be done. And third, in an enterprise every new innovation also needs to undo something else that’s currently being done. A typical start up doesn’t care about this because it’s somebody else’s business that it is disrupting. For an enterprise this is a big part of the challenge - and it’s fundamentally a change management problem. How to get people and teams to align, what to do with people whose jobs are impacted, managing the ripple effect on external partners, how to manage any other unintended consequences - all of these matter to a large organisation. This is especially true when considering process innovation rather than new products.
As an innovation team, we’ve worked on a number of good ideas, some of which have actually gone on to become excellent solutions that work at scale. For example when the Improvement Services, which works to deliver new ideas for all of Scotland’s 31 local councils had a problem with data sharing around dog control notices, we were able to deliver a POC in 8 weeks with 5 councils involved. And because we addressed most of the problems in that POC and designed the model for scale, the solution was scaled within 5 months to all 31 councils. Paving the way for other data sharing use cases across the councils at even bigger scale. For every such success, though, we’ve usually worked more than one that didn’t scale. The causes were many, and varied as is only to be expected, in accordance with the Anna Karenina principle. Not all the stakeholders were aligned. The specific idea did not align with any major organisational initiative under way. The technology wasn’t ready for scale. These are just some examples, but invariably you get a combination of 3 things - a lack of funding clarity, a culture and change gap, or a technology shortcoming. Often it’s all three and often it’s multiple and nested layers of problems across these three areas.
All of which means that the biggest challenge to scaling innovation in large organisations is that a successful Proof of Concept is far from ready to be given to an existing operations team to run and grow as a ‘business as usual’ initiative. We’ve all heard the mantra of fast fail. And this is one more myth that hampers scale. Failure doesn’t happen once, it happens over and over again, at every stage. And it goes arm in arm with success. Some things work, and some other things fail. Progress is all about recognising the learnings from the bits that fail, and moving on to the next failure, and repeating this process till all the little failures have been ironed out. When SpaceX’s rocket exploded after launch, Musk courted public ridicule with his description of it as ‘rapid unplanned disassembly’. But he separated the success of getting the rocket into the air, from the failure of its subsequent destruction, and SpaceX went back to the drawing board to improve on the latter.
I’ve now come to believe therefore that large organisations need a ‘scale up’ capability just like many now have a start up capability. While the latter is typically a garage or lab style team that identifies new ideas and builds proofs of concept, the former is a set of people who are specialised in taking these POCs to scale through a series of success/failure cycles, solving for technology, commercial models, and business change. And mirroring the need for start ups to often bring in new skills and leadership as they transition to scale ups, this scale up team also needs a very different mindset.
Remember, growth and scale aren’t the same things. Simply put, growth typically suggests that the underlying model can handle more users/ volume. Scale usually implies also fixing the model for current and future growth. Growth often puts the spotlight squarely on sales and customer acquisition but scale has to consider the entire business system and focus on the specific choke points in your business model which may become the bottlenecks to growth. As this piece suggests, getting an idea to scale could require ecosystems, new partnerships, engaging the CFO, and getting board support, whilst ensuring you are drawing on your competitive advantages.
Just as start ups need agile ways of working, so do scale ups. The key difference being scale ups have to create a clear pathway for the things they are testing for. For example, if a new idea to improve customer uptake from an e-commerce site requires additional support in a contact centre, by way of recruitment and training, this becomes a cycle of testing and learning. The feedback from the contact centre may in fact end up impacting the proposition, design, or implementation. And the reason why this shouldn’t be done by an existing operational team is that for a successful scale up, these cycles of test and correct have to happen far more quickly that is the norm in most scaled operations. You don’t have time for creating business cases, waiting for resources to become available, or to get alignment from multiple department for every cycle of change you want to execute. And it’s quite possible that you’ll go through dozens, or even hundreds of cycles before you’re really through with the scale up process.
Obviously your scale up team might need to be bigger than your start up team - simply because there are more things to think about. For a successful scale up everything from logistics, customer service, legal and regulatory issues, inter-departmental agreements, training, sales and marketing models, and integration with and modification of existing enterprise systems, all need to be worked out. So what you might end up with here, is a scrum of scrums. Adapting the relevant aspects of the SAFe model may not be a bad thing at this point.
One of the biggest skills required in a corporate scale up organisation is the ability to negotiate across divisions and departments, and create alignment. Whether it’s prioritising your needs for an already beleaguered CISO organisation, or getting the operations team to agree to a new operating model that’s required for your new idea, at every stage in a scale up you’re having to tweak existing organisational practices, which might require investment, training, role re-definitions, and more. This is why a scale up needs both insiders and outsiders (whereas you could potentially go completely with new hires for a start up phase). The insiders understand the current set up well enough to understand how it can be tweaked and what the challenges are, and how to navigate the political landscape, whereas outsiders (hopefully) know what good looks like from other organisations and their external perspectives.
Also because of this complexity and interplay between entities, you need to bring in a systems thinking mindset. Most POCs use design thinking approaches to solve a problem for a specific set of users, but without the systems thinking lens, you will run the risk of missing the interdependent complexities that will prevent the idea from going beyond that narrow lens. In addition, if your idea involves technology at the core, then the quality of engineering will come into focus. In the India Stack story, there is an extremely robust enterprise architecture principle embedded that allows the solution to scale to billions.
So the next time you wonder why your organisation doesn’t effectively scale all the POCs and MVPs you build, think about what your scale up organisation looks like, and whether you have one at all!
AI Reading This Week
AI for Government: The Tony Blair Institute has a big report out on how AI can be used to improve Government functioning. Some of the key areas of focus are the setting up of an AI council, making data interoperable, rethinking civil services with AI, creating a sovereign computing and AI capability, and winning the talent competition, just to name a few. (Tony Blair Institute)
Claude - prompt caching
An interesting feature on prompt caching as a means of controlling the cost of scaled AI solutions, and how best to exploit it. (TechTalks on Substack)
AI as a Risk: More companies see AI as a risk, than opportunities at this stage, apparently. Is this an implied admission that they expect disruptive start ups to do more with AI than their own businesses, perhaps? (FT)
AI Future: Erik Schmidt’s view on the speed of change and need for U Turns - you can change your view of the future of AI every 6 months. He did. (Exponential View - Azeem Azhar)
AI Energy Footprint: Carl Benedikt Frey and Azeem Azhar argue that the net benefits of AI on climate change will be positive despite the high direct cost of energy because of AI’s ability to influence many other industries in energy-positive ways. (Project-Syndicate)
AI vs Legacy: A part of the challenge of AI in organisations involves addressing the ‘process debt’. According to the authors, both from PWC, this involves addressing the “buildup of often antiquated, functionally isolated, and customer-disconnected ways of doing work” (HBR)
Other Reading
Robots: The future of Robotic Intelligence - how the different types of learning models will influence the evolution of robotic intelligence. (Medium)
Deep Tech: Atoms, not bits, is the mantra of this view of the future of tech, beyond AI. (eHandbook)
Technology Trends: McKinsey’s 2024 technology trends, where interestingly they distinguish between Generative AI and Applied AI. And also look at engineering, sustainability, and computing futures. (McKinsey)
Digital Money: How does it really work? Specialist writer Patrick McKenzie talks about digital money in Bloomberg, and also in his blog - bits about money. (Bloomberg, Substack)
Thanks for reading, have a great week!