Shrink an engineering team without breaking the product

Why cutting people first backfires

When a company cuts engineers before it cuts work, the pressure shows up almost at once. The roadmap still expects releases. Customers still expect quick support. Production still needs the same care. The team gets smaller, but the job does not.

Most teams also carry more hidden ownership than they realize. One engineer knows the billing edge cases. Another handles deploys, incident cleanup, and the old service nobody wants to touch. Those gaps do not appear on an org chart. They show up during a production issue at 11 p.m.

The first signs are usually small. Bug triage slows down. Review queues get longer. Support tickets sit for days instead of hours. Customers notice. They may not know the team got smaller, but they can tell when simple problems linger for two sprints.

The roadmap becomes the next problem. Leaders often try to protect growth plans by asking the remaining engineers to do more with less. That usually means less testing, less documentation, weaker monitoring, and less maintenance. Those are the jobs that keep a product steady.

That is why strong technical leaders cut obligations before roles. Oleg Sotnikov has shown that a much leaner operation can keep near-perfect uptime, but only after changing how the work gets done: less waste, fewer tools, more automation, and tighter priorities. Headcount changes work better after the system can handle them.

If you remove people before you remove work, the same pattern appears again and again:

• Ownership gets blurry.
• Bug fixes slow down.
• Support response times stretch.
• The product feels less reliable.

Teams can get smaller and still work well. The order is what matters. Cut the load first, then decide how many people you still need.

Cut scope before roles

If you cut people while the product promise stays the same, the work does not disappear. It just lands on fewer shoulders. That is when response times slip, bugs stay open longer, and tired teams start making expensive mistakes.

The safer move is to reduce what the team is expected to build, support, and maintain. Freeze nice to have features first. A feature can look small on a roadmap and still create weeks of design, testing, support, documentation, and follow up fixes.

A simple filter helps. For every project or backlog item, ask:

• Does it bring in revenue or protect renewals?
• Does it keep the product reliable, secure, or compliant?
• Do enough active customers use it to justify the effort?
• Will someone notice quickly if we stop doing it?

If the answer is no, pause it.

This is usually the moment when teams get honest. Side projects with weak usage, half finished add-ons, internal rewrites, and custom requests for one loud customer often stay alive because nobody wants to say no. If the company needs to shrink an engineering team, those are the first things to stop.

Write the stop list down. Do not leave it as a vague agreement from one meeting. Product, support, sales, and leadership should all see the same plain language plan. For example: no new integrations this quarter, no redesign of the admin area, no support for old edge case workflows, no experiments that do not affect revenue or uptime.

That written list matters because people refill the roadmap by habit. Sales asks for one exception. Support keeps an old promise alive. A manager slips in a pet feature. Soon the smaller team is doing the same amount of work with fewer people.

Cutting scope feels less dramatic than cutting roles, but it does more to keep the product stable. Fewer active commitments give the remaining team room to protect the parts customers actually pay for.

Map the work that keeps the product alive

Before you remove a role, map the work that protects uptime, revenue, and customer trust. Most teams can list projects from memory. Far fewer can name the chores that keep the product running every week.

Start with owners. Releases, incidents, billing, and support need one person attached to each area. If two people "share" ownership, ask who makes the call when a release fails at 9 p.m. or payment errors start piling up.

Then list the recurring work by cadence. Daily tasks often include checking alerts, shipping fixes, replying to urgent support, and watching failed payments. Weekly work may include reviewing backups, rotating credentials, cleaning error queues, and checking infrastructure costs. Monthly work often covers invoice checks, restore tests, access reviews, and subscription renewals.

Do not treat every repeated task as necessary. Some work prevents outages or missed revenue. Some work exists only because nobody questioned it. Teams often keep status reports nobody reads, approval steps nobody needs, or manual checks that a script could finish in 30 seconds.

One person knowledge is the biggest risk on the page. One engineer knows the deploy script. One person understands the billing edge cases. One founder handles angry customers because nobody else has the context. Those are weak spots, especially before a team gets smaller.

A simple worksheet is enough. For each task, note one owner, one backup, how often it happens, what tool or document supports it, and what breaks if nobody does it. Then ask each person, "What would stop working if you were gone for two weeks?" Hidden work shows up fast.

If a task has no owner, no backup, and no written steps, the role behind it is not safe to cut.

Consolidate tools and simplify handoffs

If you need to shrink an engineering team, look at the tool stack before you touch the org chart. Small teams break when work lives in too many places and every task needs three people to move forward.

Tool overlap hides more than direct cost. It creates two sources of truth, duplicate alerts, extra logins, and more chances for work to stall.

Remove overlap

Start with tools that solve the same job. Many teams keep an issue tracker, a chat channel, a spreadsheet, and a project board for the same work. That feels safe, but it usually means nobody knows which one is current.

Keep one place to track work, one place to see alerts, one place for documents and runbooks, one build and deploy path, and one place to review incidents. The same rule applies to services. If two products both handle monitoring, error tracking, feature flags, or CI, pick one unless you have a real reason to keep both.

Fewer services mean fewer invoices, fewer integrations, and fewer handoffs. The gain is not only lower spend. The team also spends less time checking five dashboards before doing anything useful.

Remove waiting between teams

Most delays sit between tools and people, not inside the work itself. A developer finishes a change, then waits for a manual QA handoff, then waits for approval in chat, then waits for someone else to press deploy. That chain is fragile.

Cut approval steps that only prove a message got seen. Keep approvals for actual risk, like schema changes, security rules, or billing logic. For routine work, let tests, review rules, and deployment checks do the filtering.

Small changes help more than teams expect. If alerts go to one place, the on call person owns the first response, and the runbook sits next to the alert, the usual hunt across chat, email, and old docs disappears.

When tools and handoffs get simpler, one person can cover more ground without panic. That gives you room to cut roles later, if you still need to.

Raise automation before role cuts

Before you remove a role, make the repeat work smaller. Releases still have to go out. Backups still have to run. New people still need working environments. If those jobs live only in one person's head, the product gets fragile very quickly.

Start with the tasks people do every week. They are usually boring, predictable, and easy to turn into scripts. That makes them the safest place to add automation.

A small SaaS team often gets quick wins from a few basics:

• setup scripts for local environments and staging
• one command backups and restore checks
• rollback scripts for failed releases
• simple release gates for builds, migrations, and health checks

Tests should protect the user flows that hurt most when they break. Focus on signup, login, checkout, billing changes, password reset, and the first action a new user takes after onboarding. You do not need full coverage. Five dependable tests around money, access, and data help more than fifty flaky ones.

Release checks should catch the obvious mistakes before customers do. Block the deploy if the app does not build, if a migration fails, if a required secret is missing, or if the service fails a health check. These are plain checks, not fancy systems, but they stop a lot of self inflicted outages.

The same rule applies outside releases. Backups, rollbacks, and machine setup should all follow one pattern: one clear command, one expected result, and a short note that anyone on the team can follow. If only one engineer knows how to restore production data safely, you are not ready to cut that role.

Teams that move toward AI assisted operations usually start here. They automate code review, test generation, and routine checks before they reduce headcount. That order works because automation removes chores first. Then the smaller team can spend time on the work that still needs judgment.

A good test is simple: if one person disappears for two weeks, can the rest of the team still ship, recover, and support users without guessing?

Use a safer sequence

Rushing to cut roles first looks cheaper on a spreadsheet, but it often creates hidden work, slower releases, and more support tickets. If you need to shrink an engineering team, the order matters more than speed.

Start with scope and tools

In the first week, freeze new scope unless it protects revenue, security, or uptime. Then rank current work with a simple question: does this keep the product selling, running, or compliant? If not, pause it.

Most teams skip this. They keep old promises alive, carry unfinished features forward, and burn time on work that no longer matters.

Use the second week to clean up the stack. Many teams have two tools for tickets, two places for docs, and a messy handoff between product, engineering, and support. Merge what overlaps. Pick one place for tasks, one release path, and one clear incident flow.

That removes more than cost. It removes confusion, which is often the real source of delays.

Automate, then reassign ownership

In the third week, remove routine work before you remove people. Start with tests, deployments, alerts, and the support requests that show up every day. Even small automation helps. If a script saves 15 minutes on each deploy and the team deploys four times a week, that time adds up quickly.

Week four is about ownership. Move responsibilities on purpose, not by accident. Decide who owns releases, production issues, infrastructure, customer bugs, and the runbooks that explain how to handle them.

Update those runbooks while the current owners are still there. Then watch workload closely for at least another week. If one engineer starts carrying every alert, every deploy, and every urgent fix, the team is not ready for another cut.

Only after that should you decide whether role cuts still make sense. Sometimes they do. Sometimes better scope control, fewer tools, and more automation solve enough of the problem that you can avoid a deeper cut.

A simple example from a small SaaS team

A small SaaS company had 10 people on the product side: 5 engineers, 1 designer, 1 product manager, 2 support staff, and 1 engineering lead. Revenue was flat, so the founders wanted to cut costs quickly. Their first idea was simple and risky: remove two engineers and hope the rest could keep up.

They chose a safer order.

The first cut was not people. It was a mobile app that only a small group of customers still used. The web product did the same job, and the app kept pulling time away from the main product. Every release needed extra testing, extra bug fixes, and extra support notes. Once the team retired that app, they had fewer moving parts within a month.

Next, they cleaned up support. The company used two separate support tools, so customer issues bounced between inboxes and people missed context. They moved everything into one shared inbox with clear tags and ownership rules. Support got faster, and engineers spent less time chasing old threads.

After that, they fixed releases. Before this change, each deploy depended on a senior engineer manually checking the login flow, billing page, and account setup. The team added a small smoke test pack before every release. It did not cover everything, but it caught the obvious breakages that usually caused late night rollbacks.

Then they dealt with platform work. One engineer had quietly become the person who knew deployments, backups, alerts, and odd server fixes. That is a trap. The team wrote down the routine jobs, moved access into shared accounts, and gave another engineer a week of paired handoff time. A short runbook beat tribal knowledge.

By the time they reviewed headcount, the work had already changed:

• one product surface was gone
• support had one queue instead of two
• releases needed less manual checking
• platform work no longer lived in one person's head

At that point, they could remove a role with far less risk. The product stayed stable because the team reduced work before it reduced people.

Mistakes that lead to outages and churn

Teams rarely break a product with one dramatic cut. They usually do it with several bad calls at the same time.

One common mistake is removing the only person who understands billing, renewals, tax rules, or payment failures. Billing code can sit quietly for months, then fail in a way that stops revenue. Before anyone leaves, document the billing flow, move access into shared accounts, and have another engineer run real tests for refunds, plan changes, and failed payments.

Another mistake is keeping the old roadmap after staff cuts. A team of eight can carry work that a team of four cannot. When leaders keep the same dates, engineers rush, skip checks, and ship changes they have not tested well enough. Customers notice quickly.

Adding new tools during the same period makes things worse. A new ticket system, a new CI setup, or a new AI coding tool may sound helpful, but every change adds setup work and fresh failure points. During a staffing change, keep the stack boring.

On call coverage is another weak spot. Fewer people means each person carries more systems, more alerts, and more stress. If nobody practices rollbacks, a small release issue can turn into a long outage. Every release needs a clear rollback path, and at least two people need to know how to use it.

Support volume gets ignored too often after a launch. That is a mistake. A feature release that creates 200 extra tickets can bury a smaller team for weeks. Watch ticket count, first reply time, and the issues customers repeat most. If support starts climbing, slow down releases before churn follows.

These problems stack fast. Lose the billing owner, keep the old roadmap, add new tools, and skip rollback drills, and the product starts to wobble even if the codebase itself has not changed much.

Checks to run before removing a role

Before you remove a role, test the team during an ordinary week and during a bad one. A team may look fine when nothing breaks. The real test is a failed deploy, a spike in support tickets, or a restore from backup.

Look for proof, not confidence. "We think we can handle it" is not enough.

• Someone other than the departing person can run a real release, handle a small issue, and roll back a change if needed.
• Every customer facing system has one clear owner. That includes the app, billing, auth, email, monitoring, and any service that can wake customers up when it fails.
• Alerts, logs, and backups still work, and people check them. A silent alert channel is worse than no alert at all.
• Support can answer common problems without pulling an engineer into every ticket.
• The team has already carried the new workload for two to four weeks during a normal period with real traffic.

Watch for slow damage too. Lead time gets longer first. Then bugs sit longer. Then support starts saying, "Engineering will get back to you," because nobody owns the answer.

If any check feels shaky, wait. Cut more scope, automate one more recurring task, or document one more system. Removing a role should feel boring after the test period, not brave.

What to do next

Do not change the org chart first. Run the product as if the smaller team already exists, but keep everyone in place for 30 days. That trial shows you where the plan holds and where it breaks.

Start by freezing the work you already decided to cut. Remove low value projects from sprints, pause side requests, and narrow support promises if needed. During those 30 days, watch a short set of numbers every week: bug count and severity, support and incident response times, release pace and rollback rate, and signs of overload such as on call stress or blocked work.

Numbers alone are not enough. Ask the team where work still depends on one person, where handoffs take too long, and which manual steps still eat hours every week. A team can hit deadlines for two weeks and still be close to burnout.

If service quality drops, reverse the plan quickly. Put work back in scope only if customers truly need it, and restore coverage where the product starts to slip. Waiting too long usually costs more than changing course early.

An outside review can help because internal teams often normalize risky workarounds. This is the kind of practical review Oleg Sotnikov does through oleg.is: scope, tooling, automation, infrastructure, and team design before a company makes role cuts. That outside view is often more useful than another round of guesses inside the team.

The next move should be small and testable. Pick the reduced scope, run the 30 day trial, measure the strain, and only then decide whether role cuts still make sense.