It can be a bit of a double edged sword, especially in startups.
I've been on the leadership side of this where you suddenly realize it's vitally important to your growth that you can give away the things you're doing day to day - unblocking people when they get stuck has a higher ROI than doing it yourself even if you'd do it better/faster because it scales more.
But I saw this very differently at an early stage company where our being successful led to people being hired to do all the interesting areas I had been growing into - if someone has Legos anxiety it may very well be because they've realized that this growth is not going to work well for them.
The author of [0] seems like an utter tool. They seem to wear their HR complaints like a badge of honor, and complain that people are not willing to make personal sacrifices to help the company gain.
I always thought he wrote a great ad for Google. "Look, there is this company where your director cannot just fire you on a whim. This company where you can decline a meeting because you are taking a personal day. This company where there is good food in the cafeteria" etc.
The ability for people to give away their Legos is one of the most important ways I guage an organization's health. If I'm in an established organization and I see a VP or director prescribing technical solutions to engineering problems, it's usually an indicator that:
- the leader cannot emotionally bear to give up engineering work and focus on leadership work. This signals a lack of maturity.
- there is some other serious organizational problem preventing delegation from happening (weak engineering IC hires, lack of clear processes and ownership patterns, etc)
I don't think "engineering work" and "leadership work" should be a dichotomy, especially if you're trying to follow a promote-from-within mentality.
Sure, after N years, you might be career-tracked from development into management, but you probably also know where all the bodies are buried. If you're not doing code reviews, trying to mentor new developers, or just butting in and saying "We tried that in 2006 and it has huge non-obvious compliance/performance/maintainability costs!", it lets all that knowledge go to waste.
Was Henry Ford a bad CEO? I have more faith in a CEO that's involved to a degree and understands the engineering side as opposed to some out of touch MBA.
I think people like Ford, Bill Gates, Steve Jobs, are the exception that proves the rule. It is astronomically rare for a CEO to be that involved at a micro-level and be successful.
Having been a bit closer to the action (through secondhand reports from colleagues), it was not at all uncommon for Steve to propose detailed technical solutions, but (1) many of them were no good (2) his teams got pretty good at working around him on such matters and (3) I think over time he developed the good sense to trust his lieutenants on matters like this instead of being overly insistent on seeing his bad ideas implemented.
In contrast, in UX/Design, Steve generally had very astute insights, knew so, and it was much harder to get him to change his mind.
I worked at a multi-billion dollar company (not Tesla) where the CEO considered himself chief engineer and tried to prescribe low-level technical solutions from the CEO level.
It was terrible. CEOs don’t have the time to keep up with technologies and understand the low-level requirements that drive good decision making. A person doing a CEO job can’t possibly keep up with someone doing full-time engineering work in any fast-moving field.
The only way we could make progress was by subtlety seeding our ideas to the CEO and waiting for him to claim them as his own directives after he realized they were good ideas. It was an exhaustive way to get things done.
I've talked to some folks from Tesla whose stories absolutely reinforced the parent's point. Some of the silly things Musk has dictated turned into massive wastes of resources for the engineering team.
And I'd say Tesla is successful despite and not because of that. Examples include: Tesla's shot at an in-house ERP and the drive to fully automate production. Both cost them a lot.
I'm sick of "but Elon Musk does X." Yes, the guy's exceptional. That literally means not representative, outside the normal rule or distribution. So like a black swan, you can point to him and say "proof X is possible" but you can't point to him and say "proof X is normal"—you've got to wait for "half of Fortune 500 CEOs do X."
(Nothing personal colordrops, I've just seen this take a lot lately.)
I mean, it's a fair take to argue that CEO-ship ought to be meritocratic, in the sense of only hiring extremely exceptional individuals. If you're just an average jobsworth doing a merely 'decent' job, you shouldn't be the ceo of any company.
It's kind of similar to airline pilots or surgeons, where we have to demand "excellence" as a lowest-common-denominator. At that level, they need to be graded on a reverse curve, where unlike regular grades, where a mere 65% score is a passing grade — for those folks, nothing less than a 95% should be a passing grade.
It's easy to make the argument for airline pilots and surgeons, because the human tragedy that results from their potential incompetence is immediate and obvious. I feel like the tragedy that comes out of incompetent CEOs is a lot more insidious, and sneaky. Poorly run companies, and depressing "waste of life" has ruined a lot of people's lives.
In fact, one could dare to surmise that it's actually, statistically speaking, directly killed a lot of people (an easy low-hanging fruit here would be safety stuff that OSHA doesn't cover), but there's a lot of mental health stuff we don't track as well. This whole line of thinking reminds me a lot of Florence Nightengale — her primary contribution to medical statistics was to take something that people brushed off as irrelevant or not-causal, and prove that it was a primary malefactor. She convinced the british top brass that the bulk of their deaths during war had nothing to do with enemy action, or even hospital deaths from injury, but literally was just caused by petty diseases, due to poor barracks sanitation amongst uninjured men.
Competence at being a CEO, competence in the core business (whether engineering or otherwise,) and competence at splitting focus between completely different levels of the business are all different competences. Being skilled at all three is the exception, but that doesn't make the non-exceptions incompetent.
If you always aim for the exception, what you actually end up doing is selecting for the third competence; someone who can code-switch. And if that person isn't exceptional, then you just have a CEO who is getting involved things outside their depth.
Shouldn't it also make you sick to read about prescription for exceptional hypergrowth from 500 to 5500 employees? It's not like everybody here will experience this kind of rapid growth. We also don't know how much of it is survivorship bias. What if there are cases where this approach contributed to failure, ie. because people were shifted from where their expertise actually was?
In context it reads as parent disagreeing with grandparent's statement that a "leader [who] cannot emotionally bear to give up engineering work and focus on leadership work… signals a lack of maturity" by saying "[Musk shows] it's not true in every case."
So my quibble is simply that "proof leaders do X" doesn't disprove "doing X is bad leadership," despite parent's implication to the contrary.
> If I'm in an established organization and I see a VP or director prescribing technical solutions to engineering problems
That 'established' part is key because early stage companies require wearing so many hats. And knowing when and to whom to let something go it's crucial IME.
There are some bounds on this, I’ve seen plenty of situations where VPs may not be prescribing technical solutions because they are so far out of touch they can’t even understand the solution options in play.
This is a fantastic article and I have shared it with many, many engineers in the past. It's one of those totally counterintuitive things about career growth. It's all about accumulating scope as one grows into a senior-level role. Then everything flips, and one's seniority tends to grow proportional to the amount of scope one gives away (therefore enabling others to work on larger-scope initiatives). Applies to managers as well as individual contributors.
This article was shared with me in an organization that was scaling incredibly quickly; it was extremely helpful. The mantra, "give away your legos" has echoed for me since.
The first time I was in management, I failed because I couldn’t give away my LEGOs. I wanted to continue to micro-manage and still do the stuff I had done as an IC and wasn’t ready to trust the team to do things in my place. My fear was that things wouldn’t be done as well (which may have been true, although that doesn’t mean that wouldn’t have changed over time) and I wasn’t able to let go and focus on the stuff I needed to focus on as a leader. I failed.
I learned from that experience and the next time I was in management (and continuing today), I was so much better at letting things go, trusting my team to get stuff done, and focusing on the next challenge. That doesn’t mean you aren’t sometimes wistful or nervous, but I know for me, I had to learn to trust people to get things done and be OK even when things weren’t done exactly as I would do them.
As a group grows, what is the general size, time, or other markers of maturity where this transition to “LEGO disavowal” begins to pay off?
I’m on a small team in ag automation that is growing/maturing slowly, and I'm curious when this needs to happen in earnest. Frankly, we’ve struggled with the little turnover we’ve had.
Such an insightful article. The definition of politics being at the inflection point of when people switch from indexing on the interest of the organization to individual and team interest was very helpful.
One thing I might add about scaling teams and growth in general is a bit more meta, which she talks about in a few ways, whereas I would estimate a sense of security is valued at upwards of 30% of your comp.
Some people weight it differently, but when you re-examine wealth as the ability to reasonably plan into the future, it's not just a linear effect of marginal dollars. Working in a high growth environment means giving up the real wealth that is a sense of security.
Your "legos," in the article, are the levers you have that you percieve as securing your ability to plan to still be working there in 6, 12, or 18 months. The growth mentality is that there is no stability and you just learn to manage and extract value from dynamic situations, but that mentality and talent are not always present. To work in startups, you need to source your sense of stability and your ability to plan from somewhere outside the office. This can be a constructive attitude, or it can be frugality, or just maintaining your openness to opportunity elsewhere, but what seems to cause that inflection point during growth isn't so much the speed of growth, but whether you can provide your teams with the ability to maintain that security to plan for themselves as individuals. It's similar to offering her colleague something with a multiple on importance to what she was working on to get her to delegate her current queue. That let her plan, and secured her perception of her future.
That "new job" is picking up new legos. Looking at what problems there are to solve. Which legos would fit the best.
In that article, point about "Fire people. Just do it!" means, that if there is some part of business that does not generate enough profit or other success, those people need to be "fired" or they should find another job in same or other company, so that job would generate enough profit. If those people are not "fired", then company will get less profit or go bankcrupt.
That "new job" depends, what customers actually need the most. Customers could say "faster horse" but can not imagine "auto" or other most efficient, easiest to use solution.
Sometimes with those legos, it's about picking only most important in use legos, making them work together, and then making many groups of legos working together, and groups of groups, while each lego has a failsafe way to recover from possible error scenarios.
Sometimes it's looking at what some most advanced competitors are doing, and imagining what way it could be hugely improved and simplified. Even better, going in completely different direction with more advanced solution, and leading the way.
Point with legos is, to not be too emotional about changing legos, job contents, etc. If there is a way to solve something completely, automate oneself away from job, and move to bigger different role with more advanced legos, just do it. With more advanced legos, it's possible to solve bigger problems.
The irony with that view is that what looks from the outside as a single lego may be viewed from the inside as something much more complex, because we're not talking about actual legos here.
Yes. Maybe some more concrete examples would help:
1) I built one company infra. At first, I figured out what software, servers, etc there was, documented it, upgraded various software, migrated email, etc. I was fired for some nonsense reason, but anyway, we are still friends.
2) I was doing some coding at some another company. Coding did not progress well, so they fired me. Good, it's OK for me.
3) I built Open Source software for many years. Maintaining, merging pull requests, etc. Adding new features, dependencies, etc. When adding each feature, fixing corner cases, so it all works together, many parts are intendependent of each other. Now I'm thinking which dependencies are not deprecated yet, is it possible to figure out how to upgrade all dependencies and upgrade to newest version of web framework. Or should I just figure out how to take in-use code, figure out what newest dependencies there is available, and rebuild whole stack again.
Therein lies the rub. I've never had a manager either suggest or provide a new opportunity to me while they were encouraging me to hand off my work to someone else.
The Lego's worth keeping either impossible to give away or working with the recipient of the Lego is going to be far more rewarding than the Lego itself.
In Danish, Swedish, Norwegian and British/Australian/NZ English, LEGO is an uncountable noun like "rice" or "sand". The Danish LEGO company used to advocate this usage by printing the following on their sets:
"Dear Parents and Children
LEGO® is a brand name that is very special to all of us in the LEGO Group Companies. We would sincerely appreciate your help in keeping it special by referring to our bricks as "LEGO Bricks or Toys" and not just "LEGOS". By doing so, you will be helping to protect and preserve a brand that stands for quality the world over." [1]
So the singular form is clearly the manufacturer's intention, but "Legos" is widely used in North America and is just one of those words that grates if you haven't grown up with it. For whatever reason I have the same reaction when the Poms say "kit" instead of "equipment".
> For whatever reason I have the same reaction when the Poms say "kit" instead of "equipment"
This is interesting, and one I’ve never noticed.
Would you say “the drum equipment has been set up” vs “the drum kit has been set up”? Or more in the sense “the kitchen has been equipped” vs “the kitchen has been kitted out”?
Probably the latter in both cases. I'd still use the word kit to denote something that comes disassembled that you need to put together. It's more like when someone describes their new phone as a "nice bit of kit". Ugh!
The word LEGO wouldn't exist if not for the company. The wikipedia article actually doesn't say the full story about how the name came to be aka "leg godt (play well)" => LEGO came from a "naming competition" that the founder made and which he ended up winning.
The company would like that the word "Legos" isn't used as it implies that "Legos" are plastic interconnecting bricks of any manufacturer, including the ones that just blatantly copy even the newest LEGO sets.
The plural of Lego may well be Legos, but Lego is the system not the brick, so unless you've got a plurality of systems, it's gratingly wrong to call Lego bricks Legos.
Please relax. Even the company said they don't care. They're supposed to be fun, we don't need the syntax police. Now, please hand me that bendy-twoey.
Programmers being very nitpicky about syntax is kind of a thing.
US-Americans just get super defensive if they get called out on doing something different than the rest of the world. Sure it is not a big deal and I don't care about respecting the trademark of the Lego company but you can still accept that Legos is wrong. You are free to call it whatever but it will sound very grating to an international audience.
The unfortunate thing about that is that it's wrong. I don't mean the usage, I'm British so I'm firmly 'lots of Lego', but it's obviously a noun. Using it to describe a brick etc. doesn't preclude that. (It's 'attributive', or 'adjunct'.)
In “SQL Server”, “SQL” functions as an adjective modifying “Server”; its not unusual for what are normally nouns to do that, distinguished only by position(e.g
, “hat” in “hat rack”.)
Wikipedia says [0] 'adjectival noun' was 'formerly synonymous, but now usually means an adjective used as a noun'.
Regardless, it's not an adjective, much less 'always' - it's always a noun; sometimes used attributively ('adjectivally' if you like) / as a noun adjunct, such as in 'Lego bricks'.
When you have completely given away everything you are responsible for, then you are now free to pick up all of your boss's responsibilities. So i guess the sign is, your boss gets promoted, you get promoted into their job and so on.
It is an interesting article, but the hardest thing to me is accepting the premise: why do we want "scaling startups" in the first place?
As a consumer, I'd be hard-pressed to think of a company that can make my life better or deliver better services because of its size.
As an engineer, I'd rather work in an organization that can be more efficient and profitable by being super-focused in the core business and commodifying/outsourcing/open sourcing everything else. I get depressed thinking about all the brainpower that we waste by having these huge corporations competing for market share in areas that would benefit immediately from collaboration/interoperability/open standards. Google and its 20 different messaging solutions come to mind, but I also don't forget that Skype was sold by 7 billion dollars and then wasted away. And history likely repeating itself with Discord.
As an entrepreneur, I'd rather have a Basecamp-style company with < 50 people and constantly profitable over an unicorn where I'd have little to no control and would be dependent on VC money.
Every day I am getting more and more convinced that the problems of Capitalism could be mitigated by not allowing corporations over a certain size. Over 150 headcount? Instead of fighting to get the company culture in place, just break it apart.
> As a consumer, I'd be hard-pressed to think of a company that can make my life better or deliver better services because of its size.
Please let me know if I'm mis-understanding this sentence, but there are quite a few companies that confer benefits to consumers as a result of their size. Think of Walmart, Amazon, any ride-sharing company, any airline, any carmaker, etc. Those are all examples of business models whose value proposition is predicated on the scale of their operations.
Granted, not every industry or company depends on scale, but plenty of them do. Business is a big tent, and different industries have different requirements for entry. It's exceedingly unlikely that the COVID mRNA vaccine could have been invented by a company with the scale or capitalization of a Basecamp.
Again, let me know if I'm misunderstanding the point you made.
No. All the examples you listed at best make things cheaper, not better, and in some cases they can only do so by sacrificing quality (airlines, walmart) or by destroying profitability in one sector and funding the business somewhere else (carmakers only make money via financing, ride shares only survive due to Softbank, Amazon's "your margin is my opportunity" and AWS, etc)
> It's exceedingly unlikely that the COVID mRNA vaccine could have been invented by a company with the scale or capitalization of a Basecamp.
Certainly not. It would take several of these smaller companies, working in different parts of the research chain and all collaborating organically (without any central planner). The real question is whether it would be faster or slower to develop it in such a scenario, and also if the trade-off is acceptable.
A ride share network being bigger means reducing your time until you get picked up. Imagine 1 car servicing 1 rider vs 10k cars to service 10k riders, they will be much more distributed.
You could also have a complete p2p system and forego a central company. Or your network of 10k drivers could be made of 100 taxi coops, each with an average of 100 members.
The concept of a scaling startup is used to juice the internal brainwash so that everyone feels they are 1) part of a successful company and 2) destined for career growth.
There are many companies that label themselves as startups despite not actually being startups I would also expect that many of those companies also consider themselves to be 'scaling startups' as well.
I've been on the leadership side of this where you suddenly realize it's vitally important to your growth that you can give away the things you're doing day to day - unblocking people when they get stuck has a higher ROI than doing it yourself even if you'd do it better/faster because it scales more.
But I saw this very differently at an early stage company where our being successful led to people being hired to do all the interesting areas I had been growing into - if someone has Legos anxiety it may very well be because they've realized that this growth is not going to work well for them.