‘Give away your Legos’ and other commandments for scaling startups
review.firstround.com
review.firstround.com
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.
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 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)
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.
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.
(Nothing personal colordrops, I've just seen this take a lot lately.)
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.
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.
Isn't that exactly what the parent comment said?
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.
The ability to say "this is no longer my job" is crucial if a leader is to focus on what is their job.
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...
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.
If is supremely annoying when code review is done by superior who does not produce code, but has opinions based on vague recollections.
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.
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’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.
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?
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.
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.
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
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.
"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...
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”?
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.
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.
> 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.
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 really aren't. There's just the one Lego.
So many Lego bricks.