Overstaffed for their current businesses, or overstaffed for the new businesses they are exploring?
As an outsider it’s easy to say that tech companies often have too many staff, but internally it’s much easier to see what they’re all doing, and it’s often a lot of exploring new product ideas. That’s an expensive thing to do.
Do these companies need to be doing all that R&D? Maybe, maybe not, but as much as you criticise (for example) Meta for Instagram stories, not making those sorts of changes presents a huge business risk of falling into obscurity by not keeping up with the market, or finding and controlling the next generation of technology.
I like small companies as much as anyone, but I recognise that for big companies this sort of thing is an existential issue and something that we need to accept and learn to live with.
Yes there’s still bloat, but it’s a common bias to see others as bloated/ineffective and see yourself as justified.
Yeah I'm a little skeptical of how much this goes on (outside of a handful of specific industry thought-leaders who aren't moving the needle on hiring costs), but this is a good example because if this is worth doing to companies in terms of their bottom line, then it's almost by definition _not_ over-staffing.
There is room for bootcamp programmers but it isn’t in working on and maintaining some ball of yarn that does A/B testing, deployment, analytics, ad delivery, CRUD, caching, text search, route handling, animated transitions, real-time chat, event notifications, etc.
Bootcampers, aka product developers, should be working with a language and runtime that moves all of these features into the language itself.
The language and runtime should be built and maintained by a smaller team of computer engineers. Perhaps this underlying language is from another vendor and is extensible or perhaps it is built in-house.
This would allow for product developers to rapidly iterate on product ideas and for the computer engineers to work on longer timescales while worrying about scaling, deployment, resource management, etc.
I’ve seen this model tried time and time again, though typically with an in-house “framework” rather than a language, which is a better approach anyway. It’s the “smart people build the foundation, dumb people customize with it” model. It doesn’t work well.
The reason is that the “smart” people building the framework end up spiraling off into ivory tower land. They put a lot of effort into making common patterns easy. But in so doing, they make the framework’s internals hard to understand. They also become disconnected from customer reality.
Meanwhile, the “dumb” people serving customer needs end up having to work around the framework in order to accomplish what they want. Because the framework is impenetrable, and because they’re junior, they end up make horrific balls of mud.
It’s better to have cross-functional teams composed of a mix of skill sets, that can both focus on customer needs and build the underlying abstractions needed to make that easy. This also allows the junior folks to learn from the senior folks.
> though typically with an in-house “framework” rather than a language, which is a better approach anyway.
I think that having a framework written in general purpose language is part of the problem because it allows for things to turn into horrific balls of mud.
> The reason is that the “smart” people building the framework end up spiraling off into ivory tower land.
I don't think this is about smart vs. not smart. It's about different disciplines and abilities. Product developers should also be doing more (or all) product work and interacting with customers.
> They also become disconnected from customer reality.
Computer engineers who are creating a language and runtime should be servicing the specific domain of that the product. Part of the disconnect with DevOps is that it is solving for deploying general purpose tools rather than a specific domain. Have the computer engineers responsible for creating domain specific tools as well as deploying those domain specific tools and everyone should be more connected to the final outcome.
>I think that having a framework written in general purpose language is part of the problem because it allows for things to turn into horrific balls of mud.
Yeah, the problem definitely is that people are able to write code that gets thing done, instead of being unable to perform their work.
I'm not sure how you got "unable to perform their work" from what I was suggesting. A/B testing, analytics, CRUD, etc, are all features that are ancillary to any products that need to be made.
Imagine if a language had A/B testing baked right into it. You define a couple of functions annotated for A/B testing and they are automatically A/B tested. Putting all of this inline with product functionality is generally what causes these balls of mud in the first place.
I think you’re overestimating the value of building such support into a language, rather than using libraries/frameworks, and underestimating the difficulty of creating bespoke languages. Speaking as someone who’s actually tried what you’re suggesting—in a production project—and learned not to do it again, this whole conversation smacks of theory-crafting rather than practical experience. But I invite you to try it!
Are there any tech (or other) companies that have dumped 50-90% of their workforce without any effect on output? Because otherwise OP is either the only person in history to discover this or wrong...
Oh I was hoping, but it is /s ... Nat says "I lived it" for those who do not click.
Being a part of the solution vs being the person who officially carries the solution across the finish line can be seen differently by observers. I think that's what Nat is oversimplifying.
Interesting. My more lengthy but less impressive career has shown me something different.
Many of the companies I have worked at had management issues which prevented the existing tech staff from performing at optimal levels or even inhibited it.
Just one example of this is a startup which grew to a 1500 person company under the same CIO, and that CIO was comfortable with what had gotten them that far. Consequently, we had 65 engineers in silos, often strugging with the same problems and reinventing the same wheels.
Those of us who pushed for some platform level focus were politely listened to and then forgotten, presumably because new is scary and what has gotten them this far is "good enough".
However, at every monthly company meeting, they would promote the recruitment compensation bonuses because we "desperately" needed more tech staff. No, we didn't need more tech staff. We just needed the freedom to do things smarter.
At some other companies I've worked at, tech staff is an unfortunate necessity, a cost whose ability to enable the rest of the company and business itself was rarely recognized. If a tech employee left, management would intentionally drag its feet on replacing them (because it made budgets easier to maintain).
Granted, I haven't lived in the startup VC world where money magically appears within the right circles. There it would seem that proving to a VC that you are scaling up for big gains means you're growing your staff at a phenomenal pace. In those places, yeah I bet there are people who aren't necessary. I still bet there are management who aren't necessary or who are preventing some of those devs from doing useful things...
Off topic : Twitter submissions tend to really struggle to make the HN front page despite many upvotes. I assume the HN algorithm is heavily biased against the bird site ; I'm not too sure it's such a great thing.
How many of them satisfy the on-topic criteria for HN: “anything that gratifies one's intellectual curiosity”?
The OP contains nothing more than a dubious claim with no supporting evidence or insight, is not itself intellectually curious, and does little to spur interesting discussion. If the post was made by a less prominent person it wouldn’t even be on anyone’s radar to begin with.
Im not so sure I agree HN would be a better place if the front page was loaded with topics that were merely further amplifying the Twitter posts of famous people.
Actually, in this instance, there a discussion to be had about the (lack of) management skills among CEOs who've never had a job. There is another possible discussion about CEOs saying what they really think, which is always rare.
BTW, an underrated advantage of discussing tweets on HN is that the commenters will have read what they're commenting on.
Ah the old "Everyone else is stupid" point of view. Sure, ok, Mark Zuckerberg is stupid. Satya Nadella is stupid. Tim Cook is stupid. Every tech company CEO is stupid.
Maybe every CEO isn't stupid. Maybe these companies were simply structuring their businesses to maximize their chances of capturing new growth opportunities in an environment of incredibly cheap capital. Most companies could hire 5 engineers who will completely transform their businesses. And they'll hire 50,000 in an effort to find those 5.
It's probably true you could run twitter with under 1,000 people. But it's probably not true that you can easily figure out who those 1,000 people are and get them to stay whilst you fire the other 6,500, and it's absolutely true that if the current CEO of twitter had tried that he would've got fired before he had a chance to pull it off. Go ask investors, do they want Twitter to reduce their ongoing costs significantly, with a significant chance it does long term damage to their growth plans, or do they want to grow revenue 30% YoY?
I find it very hard to tell a smart person with a lot of money from a stupid person with a lot of money; it seems that wealth insulates you from a lot of consequences.
I think the problem is that at the scale of these companies, everyone is too stupid to effectively manage them.
Well, up to this point most have been issuing overvalued equity to cover employee pay (e.g. diluting investors).
If valuations continue their path towards coming in line with actual fundamentals, many companies will soon find they can’t afford the number of workers they have. Dilution will become quite severe at lower valuations
In my neck of the woods, "line" managers have a vested interest in growing their team sizes and taking more and more budget to increase their personal valuation.
29 comments
[ 3.0 ms ] story [ 77.4 ms ] threadAs an outsider it’s easy to say that tech companies often have too many staff, but internally it’s much easier to see what they’re all doing, and it’s often a lot of exploring new product ideas. That’s an expensive thing to do.
Do these companies need to be doing all that R&D? Maybe, maybe not, but as much as you criticise (for example) Meta for Instagram stories, not making those sorts of changes presents a huge business risk of falling into obscurity by not keeping up with the market, or finding and controlling the next generation of technology.
I like small companies as much as anyone, but I recognise that for big companies this sort of thing is an existential issue and something that we need to accept and learn to live with.
Yes there’s still bloat, but it’s a common bias to see others as bloated/ineffective and see yourself as justified.
There is room for bootcamp programmers but it isn’t in working on and maintaining some ball of yarn that does A/B testing, deployment, analytics, ad delivery, CRUD, caching, text search, route handling, animated transitions, real-time chat, event notifications, etc.
Bootcampers, aka product developers, should be working with a language and runtime that moves all of these features into the language itself.
The language and runtime should be built and maintained by a smaller team of computer engineers. Perhaps this underlying language is from another vendor and is extensible or perhaps it is built in-house.
This would allow for product developers to rapidly iterate on product ideas and for the computer engineers to work on longer timescales while worrying about scaling, deployment, resource management, etc.
The reason is that the “smart” people building the framework end up spiraling off into ivory tower land. They put a lot of effort into making common patterns easy. But in so doing, they make the framework’s internals hard to understand. They also become disconnected from customer reality.
Meanwhile, the “dumb” people serving customer needs end up having to work around the framework in order to accomplish what they want. Because the framework is impenetrable, and because they’re junior, they end up make horrific balls of mud.
It’s better to have cross-functional teams composed of a mix of skill sets, that can both focus on customer needs and build the underlying abstractions needed to make that easy. This also allows the junior folks to learn from the senior folks.
I think that having a framework written in general purpose language is part of the problem because it allows for things to turn into horrific balls of mud.
> The reason is that the “smart” people building the framework end up spiraling off into ivory tower land.
I don't think this is about smart vs. not smart. It's about different disciplines and abilities. Product developers should also be doing more (or all) product work and interacting with customers.
> They also become disconnected from customer reality.
Computer engineers who are creating a language and runtime should be servicing the specific domain of that the product. Part of the disconnect with DevOps is that it is solving for deploying general purpose tools rather than a specific domain. Have the computer engineers responsible for creating domain specific tools as well as deploying those domain specific tools and everyone should be more connected to the final outcome.
Yeah, the problem definitely is that people are able to write code that gets thing done, instead of being unable to perform their work.
Imagine if a language had A/B testing baked right into it. You define a couple of functions annotated for A/B testing and they are automatically A/B tested. Putting all of this inline with product functionality is generally what causes these balls of mud in the first place.
But no need to click, the entirely of the content (a bad HN comment) is in the title. No evidence or argument.
Wow, if only the owners and execs could realize this $100B idea to cut costs.
Being a part of the solution vs being the person who officially carries the solution across the finish line can be seen differently by observers. I think that's what Nat is oversimplifying.
Many of the companies I have worked at had management issues which prevented the existing tech staff from performing at optimal levels or even inhibited it.
Just one example of this is a startup which grew to a 1500 person company under the same CIO, and that CIO was comfortable with what had gotten them that far. Consequently, we had 65 engineers in silos, often strugging with the same problems and reinventing the same wheels.
Those of us who pushed for some platform level focus were politely listened to and then forgotten, presumably because new is scary and what has gotten them this far is "good enough".
However, at every monthly company meeting, they would promote the recruitment compensation bonuses because we "desperately" needed more tech staff. No, we didn't need more tech staff. We just needed the freedom to do things smarter.
At some other companies I've worked at, tech staff is an unfortunate necessity, a cost whose ability to enable the rest of the company and business itself was rarely recognized. If a tech employee left, management would intentionally drag its feet on replacing them (because it made budgets easier to maintain).
Granted, I haven't lived in the startup VC world where money magically appears within the right circles. There it would seem that proving to a VC that you are scaling up for big gains means you're growing your staff at a phenomenal pace. In those places, yeah I bet there are people who aren't necessary. I still bet there are management who aren't necessary or who are preventing some of those devs from doing useful things...
The OP contains nothing more than a dubious claim with no supporting evidence or insight, is not itself intellectually curious, and does little to spur interesting discussion. If the post was made by a less prominent person it wouldn’t even be on anyone’s radar to begin with.
Im not so sure I agree HN would be a better place if the front page was loaded with topics that were merely further amplifying the Twitter posts of famous people.
BTW, an underrated advantage of discussing tweets on HN is that the commenters will have read what they're commenting on.
Maybe every CEO isn't stupid. Maybe these companies were simply structuring their businesses to maximize their chances of capturing new growth opportunities in an environment of incredibly cheap capital. Most companies could hire 5 engineers who will completely transform their businesses. And they'll hire 50,000 in an effort to find those 5.
It's probably true you could run twitter with under 1,000 people. But it's probably not true that you can easily figure out who those 1,000 people are and get them to stay whilst you fire the other 6,500, and it's absolutely true that if the current CEO of twitter had tried that he would've got fired before he had a chance to pull it off. Go ask investors, do they want Twitter to reduce their ongoing costs significantly, with a significant chance it does long term damage to their growth plans, or do they want to grow revenue 30% YoY?
I think the problem is that at the scale of these companies, everyone is too stupid to effectively manage them.
If valuations continue their path towards coming in line with actual fundamentals, many companies will soon find they can’t afford the number of workers they have. Dilution will become quite severe at lower valuations