Scaling with Your Team

I still remember the exchange.

It was about 18 months into my tenure at Square—so about 5–6 years ago at time of this writing in 2018—and I’ve had the good fortune of working with a bunch of early Square engineers through my first set of projects. We were well into the hypergrowth phase of the company’s trajectory; all the business metrics we cared to track were threatening a hockey stick pattern. With this context, it was to my surprise and dismay that a number of early Squares decided to leave, all within a couple of weeks of one another.

I sought answers from my manager at the time. Their response, paraphrased, was that

Sometimes, people don’t scale themselves as fast as companies scale.

It was a prescient statement, as eventually more Squares moved on as the business—and hence the team charged with its expansion—continued to evolve. I was reminded of this episode when I read this article from First Round which echoes much of the same sentiment:

Hypergrowth and The Law of Startup Physics

But here, the featured leadership coach applies an even more-precise mental model—companies scale exponentially, while people scale linearly. If this is indeed how startups operate, then it should be expected that employees turn over because they cannot physically really catch up with the demands of scalability imposed by a burgeoning business. At each exponential inflection point, more experienced personnel need to be hired and installed in authoritative positions to guide the organization to its next apex.

One immediate consequence is that absolute employee retention should not be a management goal. Of course, this is already the standard set by proponents of the “hire slow, fire fast” philosophy1, but less obvious is the idea that the people who’ve built the company up to this point may also be untenable moving forward. It’s counterintuitive and a bit disheartening to think that major contributors to the startup’s success could have definitive expiration dates.

Another result is that, since the absolute and relative impact an individual has within a growing company diverges over time, it’s often a challenge just to maintain a similar level of relative impact at scale. For instance, a system built by an engineer that supports his team of 10 people (absolute impact: 10) can either be the entire startup at that point (100% of 10 employees) or a much smaller subset (20% of 50 employees). More obvious are management roles: a head of engineering for an organization of 10 engineers (50% of 20 employees) is notably distinct from one running a 100-person engineering team (25% of 400 employees).

It’s also worth detailing what scaling actually means for people. It’s not about producing more raw output per person, but instead refers to the establishment and adherence to new modes of working, the ways to organize and communicate appropriate for the size of the team. With software development, it may mean more code reviews and creating strategies to split off large codebases into smaller medium-sized ones while maintaining a quality bar. With communications, it likely entails more information broadcasting and debate with additional stakeholders2.

All this said, even with all these challenges that come from rapid scale, the process is also terribly exciting and I feel privileged to have experienced companies amidst hypergrowth—previously at Square, currently at Affirm. Perhaps the raw physics of scale will doom me to a limited shelf-life in the future, but I’d be very happy to eventually leave behind an Allen-sized imprint.