> Sounds like the engineers were just entertaining themselves with shiny toys rather than solving the problems they actually had.
This is often the problem when hiring too fast. New employees don't have context or direction but generally people try to be productive, so they start inventing work.
Management team is new too, and not built up either direct or handle the bandwidth and they also are lacking the direction. Senior leadership and founders are likely busy hiring more folks and potentially trying to sort through the chaos described before.
IMO, pre-product market fit company shouldn't have 500 employees, maybe not even 10. These things don't become easier with more people, usually everything gets harder and slow. You also shouldn't have massive marketing or sales force before you actually have product to sell and have figured out your sales motion.
It seemed that Fast was just trying to shortcut their way to be the next Stripe by hiring people instead of actually working on the fundamentals like the product and business.
It's not just limited to startups. When my business unit in Amazon spun up we hired way too fast and ended up having a harder time shipping v1 of the product than if we would've started lean and grown organically. We ended up spending a lot of time on a modularized platform to enable ~5 matrixed feature teams to contribute across iOS and Android apps. Looking back, a small dedicated team for iOS and another team for Android probably could've shipped v1 in less than half the time with a lot less tech debt.
Yeah for sure. I think even senior leaders forget the team culture/context piece, and try to scale up too fast because they are used to it in their current orgs or previous companies.
If you have a 500 person org that has operated for years you can probably add 10%-20% new people each year without it breaking too bad. But it can be very hard to build a complete function from 0 to 100 people within a year because there is no infra, culture or understanding how things work. The new people cannot be absorbed/aligned because there is no central gravity so people easily end up pulling different directions and spending their time on internal coordination vs actual useful output.
Not really. Managers don't have incentives to grow their team size; they have incentive to deliver. And Amazon is known for 'two pizza teams' anyway.
The parent mentioned 5 teams instead of 2. That's director or higher level decisioning. Which is where you frequently end up having someone far enough away from the actual work that needs to be done, starting early to come up with a roadmap. Given fixed deadline and fixed scope, you lean on your PM triangle knowledge and try to get as much headcount as possible to ensure success, because you don't have enough knowledge yet to really decide at what point adding headcount leads to a negative gain. It's usually less about empire building and more about trying to plan things early rather than growing in response to need.
I've been in this situation, as a manager, being told to hire three teams (two being teams of contractors), pushed back to say I should hire only one (the FTE team) as we didn't have enough work for them, was rebuffed and told I needed to hire (the roadmap said we had the work!), hired, and then had leadership panicking about the fact the teams were idle with nothing to do. After a couple months had enough work we could split it (unnecessarily finely) between them so they could all look active, which lasted about a month before the FTE team just started doing it all, as that was more efficient. I didn't stay there long.
> Not really. Managers don't have incentives to grow their team size; they have incentive to deliver.
This may be true about Amazon but it is not a given in general. Managers can operate in the grey area where they deliver just enough to justify more headcount "in order to deliver more" where the underlying motivation is increasing headcount. Not atypical in political environments like banks etc.
If you have a small team, and well hired, then the stack rank grim reaper kills off 20-30% of your labor each year.
For your huge hires, 1/3 of the people were hired to be fired in the stack ranking, which of course is a huge morale hit.
The ones that aren't setup to fail lose 20-50% of productivity doing machiavellian backstabbing, defensively or offensively, for promotions other culturally ingrained/highly encouraged organizational sociopathy.
With 50% turnover per year (IT stats, not warehouse worker stats), it'll be hard to sustain development as well.
This is essentially the long term endgame of any diehard adherent to stack ranking its employees.
Heavy stack ranking basically means for a life event, a worker is very likely to get axed. Any health event, having a child, partner has hard times, or management reorg that puts you with a boss that doesn't like you, and the writing is on the wall.
Companies with a good long term focus should concentrate on acquiring and developing long term workers.
Amazon in particular structures its pay (payoffs come from bonuses and vesting 3-4 years in) in such a way that if one takes a perverse sociopathic view of how they manage workers, that management is incented to rug-pull workers three-four years in so the vesting doesn't happen.
Amazon is DEFINITELY sociopathically and perversely managed to do this.
Once that fundamental disdain of your work force becomes ingrained, then all other organizational abuses (stack ranking, hire for fire, backstabbing) is all fair game.
It starts with stack ranking and the fundamental management sociopathy. Which anyone that looks into accounts of Jeff Bezos becomes apparent of the source.
So why has Amazon been successful? Amazon's advantage in the overall corporate competition landscape was simply that they built an integrated business+IT strategy while every other company treated IT as a cost and annoyance.
But they treat their people like utter shit, and as Amazon transitions from an explosive growth company to a more sustained presence, and from AWS from explosive growth to "utility", the now-huge middle management and workforce devolves from stack ranking and sociopathic disdain into a cesspool where only the wicked survive.
Unfortunately, Amazon continues to ride a growth momentum, so the toxic workplace will be viewed as a positive. Nothing will change until serious incidents occur.
Of course Amazon is huge, so there are workers who may be in less troubled areas. Just keep in mind that toxic areas of companies that derive from corporate practices will inevitably spill over to the "good" parts. Amazon is acquiring massive amounts of pure sociopaths in their management culture, and those sociopaths will "eat" other idealistic parts of the corporate management.
Corporate america is adapting. Better integration of IT and management is going to come to Amazon's competitors. Amazon's apathy to its product fraud and fake reviews, now stretching into a three year ongoing problem shows that it is faltering. Its lies during its AWS downtimes show a blame culture in action.
I find it absolutely crazy that companies do this.
My company's strategy is get one extremely solid person across all our verticals (Android / iOS / Backend / Infra) to minimise communication overhead and maximise iteration speed (since we throw out half the code we write anyway).
I would be very hard pressed to hire more than 2-3 people in each role even if we were offered 10s of millions.
> My company's strategy is get one extremely solid person across all our verticals (Android / iOS / Backend / Infra) to minimise communication overhead and maximise iteration speed (since we throw out half the code we write anyway).
but ... but ... that makes sense ...
I have found that having fewer good engineers is much better than lots of bad ones.
That approach is treated as heresy, in today's tech industry.
Perhaps the thinking is that it's easier to hire multiple good-enough programmers to get dependable productivity, and to replace one if something goes wrong. In the extreme case, if a company has one programmer who is very good when they're working at peak productivity, but then they have a period of low productivity for whatever reason, that company is in trouble. I've been that person.
You still should avoid being too siloed. Bus factor matters; their life problems you might be able to keep them, but you're ensuring you suffer death problems the same time they do.
Well, the software industry seems to believe that, for some reason, we get to live by different rules from every other company on Earth, throughout all of human history.
Depending on key roles is something that every company in history has had to do. It’s a risk, but one that has been paying off for hundreds of years, for millions of companies.
There are ways to reduce “bus factor,” yet still maintain high Quality work. The corporation I worked for, managed this, but the price is extreme levels of overhead and rigidity. That has its own risks. I was treated as a “cowboy” in our company, and was considered to be borderline “reckless.” Most folks here, would have considered me to be destructively conservative and risk-averse. I got the job done, though. Our team consistently delivered high-Quality solutions to difficult problems, for decades.
The “easy answer” is to keep expectations and demands on labor low. Keep quality to a minimum. Rely on “black box” dependencies. Don’t use advanced development techniques. Squeeze your coders like lemons. Treat every employee the same as every other one, and control for the lowest common denominator.
That’s not how I worked.
It's OK. The industry is safe from me, and my radical views. It was made abundantly clear, years ago, that no one wants people like me in their company, so I have been forced to work with people that can't afford even crappy programmers.
>> I find it absolutely crazy that companies do this.
It has changed a bit, but a large part of it is due to HR policies around salary bands. You can have one person do 10x or 5x and another do 1/3x but their salaries are often max .5 factor apart. Ive been in situations where i'd rather reward (perhaps with a vest period) one person with 3x the salary and just skip all the inter-person communications bs, but HR makes it hard.
We were able to do this at hedge funds, and i'm sure small startups can do this, but as companies grow, HR will generally not allow this.
It strikes me as a fundamental mistake that HR are not responsible for the consequences of their policies. Failing to hire people leads fairly directly to failing to ship products, yet that doesn't appear to be attributed back to the team that insists they are all asking for above 'market rate'.
I've been wondering why a seemingly stable startup would go on a massive hiring spree leading to all kinds of chaos rather than take a more measured approach and have started to suspect that this is the reason right here.
In the 90's there was a joke that they'd take the engineering headcount and multiply it by 10M (or something), subtract a multiple of management and there's your valuation.
"Hiring too fast" happens because managers, company executives and sometimes even investors want to play with shiny toys rather than solving the problems they actually had.
The "shiny toys" in this case are employees and the task of managing them.
As a (future?) lead/manager, having more people on your team bolsters your resume. A lot of people would benefit from the company hiring more too as it generates demand in other parts of the business - HR, IT support, etc (which in turn causes more hiring if you need more people to deal with the increased workload). As a higher-up in the company, it looks better on your resume if it was a "big" company with 100+ employees rather than a scrappy garage startup with 3 people, and likewise for investors.
This is often the problem when hiring too fast. New employees don't have context or direction but generally people try to be productive, so they start inventing work.
Management team is new too, and not built up either direct or handle the bandwidth and they also are lacking the direction. Senior leadership and founders are likely busy hiring more folks and potentially trying to sort through the chaos described before.
IMO, pre-product market fit company shouldn't have 500 employees, maybe not even 10. These things don't become easier with more people, usually everything gets harder and slow. You also shouldn't have massive marketing or sales force before you actually have product to sell and have figured out your sales motion.
It seemed that Fast was just trying to shortcut their way to be the next Stripe by hiring people instead of actually working on the fundamentals like the product and business.