Big Companies Don’t Get Slower Because They Become Stupid
Designing processes and software to scale is expensive but necessary. I'll walk through why scaling by definition (basically always) leads to a loss of agility.
Welcome to the Scarlet Ink newsletter. I’m Dave Anderson, an ex-Amazon Tech Director and GM. Each week I write a newsletter article on tech industry careers and tactical leadership advice.
Free members can read some amount of each article, while paid members can read the full article. For some, part of the article is plenty! But if you’d like to read more, I’d love you to consider becoming a paid member!
I enjoy having a newsletter business. I just spent a couple of hours outside shoveling gravel from my pickup truck. This was a useful activity for our property, but man, I appreciate the opportunity of being productive while sitting at a computer. My back appreciates it too.
Last week, while lifting weights together at our local gym, an ex-coworker asked what types of emails I got from readers. Specifically, what were the personas of the typical reader who contacted me? Which is a good question! Because if I wrote a coding newsletter, you’d expect most people to be software engineers. Or if I wrote a “how to be a manager” newsletter, you’d expect most people to be managers. But I’ve managed to write a fairly broad “tech careers” newsletter, so I’ve got a wide range of readers.
After thinking, I said that probably the most common persona was a mid-career tech worker. Early career people read newsletters, but they don’t tend to feel stuck (which causes them to reach out to me), because early career movement tends to revolve around “I’m no longer clueless; therefore, I get promoted.”
However, in my observation, many people run into a wall trying to advance into senior roles. As a line engineering manager, some of my peers made it to senior manager, but a tiny percentage made the jump to Director. Same with engineers. There’s a reasonable chance to make it to senior engineer or perhaps principal/staff engineer, but there’s an exponential dropoff past that point.
And that’s fair and makes sense. Because if every level of management has 10 people reporting to them, mathematically each step up the tree means 10x influence and impact. And 10x fewer positions available for people.
I did one-on-one coaching when I started my newsletter, but I dropped it because I didn’t enjoy it. And I’ve been repeatedly asked to build a training class. But again, that’s not something I’d like to do. I write articles, and that’s my thing.
However, my last manager at Amazon was a VP named Ethan Evans. Ethan quit Amazon shortly after I did. His idea of retirement activities was to make classes, write, coach, and so on. Similar to my idea, except he’s creating a lot more.
I joined Ethan’s organization shortly after my promotion to Director. Getting that Director promotion was a nightmare. Honestly. That leap was hard, frequently frustrating, and I had a lot to learn about the process along the way.
Shortly before my promotion, I went to an internal talk Ethan was giving about hiring. Hiring was an area I excelled at, so I honestly assumed I wouldn’t learn anything. I was wrong. As only certain people can do, Ethan deconstructed the hiring process, and approached it less like “this is how you do your job”, and more like “this is how you get the outcome you want.” I was impressed with his talk and how he spoke about being a leader. Perhaps a year later, I jumped at a chance to join his organization.
Ethan was well known internally at Amazon for his talks, and it didn’t surprise me at all that he created external classes covering some of the same material. One in particular I have to mention and recommend. He made a course specifically covering that leap that I struggled so much with years ago.
The class is “Beyond Senior Manager - Break Through to Strategic Executive.” (15% discount code linked)
In this class, he talks about not just what you have to do personally, but he talks about interactions with your future peers, upward communication, and the practical steps you need to follow to get yourself promoted. This is great. It’s precisely what I would have built if I’d wanted to create training instead of chicken coops.
The link I gave provides a 15% discount to Ethan’s price, which is pretty cool. He said if I was going to share it with my readers, I should be able to hand you all some reward. Yay.
Anyway, if you’re happy reading a newsletter and continuing with your day, great! However, if you’re somewhere in the middle of your career and feeling a bit stuck? I certainly was. This class is the type of resource that could pay you back 100x over. Literally.
That’s it! On with the rest of the article.
I spent a good portion of my career at Amazon, and I thought about company size a good amount.
For certain problems, a startup seemingly had zero hope if Amazon was interested. A large tech corporation can throw a team of experienced engineers and a billion dollars at scaling a solution. You can accomplish a heck of a lot at a place like Amazon if you have the motivation.
Yet in many ways, large companies move significantly slower than startups. I repeatedly had new hires complain that launching new code took a couple of weeks, rather than a few hours at their startup. There were good and bad reasons for those delays, but it certainly has a different pace.
If you controlled a big company like Meta or Amazon, there are absolutely a few things you could do to improve the pace of engineering. But I’m convinced that a reduction in speed and inability to pivot quickly almost inevitably come with growth. I’ll explain. Because that’s what I do.
Efficiency vs. Size
Amazon operates (mostly) like a big bundle of startups. Which is awesome, because particularly if you move around inside the company like I did. Because you get to see how different groups operate. Some of them sincerely operate like a startup (with a lack of process and moving quickly and everything), and others are far more red-tapey.
In my experience, as groups grow, they become less efficient and agile per headcount. Essentially every person you add makes everyone else slightly less efficient on average.
My point is that imagine you have a group of 20 people busy launching features. If you doubled that headcount to 40, you absolutely would not see a corresponding 2x productivity increase. This shouldn’t shock anyone. But it’s almost always blamed on the actual leaders in place, and the policies they implement.
“Stupid bureaucracy makes us slow.”
“They made some bad hires recently.”
“We hired so many useless people.”
“Now we have all this process that slows us down.”
I think instead that it’s something inevitable, like the weather.
You can hear this an endless number of times from people who have worked at startups. There’s a fantastic little 10-person startup, throwing feature after feature into production.
They’re different and exciting, because they’re moving so much faster than their competition.
“Holy cow, did you see how fast they added the <featurename> feature?! We’ve been waiting on that feature for 3 years from <leader in the space>.”
Then, because of their success, they grow their number of employees. And weirdly, their launch pace doesn’t increase to match the personnel growth. Often, despite that growth, you’ll actually see a decrease in new features as time goes on.
Heck, here’s a quick anecdotal story.
Goodreads was a rising success story. They were growing quickly, and building new things. Amazon bought them and gave them massive funding, more than doubling their team size. Whoohoo, imagine what Goodreads can build now! Except.. Look at what actually happened. Has Goodreads fundamentally changed their feature set or site, considering the incredible increase in funding?
So again, is that leadership incompetence, or, as I suggest, the weather?
