M&Ms: Empire Builders
How trying to build empires instead of building things people want ruins managers and teams.
Hey Team,
I don't know many software engineers who don't like building software.
An engineer who hates building things would be like a painter who hates painting. Or like a rabbit who hates mating. While I'm sure they exist, I don't know many of them.
But I know plenty of managers who love building empires more than making things.
In fact, I was once collegues with a leader who cared far more about hiring and growing his teams than building the best product. He had his teams spend tons of time crafting power points. All these power points were about what the organization might look like after they were allowed to hire even more people. But what would we do with all those people as a tiny startup?
One day while I was heads down building things with my tiny team of engineers, I got the ping. The empire builders body guards approached me with beautiful-looking slides detailing the organization's shape and where my tiny team and I would fit. They made it all sound so appealing, too; "take this fig leaf offered to you, Louie, and you, too, will have a place in our new empire."
But I was just too busy to try and understand. I was busy building what felt immediately important and painful to my business partners. And I was not yet adept at corporate politics to truly understand what was going on. We were a small startup at the time. And truthfully, like a typical engineer, I had too much fun building to worry about organizational design.
Then, in my usual hurry in my one-on-one with my boss, I explained to him that I was offered a chance to be out of his organization. I explained that, according to their slides, they'd soon have a vast empire, and if I went, I could soon have a big team. I didn't think much of it, but my boss was fuming; I told him not to worry. I hadn't accepted.
Within a year, that leader was pushed to a corner. And shortly after, he left entirely. His team suffered badly. It had become painfully obvious to leadership what was happening—a severe case of empire-building.
This experience made me permanently nervous about the dangers of overhiring.
But the thing is, while his empire failed to materialize at a small startup, these sorts of things can go on for a long time in big organizations. And plenty of empires do materialize. I saw it firsthand at Walmart. Walmart isn't unique; Daniel Vassallo tweeted that it would take many meetings at Amazon and "it used to take us a month to move a button on a UI."
All of this is to point out that it isn't the engineers, designers, or the product people who are to blame. No, the blame falls squarely on the managers, on the empire builders. And the leaders who allow the empire builders to keep growing teams unfettered. Only so individuals own a tiny and tinier slice.
This all brings us to recent events and observations.
Elon Musk bought and let go of, or pushed out, over 90% of the workforce at Twitter in the last two weeks. There is no way the remaining people are "the best" people; they are just people. It was all so arbitrary, chaotic, and so deep in terms of cuts and resignations.
But the shocking thing is that Twitter has not gone down yet. And there is a real possibility it might still succeed in the longer term.
And if Elon can somehow turn Twitter around and make it better than its competitors, then there is no way that is an indictment of the engineers, designers, and product people that are now gone. All of that was arbitrary.
But it is a massive indictment of leadership at all levels—a massive indictment of Empire Builders who gave people a smaller and smaller slice of ownership.
Two Tweets from this week:
This week I wrote a thread about the ramifications of Elon Musk pushing out over 90% of the workforce at Twitter. In the thread I said that Big Tech would never be the same if he succeeds. There will be massive pressure on CEOs from shareholders to downsize.
And if he does succeed, Twitter will become one of our best examples of how bad Empire Building can get at big companies.
As an engineering manager, I dealt with sponsoring many engineers who were on H1Bs for green cards. And I dealt with many other various visa-related issues, like F1s and L1s, and on and on.
The process is terrible; it should be overhauled. There is absolutely no reason to have an arbitrary 60-day cut-off date, it is far too little time if there are layoffs, and it leads to people taking lower and worse offers. It isn't good for the economy.
There are other issues too, but that's for another time.
One Article from this week:
It’s always sad when Startups shut down. But I am sharing this link because I think its an important lesson for engineers.
Kite was trying to build an AI code assistant.
"the problem is very engineering intensive. It may cost over $100 million to build a production-quality tool capable of synthesizing code reliably, and nobody has tried that quite yet."
“We failed to build a business because our product did not monetize, and it took too long to figure that out."
They were at it for 7 years and the problem was too hard to solve.
One Meme from this week:
One reason I like sharing memes on this newsletter is because Comedy, a lot of times, points out the truth we are uncomfortable with.
Memes then are just socities canary in the coalmine.
As George Bernard Shaw said:
“If you want to tell people the truth, you’d better make them laugh or they’ll kill you”
As always, thank you for reading.
-Louie
P.S. you can reply to this email; it will get to me, and I will read it.
A timely reminder for me
there are great empire builders but they are few and far between
To paraphrase Einstein
Instead of me trying to emulate the empire builders, I should just be myself and that means finding / scraping / earning a ton of autonomy to build products and systems I want to build
No more mindless mimetic desire copying
Hi Louie,
Thanks for your great newsletter. I would love to hear your opinion about the failure of Kite as a business.
I agree with the Kite founder that the code technology was way too early to be built as a business in the mid 2010s. It was at least 10 years behind prime time. To give a perspective, 2014 was the time when the first academic paper introducing the attention mechanism behind all used Transformer models was released (https://arxiv.org/abs/1409.0473).
But I don't fully buy the founder's argument that "making their developers 18% faster when writing code did not resonate strongly enough" with engineering managers. I am a happy paying user of current code writing assistants like Copilot, and I use them for both job and personal projects.
The time savings with these tools are massive (even though they make blunt mistakes sometimes), and I am surprised that engineering managers would not want their developers to be more productive when writing code.
I'm curious to hear your thoughts as a former engineering manager.