Nail It Before You Scale It!

Scaling is a popular strategy these days: scaling innovation, scaling agile, scaling whole organizations. But scaling can easily undermine agile principles like focus and minimal viable product, and the abilities to deliver, learn quickly, and pivot decisively when required.

 Human nature means we tend to want to scale too fast. I think of Frasier’s appeal to hire a full orchestra and a choir to record his show’s new jingle, much to his brother’s chagrin: “Ah, but if less is more, just think of how much more ‘more’ would be!” Once we prove a concept or framework, we want to add people right away, assuming this could only multiply its success. Unfortunately, adding people doesn’t always mean adding results. You don’t get double the output by doubling the teams—you may, in fact, end up with a decline in productivity. This is because the larger a team grows, the harder it is to choose decisively and correctly. 

By keeping your organization small, you’re insisting that the right trade-offs and decisions are made. Smaller groups can move more nimbly than larger groups, and you can push the limits of rapid learning. Before you consider scaling, integrate as much continuous improvement as possible within the existing size constraints, either through improved practices, new technology, or the putting the right people and skillsets in place. Until you can scale to the point where 1 + 1 = >2, you simply shouldn’t scale.

To put it another way, work to ensure that it’s only the number of people in your organization that’s holding you back. Too often we put the focus on growth in anticipation of increased customer needs, rather than reducing the time it takes to incorporate customer feedback into the product or service. Instead, get one concept proven by a certain demographic (or number of customers), then scale. 

Once you’re in scaling mode, do so responsibly. Go from one to two. Get that to work. Then go from two to three, and get those three to integrate efficiently. When you add teams, a few things happen: it becomes more difficult to collaborate cohesively, and more expensive. You need to make sure you’re scaling ahead of the overhead required to coordinate work amongst your teams.

From my experience, a lot of organizations begin to scale without the infrastructure to support the throughput. Before you look at increased throughput from scaling the number of people, scrutinize your existing end to end processes and practices to make sure they can keep up. Scaling is more than just producing code, especially in large organizations where you regularly work with third party audits and control functions. Ensure that when you scale, the supporting functions like audit, marketing, finance, and customer support are ready and willing to support it.

In sum, localize continuous improvement initiatives to get the most out of your current team before adding to it. Scaling will actually make you move more slowly, and it’s much easier to fail fast. Nail it—really get to know your organizational bottlenecks, without assuming adding more people will solve them—before you scale it.