You have 1 article left to read this month before you need to register a free LeadDev.com account.
Estimated reading time: 6 minutes
Key takeaways:
- Sudden team cuts can hit hard. Capture knowledge before it walks out the door!
- Reassess team capacity vs. responsibilities, prioritize “keep the lights on” work, and align with stakeholders on what gets cut, delayed, or re-scoped.
- Plan for a smaller team (for a while). Explore internal staffing options and be mindful that team changes are costly and take time.
Experienced engineering managers know that their teams ebb and flow with time. No team truly stays the same forever. In the best case scenario, your team will grow in size with new hires, but what happens when you lose engineers and your team suddenly shrinks?
In the age of mass layoffs, acquisitions, and return-to-office mandates, many managers may find themselves in the strange situation of leading a team that suddenly, in the course of a day or a few weeks, is much smaller in size.
Having experienced the shrinking team phenomenon a couple of times over the past few years, there are a few steps you can take after you get the news that you’re losing engineers on your team.
Your inbox, upgraded.
Receive weekly engineering insights to level up your leadership approach.
1. Take advantage of offboarding time
If you’re lucky enough to get a heads up about your upcoming departure, then you’ve got something extremely valuable on your side: time. The time between when your engineer gives notice and their last day is usually filled with an array of offboarding tasks: completing paperwork for HR, removing access to certain software and systems, and perhaps scheduling exit interviews.
As a manager, this time is also your one opportunity to take stock of any historical knowledge, access, or specific context that will be walking out the door in a few weeks when this person leaves.
Perhaps this specific engineer has been leading a project or spent the last few months working in a niche area of the codebase. Having them document the context that lives in their head is a great way to codify that knowledge before they leave the company.
Similarly, if there are any unexpected knowledge silos, you can encourage pair programming and collaboration, which will help ease the process of finding a new owner for some of this information.
Another useful strategy is to have the departing team member note down any known areas of tech debt and maintenance. Perhaps they are aware of opportunities to refactor code or have previously spent some time researching the path to upgrade a framework or modernize a tool.
Capturing that in written format will ensure that the next person who tackles that problem won’t be starting from zero. Architecture diagrams and recorded learning sessions are other useful artifacts that can be generated in the last few weeks of someone’s tenure.
2. Rethink deadlines and deliverables
If you’re in the tricky situation of not having any advance notice about folks leaving your team, an unexpected layoff, for example, then instead of focusing on the offboarding period, you will be forced to turn your attention to the situation at hand.
There are two questions that are important to answer: what does your team look like now (i.e. who is left?), and what is this team currently responsible for? Depending on how many departures there were on the team, the delta between team size and team responsibilities is likely to be quite big.
For example, if your team of six engineers was previously balancing three projects, but the team has now been cut in half to just three engineers, you’ll need to make some decisions about the in-flight work and things queued up next on the roadmap.
Some of these decisions might be easy to make, while others may be tougher. For example, if your team is responsible for platform stability and maintenance, then keeping infrastructure and ops work on the team’s plate is probably an obvious, easy decision.
However, in order to carve out time for that work, you may need to de-prioritize some of the feature work that a product partner may have been advocating for, and deciding what to cut is harder. For example, if your team is shrinking in size significantly, you may find yourself in a situation where you are operating with a “keep the lights on” approach with a skeleton crew, with most of your product feature list cut as a result.
Thankfully, you don’t (and shouldn’t) need to make these decisions all by yourself. Effective stakeholder communication and management is a key part of the process. Having collaborative conversations with your product partners and engineering manager peers can be a helpful way to find a path forward and help you weigh the tradeoffs of what to cut and what to keep.
For example, if your team has less capacity now than it did before, sharing that context with stakeholders in an honest and candid way will help cushion the blow when you have to tell them no to something, or need to ask for more time or resources.
Similarly, there may be some processes and standards you’ll need to reevaluate with your smaller team. When our team shrunk in size, we needed to revisit our capacity for triaging and squashing bugs, and eventually ended up renegotiating our bug fix Service Level Agreement (SLA) to better mirror our team’s bandwidth.
Ultimately, you’ll need to whittle down the team’s priorities and responsibilities to a list that feels like the right mix of “ambitious but achievable” for your smaller team.
More like this
3. Don’t forget staffing
Depending on whether your engineering organization has the budget for it or not, you might be able to start the process of backfilling the engineers who left your team.
If your backfill role requests are approved, it’s important to be aware that hiring tends to be a long, arduous process, and even after closing a role, you’ll need to account for a bit of onboarding and ramp-up time. You’ll need to plan to operate with your smaller team for some time until that role is filled.
However, if the company is tight on cash or has just implemented a layoff, backfilling a role may not even be an option. If that’s the case, and you still find that your team needs extra hands on deck to help with an urgent priority, you can explore the option of soliciting help from within the organization to help your team meet their priorities.
For example, when I lost two backend engineers due to an impending acquisition and a likely layoff, I collaborated with my peer engineering managers and our director to assess whether it made sense to move a backend engineer from another team over onto ours. In this case, it did!.
We also discussed the possibility of fusing two teams together (in this case, we unanimously decided against this). Ultimately, it came down to a question of tradeoffs. As a group, we had to decide which project was the most important to the business and had the highest likelihood of being shipped the soonest. Then we were able to staff them accordingly.
Whatever you decide to do, remember that organizational changes are expensive. They can be disruptive to individuals and teams, and often don’t speed things up much since engineers need to onboard onto a new problem and gain context, which takes time. However, this can be a helpful lever to pull if you feel strongly enough about staffing up an initiative.
New York • September 15-16, 2026
Speakers Camille Fournier, Gergely Orosz and Will Larson confirmed 🙌
Navigating sudden team cuts
Whether you’re navigating an unexpected layoff or dealing with talent attrition at a smaller scale, it can be hard to watch folks on your team leave, even if you are happy for their successes.
If you’re fortunate enough to have those folks stay on for a few weeks, use that time wisely. Even if you have to say goodbye abruptly, if you can take some time to reprioritize, renegotiate, and reorganize, you’ll ease the transition for the people left behind and gracefully lead your team into its next iteration.
