Team got cut. Scope didn’t.
When you are asked to "do more with less"
CEOs make "hard" decisions like letting people go. “Hard” in quotes because it’s not really hard for them.
The actually hard things? Dropping projects? Focusing? Getting rid of some customers?
That? No way.
Today’s article is brought to you by Korbit.ai
I used Cursor’s agent mode to write ~98% of our startup’s code (~60k lines and counting). A couple of weeks ago, they launched BugBot - an automatic code reviewer. I tried it and wasn’t impressed.
Then I realized it’s like reviewing your own code - you will probably just make the same mistakes you did originally.
Last week, the team at korbit.ai reached out and asked if I wanted to give their reviewer a try. So I ran a juicy PR through both.
➖ Corbit took a few minutes longer
✅ BUT, it left 11 comments - 2 of them caught real edge cases (vs 3 in BugBot)
I chatted with two of their devs, and loved the focus and vision. Here’s a 14-day free trial to try it out:
So what happens after the layoffs?
You are expected to “be a team player”, be more productive, work more. And if you don’t like it? You can go, it’s “Employer’s Market” right now. We’ll find someone else.
You used to work on two systems with five people. Then came two rounds of layoffs. You lose half the team. Your fellow EM is gone, and you inherit the leftovers from their team.
Congrats. You now support five systems with four people.
You’re expected to:
Add features to all five
Manage context switches
Continue with the same exact roadmap
And on top of it, you get messages like this from your PM: “I’ve built this feature in an hour in Lovable, can we add this to our app tomorrow”?
If you are in this situtation, you can either quit and find a better place (a valid choice), or try to make the best out of it.
For those choosing the 2nd option, there are 2 things I recommend to start with:
Start Showing the Cost
Start Mapping the New Reality
Start Showing the Cost
Non-engineers often think that building a feature is the hardest part of our jobs. It’s usually not.
The harder parts are:
Maintaining it
Supporting it
Keeping it fast, secure, and relevant without creating a spaghetti codebase
Every feature you say yes to adds permanent weight to your team. Even with zero tech debt (never happens), there’s a limit to how many moving parts a team can support and stay productive and sane. The more unrelated they are, the harder it is to support.
So when we are asked to develop a completely new project (like adding a chat somewhere it definitely doesn’t belong), we know that we need to push back and explain why it’s a bad idea. Still, most EMs find it VERY hard to explain this reality to business people.
The ‘Multi-Dimensional Tradeoffs’ article by Will Larson can really help you here.
In a nutshell:
Two-dimensional tradeoffs always disappoint someone
You can usually make a tradeoff that doesn’t disappoint anyone by introducing a new dimension
Here’s an example:
Project budgets – During annual planning, many companies struggle with intense debates about whether they invest into international expansion in new markets or do they instead prioritize their existing markets. By adding the dimension of fixed budgets, they can get varying degrees of both rather than debating existentially about doing one or the other.
Roadmap discussions are usually trapped on two axes:
What we build
How long will each item take
I’m not saying it will be easy, but if you can add the ‘Ongoing cost’ as a third dimension, it can really improve your life.
A good way to start is to map the current ongoing costs of the systems you are responsible for. This is not just tech debt - it can be bug fixes, urgent customer requests that were not a part of the roadmap, outages, and so on.
Let’s say you have 3 systems, and you find that ~10% of your team’s time is spent on maintaining each. So you have 70% free for ‘new’ product work.
Now, you can show the estimated increase of this ongoing cost, and let the other side make the decision. Sometimes, they will still want that new feature, and that’s ok - as long as they agree to the price.
Yeah, the numbers won’t be accurate, and they will fluctuate a lot, but your goal is not to be accurate, but to add the maintenance cost consideration to the table.
When you start to track those things, and bring in actual stories, it makes it easier to explain your point.
Here’s a great tip from Larson:
Go into each tradeoff discussion believing that there’s an additional dimension you can add that will greatly reduce the current tension in decision-making. Socialize this belief with others so they understand where you’re coming from, this can be as simple as a statement like, “I wonder if there’s a dimension we can add to this tradeoff to make it easier.”
Start Mapping the New Reality
We’ve all faced this dilemma:
Do we let the engineer1 who built app X finish the feature in 2 days, or give it to engineer2 who’ll take twice as long, just to share knowledge and mix things up?
In the “old” days, I really believed in the second option. My team of five had a single “team rep”:
One engineer who was on-call for issues
Also the point of contact for support
Reading alert channels, triaging problems
Every engineer knew ~70-80% of the systems, and could debug reasonably well most types of problems. This had so many advantages:
No dependency on a single person
Diverse work for people
Less on-call burden on the more tenured engineers
After a round of layoffs and the ‘joining’ with another team, most engineers were familiar with just 50% of the team’s responsibilities (at best).
We tried spreading the knowledge again, but "Everyone knows everything" became unsustainable.
In the new reality, three people who know a system became a privilege, and in most cases, we had to settle for two. In the smallest systems, even just one.
This is HARD on everyone. On-call becomes harder. Instead of one person being distracted per day, every problem goes straight to the most knowledgeable person.
Your job is to be aware of those new dynamics, prepare for them, and protect your people. In every department, the reality will look different, so I don’t have a magic tip here.
Talk to your manager about it, and make sure they are aware. It’s not just about working hours, it’s also about mental exhaustion for your senior people. What worked for me is giving people now and then ‘breather’ days, which are not deducted from their vacation days. Just a day to relax in the middle of the week.
Discover weekly
Build, Sell, Understand - a very interesting framework by
to navigate your startup career.4 Useful Japanese Concepts You Need to Know by
. A great article about Mottainai, Kaizen, Aimai, and Ikigai - most of it was new to me!Choosing the Right AI Code Review Tool: What Really Matters. With the increased number of systems to support, the quality of code reviews starts to slip. Fully depending on an LLM is madness (for now), but it can for sure help us in the process. (sponsored)
Finding a job as a product engineer by
- tactical advice that is relevant not only for ambitious developers, but also for EMs. I feel there is a strong overlap between an EM and a product engineer, in everything aside from the people management.
Thanks for bringing up 'Multi-Dimensional Trade-offs'.
I hadn’t heard of it before.