Reducing headcount is a common management tactic aimed at encouraging teams to focus on efficiency and eliminate non-essential efforts. It's often framed as a way to empower employees—but it comes with two critical pitfalls:
- Lack of Motivation – Team members frequently don't understand the underlying necessity for the reduction, which undermines their motivation to perform at their best.
- Unrecognized Performance Decline – Once all potential efficiencies have been extracted, further reductions begin to harm actual output—yet management often fails to acknowledge this impact.
While this method is widely used, I don't support it. There are more thoughtful and effective ways to enhance organizational efficiency without sacrificing morale or long-term performance.
I fully agree about the 'extra' cuts being much more harmful. Very often an initial 10% cut has barely any effect, but as you keep laying off people, it becomes much more painful.
- You (the engineers) are going to have to cover all the responsibilities
- We (top leadership) will keep the money of laid-off folks
That's an oversimplified picture.
I don't say this story isn't sometimes true. Sometimes. But...
As a person who let people go both for (under)performance and because of economic reasons, I can tell how easy it is to rationalize the situation from the perspective of an engineer (or a line manager).
I asked people to take over responsibilities. I asked people to do stuff that they didn't like. If there were a checklist in this layoffs meta-story, I'd check all the boxes.
And yet, I was never fooling myself that we'd magically do everything equally well. I was the first to visualize the work just to make the discussion about trade-offs more tangible.
After all, no matter how much pressure top leadership exercises, if the engineering work doesn't fit the work week, it won't fit the work week. It won't magically happen just because an important person wants so. And it's an extremely rare case that they really want to take over the line manager's job to show that it's doable (and yes, I have such a story, too; guess how it ended).
I've also had to let people go for both reasons, and I agree with almost everything you wrote.
I think in small startups, at least in my country, there are expectations (and even in the contract) to work more than the work week. That some things just 'need to be done'.
The smaller the team, the more such things fall on the same people.
Oh, there are whole industries built on hustle (I'm looking at you, game dev). And popular perceptions of startup culture aren't that far from the view.
Working with startups a lot, I've seen it too, on our clients' end. Working way beyond what people can sustain in the long run (psychologically and physically). I've seen engineers signing off, either because they decided to move on, or simply their bodies gave up. And I've seen founders making all sorts of low requests just to make their startups survive. One. More. Month.
If there's a pattern in all that, it's about organizational culture and—especially in small companies—founders' characters.
And that's probably a hint: if you choose to work in a startup, choose one where the leaders are decent human beings. When shit hits the fan, little beats a boss who actually cares about you as a fellow person.
Startups that grow for the sake of the ROI and the next investment cycle are 90% doomed, statistics are clear. Hustle is the normal mode, therefore, I need to know what I am signing for.
There are businesses that lock on getting clients, listening to them and delivering insane value by focusing the workforce capacity. Therefore I see 2 characteristics to watch for:
- What you said - look for founder decency
- I would add - see reluctance to dilute ownership too fast, and obsessive focus on the value delivery to their customers, rather than wide feature experimentation.
This will likely land you in a sane environment where you may learn how to later build something for yourself, while also building solid relationships.
I like the point about the reluctance for dilution.
That, however, would suggest that the benchmark should be bootstrapping. That's the ultimate non-dilution strategy. Thus, the closer we are to that reference point, the more decent business we can expect.
Of course, the standard disclaimer applies: it's correlation, and there are edge cases going against the pattern.
In fact, I would say that the EM has an obligation to illuminate the capacity allocation (which is directly translatable to cost). The "multi-dimensional" metaphor feels spot on! Will Larson is a fantastic systemiser from whom I've learnt a lot of insights. I've found that proactively reporting on the quarterly capacity distribution and discussing with senior management where they see the balance needs to go for the next quarter is a very eye-opening exercise for them (and for me).
On the "everybody knows everything" team - the nature of innovation is that one drives and creates. Naturally, the creator is the most knowledgeable about the resulting system (part). The question is, for how long? If we want a team that is resilient, we better achieve some familiarity with at least 1 more person for cutting the logistical risk in half, and perhaps the whole team over a few months. I called this "Champion, coach, let go" in short, as an ever-repeating pattern of strong initiative drivers aimed at sustainable and resilient teams.
Tough situation, Anton. With a reduced dev team, you'll face challenges in maintaining the same level of code quality and efficiency. Consider implementing automated testing and continuous integration to mitigate this. Also, reevaluate your architecture for scalability and sim...
We plan and track the effort for product maintenance separately. This ensures full transparency around the total workload and enables conscious decisions about resource allocation.
When capacity is tight, we rely on external support—but these external resources can be scaled back flexibly without resorting to layoffs.
Thanks for bringing up 'Multi-Dimensional Trade-offs'.
I hadn’t heard of it before.
I really loved that one! A great perspective :)
Yes, that’s a great perspective indeed! :)
Reducing headcount is a common management tactic aimed at encouraging teams to focus on efficiency and eliminate non-essential efforts. It's often framed as a way to empower employees—but it comes with two critical pitfalls:
- Lack of Motivation – Team members frequently don't understand the underlying necessity for the reduction, which undermines their motivation to perform at their best.
- Unrecognized Performance Decline – Once all potential efficiencies have been extracted, further reductions begin to harm actual output—yet management often fails to acknowledge this impact.
While this method is widely used, I don't support it. There are more thoughtful and effective ways to enhance organizational efficiency without sacrificing morale or long-term performance.
I fully agree about the 'extra' cuts being much more harmful. Very often an initial 10% cut has barely any effect, but as you keep laying off people, it becomes much more painful.
- We (top leadership) decided on layoffs
- You (the engineers) are going to have to cover all the responsibilities
- We (top leadership) will keep the money of laid-off folks
That's an oversimplified picture.
I don't say this story isn't sometimes true. Sometimes. But...
As a person who let people go both for (under)performance and because of economic reasons, I can tell how easy it is to rationalize the situation from the perspective of an engineer (or a line manager).
I asked people to take over responsibilities. I asked people to do stuff that they didn't like. If there were a checklist in this layoffs meta-story, I'd check all the boxes.
And yet, I was never fooling myself that we'd magically do everything equally well. I was the first to visualize the work just to make the discussion about trade-offs more tangible.
After all, no matter how much pressure top leadership exercises, if the engineering work doesn't fit the work week, it won't fit the work week. It won't magically happen just because an important person wants so. And it's an extremely rare case that they really want to take over the line manager's job to show that it's doable (and yes, I have such a story, too; guess how it ended).
It's definitely oversimplified, I agree.
I've also had to let people go for both reasons, and I agree with almost everything you wrote.
I think in small startups, at least in my country, there are expectations (and even in the contract) to work more than the work week. That some things just 'need to be done'.
The smaller the team, the more such things fall on the same people.
Oh, there are whole industries built on hustle (I'm looking at you, game dev). And popular perceptions of startup culture aren't that far from the view.
Working with startups a lot, I've seen it too, on our clients' end. Working way beyond what people can sustain in the long run (psychologically and physically). I've seen engineers signing off, either because they decided to move on, or simply their bodies gave up. And I've seen founders making all sorts of low requests just to make their startups survive. One. More. Month.
If there's a pattern in all that, it's about organizational culture and—especially in small companies—founders' characters.
And that's probably a hint: if you choose to work in a startup, choose one where the leaders are decent human beings. When shit hits the fan, little beats a boss who actually cares about you as a fellow person.
Startups that grow for the sake of the ROI and the next investment cycle are 90% doomed, statistics are clear. Hustle is the normal mode, therefore, I need to know what I am signing for.
There are businesses that lock on getting clients, listening to them and delivering insane value by focusing the workforce capacity. Therefore I see 2 characteristics to watch for:
- What you said - look for founder decency
- I would add - see reluctance to dilute ownership too fast, and obsessive focus on the value delivery to their customers, rather than wide feature experimentation.
This will likely land you in a sane environment where you may learn how to later build something for yourself, while also building solid relationships.
I like the point about the reluctance for dilution.
That, however, would suggest that the benchmark should be bootstrapping. That's the ultimate non-dilution strategy. Thus, the closer we are to that reference point, the more decent business we can expect.
Of course, the standard disclaimer applies: it's correlation, and there are edge cases going against the pattern.
If the above computes, it would be a supportive argument to a prediction that boostrapping as a strategy will be on a rise: https://pawelbrodzinski.substack.com/p/bootstrapping-the-new-black
In fact, I would say that the EM has an obligation to illuminate the capacity allocation (which is directly translatable to cost). The "multi-dimensional" metaphor feels spot on! Will Larson is a fantastic systemiser from whom I've learnt a lot of insights. I've found that proactively reporting on the quarterly capacity distribution and discussing with senior management where they see the balance needs to go for the next quarter is a very eye-opening exercise for them (and for me).
On the "everybody knows everything" team - the nature of innovation is that one drives and creates. Naturally, the creator is the most knowledgeable about the resulting system (part). The question is, for how long? If we want a team that is resilient, we better achieve some familiarity with at least 1 more person for cutting the logistical risk in half, and perhaps the whole team over a few months. I called this "Champion, coach, let go" in short, as an ever-repeating pattern of strong initiative drivers aimed at sustainable and resilient teams.
Loved the champion, coach, let go framework, sounds very healthy :)
Regarding the capacity - I agree, though I found it very hard to track it.
Tough situation, Anton. With a reduced dev team, you'll face challenges in maintaining the same level of code quality and efficiency. Consider implementing automated testing and continuous integration to mitigate this. Also, reevaluate your architecture for scalability and sim...
We plan and track the effort for product maintenance separately. This ensures full transparency around the total workload and enables conscious decisions about resource allocation.
When capacity is tight, we rely on external support—but these external resources can be scaled back flexibly without resorting to layoffs.