Descaling Innovation: Why Scaling Innovation Starts Small By Descaling Work

Pouring millions into Agile transformations, SAFe certifications and Spotify models based on shallow stories is a sad state to define as success—and certainly a much bigger risk to bet the future of your business on. Yet this is the situation the majority of organizations find themselves in—especially those seeking to scale agility.

I must get an email a week from people inside companies stuck with McKinsey & Company, Scaled Agile Framework and other big consultancies asking if their recommended strategies ‘make sense to me?’ I feel sorry for these folks. They want to work in different ways, with truly innovative partners but their leadership won’t let them, saying it’s too risky or the person too much of an unknown (to them).

There was such a huge response to my post from people dissatisfied with what they are been told, sold and under delivered that I decided to write up my own case study—based on my own experiences working with real global organizations and bold leaders—on why scaling innovation starts by descaling work.

This article is my top insights on how and why starting small is the best way to realize BIG initiatives and make a BIG impact. The article highlights;

Article highlights:

• Why the traditional strategies to scale innovation fail to deliver, cost companies millions, and cause them to fall further behind market leaders

• How a stronger strategy is to start smaller, deliver sooner and safer before scaling up investments as you see real signals of success

• The 7 mistakes companies make on large scale innovation efforts, plus how to avoid them and systemize innovation throughout your entire organization

• Deep dives into four case studies from the finance, airline, government, and SasS industries

• How my 1% system saved money, scaled innovation and delivered business results 400% above expectations in highly regulated, complex operating environments

Exponential technologies such as cloud computing, machine learning, AI, and data analytics are all at their fingertips—yet they routinely find themselves struggling to scale innovation.

Mired in backlogs of unfinished projects, ineffective processes, and disappointing results … it’s a situation of frustration for all involved.

Blame often lands on poor decision-making by people, but the real issue stems from how organizations design their systems of work and the nature of project-based work.

I’m going to show you why project-based work—a common approach to large initiatives—is so prone to failure and how to get your organization unstuck by adopting a product-centered, outcome-based, cross-functional approach to innovation.

The Golden Data Quagmire

A leading international bank invited me to help them get a major initiative back on track. The project was one of those dreams that so many companies have but rarely manage to realize: the single source of data.

A classic project in the technology world, right?

Everyone wants a perfectly unified, single source of data for their whole business, so anybody in the company, at any time, can easily dip into the pool and get what they need.

It’s a great idea that, when implemented, could make everyone’s job easier as well as provide valuable insights, analysis, and actionable steps to attract new business.

For example, with such a capability,
the salespeople for this bank could offer potential large clients high-precision predictive analytics to support their business growth with better services:

“We noticed that your rate and frequency of foreign exchange transfers from operating companies in Europe to the US has increased by 20% in the last 3 months, and using SWIFT as a provider is actually costing you 5% more than if you used two other services we now integrate with. We also suggest holding 10% of your USD cash due to a 73% likelihood of a 10% increase in currency valuation compared with EUR in the next two months. This could save you an additional $19,000 in fees plus upside from the currency shift.”

That’s a powerful service to be able to offer—and everyone wants that capability. Yet the majority of industries are failing at making this data vision a reality. Many such initiatives have been running for years without achieving any of the results they’re aiming for. On the surface, everyone is busily working away at it, but amazingly, very little functionality is actually being produced.

The bank team was struggling. When I met them they were two-and-a-half years into their “Golden Data” initiative, and they had released nothing. Not a single use case had actually been shipped—nothing in a single customer’s hands.

Yet, they had some of the most sophisticated cloud computing capability I’ve ever seen. The cloud team was building amazing, automated, scalable instances on Amazon and Google Cloud because speed, scale, and performance were what they valued.

They proudly pointed out how they could manage more data than many Google services on a daily basis.

Meanwhile, the sales team had their backlog, and they were working on the components they thought most important: reports to wow customers, screens to share with them and interesting edge cases that would differentiate their product and make it the only one with such capabilities in the market. The traders were working on their risk components, as were the tax team, operations, data, and so on.

People were solving incredibly tough problems—their critical thinking and individual components were fantastic. However, none of it was connected. There was no coherence across the entire platform.

Each group was well on their way to achieving their own projects’ measures of success, yet no customers were being delivered the promised powerful insights. There was simply no path to bring the product vision alive with an end-to-end use case or valuable solution.

And so, like many organizations, they were stuck in a myriad of dysfunctional patterns, conflicting priorities, and business politics that were preventing effective collaboration and real progress.

Why Big Projects Get Stuck

Mistake #1: Starting Big

My mantra is “Think BIG, start small, and learn fast,” a formula which encapsulates what I’ve found to be the most effective strategy for meaningful, productive innovation.

Unfortunately, what this company had done, which is the classic trap, was to think big, but then start big and implement all aspects of the entire BIG idea simultaneously.

They looked at this massive project with a massive mission and tried to tackle it all at once. When we start big, projects immediately become too big to fail, and at the same time they become unmanageable.

Mistake #2: Siloed Teams

The project was split across a variety of teams, all of which operated with siloed thinking in terms of processes and objectives. They had limited horizontal communication or coordination within other teams. Ironically, this approach effectively removes the “Think BIG” part of the formula by narrowing each team’s focus to their own local objectives and needs.

Mistake #3: No Shared Understanding of Success

Without the big vision and clear definition of success to draw people together, they think smaller, focus on their own priorities, and end up colliding. Communication suffers, as does progress. As often happens when people are struggling to collaborate, the bank teams had started finger-pointing and exhibiting other negative behaviors toward each other in frustration.

It’s a predictable byproduct of conflicting goals and lack of clarity about what constitute shared outcomes for success. You end up with locally optimized work and no understanding between different groups—an alignment gap only amplified at each organizational level.

Mistake #4: Focused on Outputs Rather Than Outcomes

Project-based work optimizes for execution risk over market risk, meaning teams measure success in terms of delivering the project outputs within their defined constraints (e.g. being on time, on budget, and in scope). Unfortunately, output metrics have precisely zero impact on the success of a new innovation.

Focusing on outputs is a mechanistic approach, which means each participant is essentially optimizing for task completion. They’re cut off from a sense of purpose behind what they’re doing. Intelligently defined outcomes, on the other hand, not only provide a sense of “why”, but also give teams a way to assess and communicate whether their outputs are moving the needle in the desired direction and reducing the market risk of building the wrong solution.

Another byproduct of focusing on outputs is that participants track easy-to-measure metrics like “tasks completed”, “features launched”, or “releases on time” to demonstrate the quantity and quality of their activity.

This is a poor replacement for tracking harder-to-measure metrics that actually signify progress towards the outcomes we’re aiming for, such as:

• increases in the percentage of market captured
• usage rate of key functions of your system, or
• increases in customer spend for new versus existing customers

Mistake #5: Competing Priorities for Individuals and Teams

In the project-focused approach, which the bank was struggling with, companies want their “best people” involved on every big project. Senior leaders or key contributors might have as many as 10-20 initiatives they’re concurrently assigned to.

As a result, their focus disperses, and their productivity diminishes. Working on multiple initiatives and constantly context-switching leads to burnout, low-quality work, and a struggle to get anywhere on any particular initiative.

Mistake #6: Too Many Initiatives in Progress

Most organizations measure progress by how many initiatives they have in progress, creating a propensity to start more projects rather than finish current ones.

Unfortunately, the more work in progress, the more competing priorities and dependencies you create for completing work end-to-end, getting results, and using that information to inform your next priorities.

Taking this up to the organization level, you end up with countless variables, components, and dependent parts interweaving through the process, causing delays and effectively blocking progress.

Mistake #7: Personal Brands and Bonuses Tied to Initiatives

Stakeholders often become personally attached to grand projects. Rewards and recognition get linked to the delivery of initiatives rather than their impact on overall business results. This is further exacerbated by pay-for-performance systems where 50-80 percent of total compensation for senior executives is based on achieving their incentives.

As a result, even if an initiative is stalled or failing, they fight to make it work in order to save face and protect their reputation and compensation.

This can often mean people fear speaking up, tending to report only positive news and progress, rather than failures or challenges (as well as encouraging the same from subordinates).

Leaders act on invalid assumptions and, worse still, lead others to make decisions based on the poor quality of information provided, creating further risk and potential for failure.

THINK BIG Start small

I imagine you’ve experienced some or all of these issues in organizations you’ve worked in—most of us have.

It’s a shame so many companies continue to follow this outdated approach to innovation, because it leads to high levels of frustration and dissatisfaction, as well as putting the company itself at risk of falling behind in the market.

We all want to scale innovation and build amazing products that will have a seismic impact in the world and on our business. What needs to be unlearned is the project-based approach for achieving a grand vision.

The answer is NOT to think BIG, start Big, and have a Big-Bang launch.

It’s to think BIG, start small, and learn fast what will work, or not.

Descale your work and build out your solution based on feedback from real customers throughout the development process.

As I’ll show, you’ll achieve your big vision sooner, safer, and with higher confidence of its success in the market.

What Does Descaling Work Mean To You?

For someone who’s caught in the project-based, start-scaled mindset, it’s counterintuitive to think that the way you scale innovation is to descale work.

So when I say to people, “We need to descale your innovation strategy,” they look at me with a mix of shock, fear… and (often buried at first) relief.

In most organizations, for innovation initiatives to get focus and funding, they need a WOW story to woo executives into opening their budgets to back the idea. So when people develop ideas to get that attention, they tend to go for bigger, bolder stories.

That’s fine and important (Think BIG); however, they usually assume the delivery of the big idea has to be big and bold as well, starting and scaling the initiative across the whole company. They think every use case and edge case needs to be considered and solved from the very beginning (or worse, feel the need to start burning up the budget in fear of it being taken away)!

This pattern has given rise to massive, yet oversimplified, scaling frameworks and a whole industry around certification from experts to coach teams on “Enterprise Agile”, “Scaled Agile” or whatever sounds sellable as a silver-bullet solution.

The theory goes that you spend two days locked in a room going through the framework, take a tick box test, and magically you are transformed to scale innovation across your entire organization.

Copying and pasting a fixed set of practices onto a company—a complex adaptive system—and expecting extraordinary results is so overly simplistic as to be laughable.

It will create plenty of activity and output but yield few of the promises of progress beyond certification numbers, user story points, and percentages complete. Be sure to ask every certification agency to show the outcomes from their work and you’ll get a true signal of their stories of scaling success.

So Why Descale Work To Scale Innovation?

As mentioned, a real challenge for a lot of organizations is the tendency to build in large chunks or phases. They are big initiatives that often rely on many different components coming together for the overall program to get anywhere.

However, individual components usually don’t align on a true north, a shared set of outcomes that everyone is responsible and accountable to achieve.

When we descale work, we reduce the impact of these challenges by empowering a bold vision with a clear, small, first step. When we pair this pattern with outcome-based measures of success, the benefits become exponential.

Descaling work encourages the team to identify small, thinly sliced pieces of end-to-end functionality to ship to customers, enabling them to learn if their big, bold vision and first small step is putting them on the path to success.

Imagine that the bank had defined their “Think Big” as a 50% increase in new business from existing customers based on products derived from our Golden Data platform. Their “start small” could be a 1% increase in the next three months … or even smaller, like a 0.01% increase in the next month. If you were on the team, what type of solutions would you start to consider? You got it. Simpler, smaller, and sooner.

Working in small slices like this, you quickly find out what works at the most basic, sometimes shockingly simplistic levels of functionality. And you get a foundation of real data and useful insights to build upon, iterate, course-correct and improve your products in a safe-to-fail manner.

Descaled Work Solves Real Problems

A classic anti-pattern example is the development of the Healthcare.gov website for the launch of Obamacare. The US government had a big idea to create a single source for people to get health care. They set a launch date, put out 60 contracts to 33 different vendors, and set off to build it.

All these vendors knew they weren’t going to hit the deadline, but they were just waiting for one person to come out and say, “We’re going to be late,” so everybody could blame that vendor. When they launched it, the whole site went down. It was a disaster. So they fired everyone and got a new group of vendors … and the exact same thing happened again.

The only way they got out of this mess was to descale the team and the work. Todd Park, White House CTO, reorganized the technology leadership team, demoted some of the underperforming employees and 3rd party contractors, and recruited a small group for a government sabbatical to save the site.

This tiny team was formed with the narrow mandate of getting the system working properly; the team met daily, triaged existential risks, and prioritized the most important defects on the critical path.

Over the next six weeks, the team fixed around 400 system defects and increased system concurrency to 25,000 users. They also improved website page responsiveness to one second by continuously shipping small slices of functionality to support scenarios of user segments and scaling out over time.

Enrollment jumped from 26,000 in October to 975,000 in December. The tech surge worked so well that many of the fellows stayed on to establish the successful US Digital Service organization in 2014 to transform important, public-facing digital services provided by the US government.

Recognizing the Pattern

This is not a new pattern. It’s how the majority of innovation actually happens. Big companies of today didn’t start big. They started small, then they grew into their business models over time:

• Amazon started as an online bookseller in the early days of internet adoption, then expanded to multimedia, to toys, to everything … plus building out Amazon Web Services and other initiatives over time.
• Starbucks started out selling high-end coffee beans, teas, and equipment. In fact they started incredibly small, with just one type of coffee.
• Airbnb started as a couple of friends renting out their air mattress in a room and started to build out from there, growing into the largest hotel company in the world.

How to Descale Work

Here are my top strategies for descaling work to generate real results safely and quickly. This is the counterintuitive, competitive advantage for achieving a bold vision.

Think Big, Start Small, Learn Fast

Yes we need to think big and be aspirational about what we’re trying to achieve. But we don’t build big. To get real results and solve real problems, we actually start small… incredibly small.

When people hear “small”, or “minimum viable product”, they often think “fragile and crappy”—a stunted release that will never be revisited. But thinking about a 1% or even 0.01% improvement relative to the big outcome you’re aiming for is a powerful way to deliver something of real value quickly.

Yes, it’s a simplified set of your desired functionality, delivered to a subset of your desired customer segment, but it solves a problem end-to-end. You can quickly learn and test assumptions before you go big. You get this information sooner, and you get it cheaper. This enables you to safely start learning how to make sure the full version itself not only doesn’t end up fragile and crappy (or useless), but becomes a meaningful success.

Favor Outcome-Based Measures Of Success

An outcome is a change in behavior that leads to a business impact. Shifting to an outcome-based approach to innovation is non-negotiable in creating a culture of experimentation and learning. It demands that you clarify the success you seek—in quantifiable terms—by crisply defining what you’re trying to achieve so people know why it matters.

Everyone wants “happier customers”, but that’s too abstract. Outcome-based businesses want “a 30% increase in customer retention in the next 12 months”. Clarity of destination allows people to explore different options to discover if the investments you make are moving you in the direction you desire.

An outcome-based approach allows you to be more accurate and adaptive. You own the results you gather—checking, rechecking, and thereby navigating the uncertain path towards the desired benefits and behaviors your product exists to create.

Empower Your Employees

Great people want meaningful problems to work on—they’re not excited by simply increasing shareholder value. I was pleased to have long-standing innovation experts Mary and Tom Poppondieck on my podcast, and appreciate how they framed empowerment

“This is not about great people. This is about making people great. So much organizational architecture prevents people from making a real difference, and if they could, great things would happen. It’s not that you have to have super people, but you have to have a super environment.”

Descale Work

Here’s what we want to avoid: starting big to accommodate all the complex scenarios and outlier use cases, finally shipping your product, and then realizing most of your assumptions were incorrect.

Instead, make solutions as small as possible so you can iterate and test quickly. If your big vision is to increase factor “x” by 250%, decide what a 1% improvement would entail, and start there.

If someone wanted to go from couch potato to running a marathon, they wouldn’t start out running 26.2 miles on day 1 of training—they’d start by walking around the block and scale out from there.

Ask yourself what is the smallest slice you could complete end-to-end that will help you answer the two critical questions:
Will customers use this?
Can we complete it?

Only after proving you have a “Yes” for both questions should you start to scale and increase the complexity.

Start With Things That Don’t Scale

Software is simply an automation of a manual process, and we should only automate when our manual systems become over-subscribed.

Kim Atherton is CEO of Just3Things, an organizational alignment and goal-setting platform. She developed the product as Chief People Officer at OVO Energy, when faced with the problem of productivity, clarity, and communication breakdowns as they rapidly scaled from a startup to the second largest green energy provider in the United Kingdom.

What was the first iteration of the product? Sticky notes on the CEO’s office door alerting people to the company’s top priorities. Incredibly primitive and simplistic, right? But it was effective, and it helped them start learning how to solve the problems, scale up their innovative new structure, and create an automated version of the system in their product.

Alberto Savoia had a successful career as Chief Technology Officer in companies like Sun Microsystems and was Google’s first Engineering Manager. He created “pretotyping” as a concept, and he relayed the story of how Jeff Hawkins developed the Palm Pilot. The first version was a block of wood with a notepad on it. How could that possibly be useful? Because it taught him the most important functionalities he would use in a digital version.

On the surface, these initial solutions look embarrassingly naive. But they provide an end-to-end solution, so you’re learning:

• What is the problem?
• How does our solution address the problem?
• Does anyone use the solution? How do people react to it?
• What’s experience like?
• How might we evolve it?
• Should and could we automate and scale it?

This is why the Just3Things and Palm Pilot examples provide such important lessons. It’s okay, and often even preferable to start with things that don’t scale — solve the problem manually, and stay close to the pain points while you’re learning.

Scale Solutions By Working in Small, Thinly Sliced, Reversible Steps

The reason to work in small slices is so you can complete work and gather results sooner. Results are what we learn from to inform decisions, course-correct, and take better action in the new future.

This approach to work makes it safe to fail by setting up a series of small wins and recoverable losses. You can either scale up your solutions to reach your ultimate outcome, or you save face, time, and money by moving on when something proves unsuccessful.

It’s a counterintuitive approach, because the nature of innovation is embracing uncertainty—which means you don’t actually know what will work, and what won’t.

But paradoxically, the only way to get the information you need is through action … taking your best guess, starting small, and learning your way through the uncertainty.

Invest In The Technology Platforms To Enable Continuous Delivery

The mantra of continuous delivery is: “If it hurts, do it more often, and bring the pain forward.”

If your product integration, testing, and deployment are painful, you should aim to perform them every time anybody makes a change. This reveals any waste and inefficiency in the delivery process so you can address it through continuous improvement.

However, to make it economic to work in small batches, you need to invest in extensive test and deployment automation and a technical architecture that supports it. This makes it economically viable to work in small batches. The cheaper, quicker, and safer it is to release your product, the more your team will do it … iterating, learning, and adapting faster than ever.

To help you understand the power of descaling work to scale innovation and bring a big vision to life, let’s take a look at a couple more examples.

Descaling Airlines | Case Study: British Airways - Group Booking

I had the pleasure of working with British Airways to help a group of senior leaders rethink their innovation portfolio, which led to a number of interesting breakthroughs. One initiative that came out of our sessions was a group booking feature to provide discounts for people traveling together. A fairly simple idea: if you could demonstrate you were traveling in a group, you’d get a rebate between five and 10 percent.

In highly regulated, often bureaucratic industries such as the airline industry, delivering even small software change can typically take anywhere between 12 to 18 months.

So to deliver an idea as straightforward as group booking can take many months, hundreds of millions of dollars, and hundreds of people.

In these situations, descaling work to scale innovation becomes even more important. So with an innovation like group booking in mind, how would you start?

In this case, we applied the “1% better” approach I mentioned earlier, and we even went through several rounds of it—the 1% of the 1% of the 1%. We ended up cutting the scope down to one single flight on one single route. That’s about 400 customers to deal with.

A 400% Reduction In Lead Time From Idea To Scalable Solution

We used a highly sophisticated communication tool called email, as well as manual handling of phone calls and rebate processing. We brought in one person at British Airways who knows all the systems, and she took care of everything.

Once people had booked, we simply reached out to ask if anyone was traveling in a group, and if they proved it, we’d give them a discount. This allowed us to learn what percentage of people on the plane would want to take up the service. We could start to gauge demand for the idea (will people use it?).

Even though we were testing post-booking, it was useful enough to decide whether the service was worth building. Crucially, we also learned what it would take to build it, and what software systems and processes would have to be automated to avoid bottlenecks.

The next step was to add more flights on the same route. Then we added more routes. And we developed the ability to compare data, building a learning system at the same time as delivering the system. We were thereby able to get enough data for the revenue management people to determine the financial viability of offering the service at scale.

The initiative turned out to be both popular and financially beneficial, and they were easily able to build on the foundation we created to launch it at scale. The whole process took less than 14 weeks—a 400% reduction in lead time from idea to fully functioning solution! We launched early, continuously learned, and safely course-corrected along the way.

If we had just said to the team, “We want to have group booking,” they would have treated it as a project: jumping to solutions and managing the execution risk, making sure everything in the idea was built on time, on budget, and in scope. By descaling the work, they got a naive but end-to-end, complete solution much faster and cheaper, with less risk and greater confidence at every step that they were on a positive path to meaningful impact.

Scaling Financial Services | Case Study: Fortune 50 Bank - The Golden Data Project

So at this point you must be wondering how things turned out with the bank’s “Golden Data” project.

First, we had to step back and align on a bigger aspiration to bring people together … and break free of their localized, individual goals. The first question I asked the team was whether they could describe a bold vision for the product: how it would affect customer behavior, and the outcomes the initiative would achieve for the business. Of course, no one could agree on them. They’d actually never had that conversation—they’d all just started to work on their own piece of the puzzle.

So I got them thinking about outcomes to describe what success might mean. They initially started dreaming up complex schemes to trade an array of different stocks and currencies in different markets at different times with different global entities. This was great in that it brought them together out of their siloes to connect with a unifying vision.

On the other hand, they were adding a huge amount of complexity into the system. So after a while, I stopped them to ask, “What would be 1% of the product vision you’re aiming for? And 1% of that, and 1% of that?” And this allowed them to narrow down from the “think BIG” vision to a scenario where they could start small.

It came down to focusing on just one type of trade, in one market (between London and New York), at one time of day. Their shared first step became to use their data to understand the exact price of that trade at that time.

By descaling their work, they could actually get something done end-to-end. Everybody knew what they had to do to get this one piece accomplished. It took them just 14 days to build, test, and launch this small service to a tiny segment of real customers—conducting and completing one trade on their systems.

It seemed like a miracle. They’d never done anything like that end-to-end before, so it was cause for celebration—completing this tiny slice and seeing the results. They could finally feel a little success … and get excited to start layering on the next slice and scenario.

They could just keep building these small slices and progressively enhance the platform over time, while people used it. They were finally completing and shipping work and getting results that allowed them to iterate toward the BIG product vision.

Before this, they were always trying to solve for the most complex, difficult edge-case scenarios, which only served to hold them back.

Tasting a complete win, even though it was so much smaller than the big vision, created a huge boost in morale and generated real progress that had been eluding them for two-and-a-half years, despite millions of dollars invested.

That Is 'Agility'

Starting small by completing a thin slice end-to-end yields a relatively quick and cheap answer to the question, “Can we build it?” Then you can start digging deeper on the question of “Should we build it?”

So next time you’re assigned a big project, stop. Consider how to create thin slices of functionality to start building toward the vision you have (or have been assigned).

When you work in small, shippable batches, if an error comes up, you and your team can relax, knowing it’s going to be corrected quickly. You can have the confidence to change direction if you see that people don’t actually want what you’ve built.

And instead of derailing progress, as happens in larger programmes, getting new requirements actually becomes a positive experience, guiding you toward better results and greater impact faster and cheaper. Having real data and the ability to utilize it in small chunks of work gives you options to explore.

The safety factor is huge. Committing to small amounts of change ultimately makes change itself easier, so people get comfortable with it. They welcome new information rather than seeing it as a problem. So you end up with far less apprehension and anger driving communication, decision-making, and workflows.

So, to recap the strategies for shifting from a project-based, output focus to a product-based, outcome focus:

• THINK BIG, start small, Learn Fast
• Favor outcome-based measures of success
• Empower Your Employees
• Descale the work
• Start with unscalable solutions
• Scale solutions by working in small, thinly sliced, reversible steps
• Invest in technology to increase delivery frequency

So where in your company could you shift to a product-centered, outcome-based approach to innovation to start making meaningful progress?