‘Give away your Legos’ and other commandments for scaling startups(review.firstround.com)
review.firstround.com
‘Give away your Legos’ and other commandments for scaling startups
https://review.firstround.com/give-away-your-legos-and-other-commandments-for-scaling-startups
89 comments
Who else is mad that the blocks in the second picture aren't LEGO bricks but some other product?
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.
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)
- 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.
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.
Code review by someone who did not cared for years except doing reviews strikes me as a bad idea. Same with that person teaching juniors.
If is supremely annoying when code review is done by superior who does not produce code, but has opinions based on vague recollections.
If is supremely annoying when code review is done by superior who does not produce code, but has opinions based on vague recollections.
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.
Not so simple. You write like "weak engineering hires" is just a problem of laziness or ignorance.
But the reality today is that most companies simply cannot afford to hire strong engineers across the board for economic supply-and-demand reasons.
You have to work within the bounds of possibility, and yes, that sometimes means that people have to wear multiple hats.
But the reality today is that most companies simply cannot afford to hire strong engineers across the board for economic supply-and-demand reasons.
You have to work within the bounds of possibility, and yes, that sometimes means that people have to wear multiple hats.
> 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.
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.
You've got musk prescribing technical solutions at the CEO level, so clearly it's not true in every case.
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.
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.
There’s a line somewhere between understanding technical issues (and being able to make decisions on it) and being too interested in the details.
And another line after that when mandating the details from on high.
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.
Also https://www.cnbc.com/2021/10/05/tesla-must-pay-137-million-t...
The ability to say "this is no longer my job" is crucial if a leader is to focus on what is their job.
The ability to say "this is no longer my job" is crucial if a leader is to focus on what is their job.
Like the absolutely asinine "steering yoke"?
Everyone's first words at the reveal were "is this a yoke?".
[deleted]
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.)
(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.
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.
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?
> "proof X is possible"
Isn't that exactly what the parent comment said?
Isn't that exactly what the parent comment said?
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.
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.
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.
Henry Ford was a good CEO in that he handed the reigns over to his son pretty early on. Henry did his best to hamstring the company until his death.
This is not historically accurate.
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.
Steve Jobs definitely wasn't proposing technical solutions in any version of events I've read.
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.
For a publicly documented example of a bad technical decision by young Steve that the team simply worked around for a while until he changed his mind, see: https://www.folklore.org/StoryView.py?project=Macintosh&stor...
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.
For a publicly documented example of a bad technical decision by young Steve that the team simply worked around for a while until he changed his mind, see: https://www.folklore.org/StoryView.py?project=Macintosh&stor...
he was however heavily involved in UX and design.
LEGO is an adjective. Never call it Legos.
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".
[1] https://english.stackexchange.com/questions/10839/what-is-th...
"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".
[1] https://english.stackexchange.com/questions/10839/what-is-th...
> 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”?
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.
[deleted]
In vernacular American speech (what a lot of us are doing here) the plural “Legos” is fine.
[deleted]
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.
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.
[deleted]
I think you meant acronym? Either way, this is an irrelevant comment to make.
Adjective, apparently: https://twitter.com/lego_group/status/842115345280294912
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'.)
Is "SQL" in "SQL server" also a noun? Not trying to argue one way or the other, I honestly don't know (non-native english speaker).
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”.)
So when the LEGO™®© folk are arguing that "LEGO is always an adjective", they might mean that using it as an adjective noun is the correct thing to do, rather than claiming that "LEGO" by itself is an adjective? I suppose that since "LEGO" is the name of a real concept (the LEGO system) it's unavoidably a noun in essence.
[deleted]
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'.
[0] https://en.wikipedia.org/wiki/Noun_adjunct#Related_concepts
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'.
[0] https://en.wikipedia.org/wiki/Noun_adjunct#Related_concepts
It’s aaactually a verb as in - Lego my stuff, asshole!
> "There are so many Legos!"
There really aren't. There's just the one Lego.
So many Lego bricks.
There really aren't. There's just the one Lego.
So many Lego bricks.
Since we’re being pedantic, there’s actually so many LEGO™ bricks.
[deleted]
No. Lego bricks. We don't have to speak about everyday things in terms of trademarks.
You must say it with smile on your face, thumbs up and a blink - otherwise it's incorrect – I hear they say.
Any advice on how to find the "new job" to replace the one you gave away?
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.
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.
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.
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.
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.
Today the startup CEO wants you to "give away your legos".
Tomorrow he would like to quickly "fire someone for the basic reason that you don't need this role any more" [0].
Double-edged sword indeed. To be fair to the OP, they seem to be writing from the position inside the FAANG, and there it's a much safer proposition.
[0] https://paygo.ghost.io/why-did-i-leave-google-or-why-did-i-s...
Tomorrow he would like to quickly "fire someone for the basic reason that you don't need this role any more" [0].
Double-edged sword indeed. To be fair to the OP, they seem to be writing from the position inside the FAANG, and there it's a much safer proposition.
[0] https://paygo.ghost.io/why-did-i-leave-google-or-why-did-i-s...
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.
You have to be careful as some people give away ALL their Legos, and simply watch others build until it's time to take credit.
Yes, if others can build well.
Or alternatively:
1. Give one Lego away to someone.
2. That someone messes up something immediately.
3. Take that one Lego back.
4. Repeat 1-3 many times. Thinking, how to help somebody to not just mess up everything? And, is it possible to delegate or grow?
Or alternatively:
1. Give one Lego away to someone.
2. That someone messes up something immediately.
3. Take that one Lego back.
4. Repeat 1-3 many times. Thinking, how to help somebody to not just mess up everything? And, is it possible to delegate or grow?
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.
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.
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.
> 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.
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.
Yeah, but my aversion to big companies could be extended even to traditional corporations that don't call themselves startups.
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.
Needs a (2015) label.
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.
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.
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.
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.