# Engineering payroll reduction: test 60% savings safely > Engineering payroll reduction can work, but founders should first model workload, reviews, on-call cover, and customer delivery risk. ## What a 60% payroll cut changes A 60% engineering payroll reduction changes more than a spreadsheet. If a company moves from ten engineers to four, those four people inherit work that used to be spread across the team: code review, incident response, releases, security updates, support questions, planning, and handoffs. Feature work is the visible part. A founder can look at a backlog and assume fewer people will finish fewer tickets. But work continues after a ticket looks done. Someone must review the change, test it, deploy it, watch alerts, answer customers when something breaks, and fix the problem. A smaller team can work when the company removes unnecessary work and uses AI with care. It breaks down when one engineer is expected to write, review, release, and support every change without delays or fatigue. Review capacity often tightens first, especially when risky changes need an independent reviewer. Customer commitments do not shrink with the team. The business may still need to meet a launch date, respond to a production outage, protect customer data, repair billing failures, and maintain integrations. Those obligations should define the limits of any payroll reduction. Test the operating model before changing roles. For a limited period, route planned work through the proposed smaller-team setup while current staffing remains available as a safety net. Track whether the trial team completes normal work, reviews changes on time, covers incidents, and meets customer deadlines. If it cannot, the company has found a constraint before making an irreversible cut. Oleg Sotnikov has used AI-augmented engineering to reduce team size while maintaining output and uptime. The starting point is still evidence, not a staffing target. A Team & AI Audit can turn that evidence into a cost target, staffing plan, and a safer test. ## Build a baseline from the last 90 days Start with the last 90 calendar days, not a planned sprint or an optimistic backlog. This period shows how the team spends time when production issues, customer requests, meetings, and unfinished work compete for attention. Create one cost sheet for everyone who touches engineering. Include salary, employer taxes, benefits, contractor invoices, management time, and agency fees. Record contractor hours as well as cost because even a part-time contractor affects review queues and on-call coverage. Keep recurring costs separate from temporary spending. A one-time recruiting fee, migration consultant, or laptop purchase can distort the picture. Focus first on monthly costs that continue after restructuring. Record delivered work in plain language: releases, customer fixes, production incidents, security work, internal maintenance, and support escalations. Ticket estimates help, but they often miss work that happens in chat, calls, and incident response. A useful baseline includes: - Monthly cost for each engineer, contractor, and engineering manager - Available hours, planned leave, and time away from project work - Shipped features and fixes, with release dates - Support requests and incidents that required engineering help - Work still open after 90 days and its customer impact Use calendar time to connect effort with outcomes. A feature estimated at five days may take three weeks because engineers wait for reviews, fix a production bug, and answer customer questions. That delay matters more than the original estimate when testing a smaller team. Ask managers to verify the sheet against payroll records, release notes, and incident logs. Do not rely on memory. A clean baseline gives founders a defensible starting point and shows what the remaining team must still cover. ## Map where engineering time goes Payroll plans fail when they treat every engineering hour as feature work. Pull data from tickets, calendars, incident notes, support requests, and release records. Group the work into a few clear categories: new features, bugs and support, infrastructure, meetings, and unplanned requests. Use actual time where possible. If a team logged 1,200 hours, do not assume 70% went to product work because that sounds plausible. A short sample may show that urgent customer fixes took 180 hours, deployment work took 90, and recurring meetings took 75. That changes the staffing decision. Give each item an owner, an estimated effort, and a reason it existed. Perfect accounting is unnecessary. You need a clear view of work that must continue after a reduction. Mark work that depends on one person. If only one engineer understands billing, production deployments, or a major customer integration, that risk will not appear in a payroll spreadsheet. Write down what they do, how often they do it, and who could take over after a short handoff. Repeating work deserves attention. Weekly release chores, recurring support fixes, and manual test steps can consume more time than founders expect. AI can reduce some of this load, but test the new process before removing the person who catches mistakes. For each recurring task, ask whether it supports revenue, an active customer commitment, a legal duty, or service reliability. Stop, pause, or simplify work with no clear reason. Record those choices so old tasks do not return through habit. ## Calculate review capacity before reducing headcount A smaller team can write code quickly and still miss release dates because nobody has time to review it. Reviews catch defects, spread system knowledge, and protect customers when changes affect money, personal data, or production infrastructure. Treat review work as planned workload. Use the last 90 days to count merged pull requests, review comments, and the time from opening a pull request to its first useful review. Separate small fixes from large changes. A team that merged 120 pull requests with a median first-review wait of four hours has a different workload from one with a two-day wait. Identify who can approve changes in areas where mistakes cost the most: - Security and access control - Payments, billing, and subscriptions - Customer data, backups, and database migrations - Cloud infrastructure, deployments, and incident fixes This often exposes hidden risk. If one engineer alone understands payment webhooks or production permissions, removing them does not create a safe payroll reduction. It moves a bottleneck into the remaining team. Set a queue limit before restructuring. For example, no more than five pull requests, or one business day of review work, should wait unreviewed. If the queue remains above that limit for two weeks, pause new feature commitments and find the cause. Oversized pull requests, unclear ownership, support work, and incidents can all slow reviews. Assign a primary and backup reviewer for every critical area. The backup should review real changes during the test. A paired review of an infrastructure change tells you more than a claim that someone knows the system. AI can draft tests, summarize changes, and spot obvious inconsistencies. It does not replace a person who understands the customer impact. Keep approvals for security, payments, and production access with named people. ## Plan on-call coverage with fewer people A smaller engineering team can support production safely only when its on-call plan matches the work that arrives. Review every alert, customer escalation, incident, and urgent manual task from the last 90 days. Include alerts that nobody acted on because they still interrupt the person on duty. For each event, record when it arrived, who responded, how long recovery took, and whether a person needed to act. A page at 2 a.m. that takes 15 minutes to close is different from a checkout outage that occupies an engineer for four hours. ### Assign ownership before an incident Every production system needs a named primary owner and a backup who can access its code, logs, deployment process, and runbook. "The team owns it" fails during an outage, especially after headcount drops. Keep the ownership list simple: - Name a primary and backup for each service, database, integration, and deployment pipeline. - State which alerts page someone immediately and which can wait until business hours. - Write short recovery steps for common failures, such as a failed deployment or expired credential. - Confirm that each owner can access monitoring, cloud, and support accounts. - Set an escalation path for incidents the on-call engineer cannot solve alone. AI can summarize logs or draft a fix, but an experienced person must decide whether to roll back a release or notify customers. ### Protect time off and customer commitments Put weekends, public holidays, and planned leave on the coverage calendar before restructuring. If two people cover production, neither has a real vacation if the other lacks backup. That is a staffing gap. Measure after-hours pages per person each month. Also track the median time to acknowledge and resolve serious incidents. If one engineer gets six overnight pages in a month, investigate alert rules and underlying failures before calling the arrangement sustainable. Set an escape rule for the test: pause it if coverage misses its response target, critical incidents repeat, or the remaining team cannot take planned leave. ## Run a protected savings test Do not reduce engineering payroll across the whole company at once. Choose one product area with steady work, limited customer impact, and a team that already knows the code. A billing rewrite or a launch promised to a major customer is a poor test case. Internal reporting, an admin workflow, or a small product module gives cleaner evidence. Freeze requests that do not support the pilot's agreed goal. New ideas, side tasks, and meeting work can hide the team's actual capacity. Tell product, sales, and support which requests will wait and who can approve a true exception. Write the trial setup on one page before changing roles. Name the people who build, review, release, and handle incidents. Name one person who resolves priority disputes. The plan should set the pilot scope for two or three delivery cycles, the proposed team size, daily responsibilities, service limits, baseline measures, and rollback triggers. Record completed work, defects, review wait time, and on-call load before the test starts. Run the smaller team as if the arrangement were permanent. Do not rescue it with hidden overtime from people whose roles you plan to remove. You need to see where queues form and whether AI-assisted coding reduces build time without creating more review work. Review results after each cycle. Compare planned work with completed work, track production issues, and ask support whether customer response changed. Fewer completed tickets can still be acceptable if the team delivered the highest-priority work with fewer defects. Repeated release delays or exhausted on-call staff mean the cut is too deep or the work split is wrong. Keep the rollback plan practical. Restore coverage for a named service, pause further role changes, or return the pilot area to its earlier staffing for one cycle. ## Measure delivery risk during the pilot A payroll reduction pilot needs operating limits, not only a savings target. Track results weekly against the 90-day baseline. A smaller team can close the same number of tickets while releases slip, customer bugs rise, or urgent support waits longer. Use a short scorecard covering release dates, customer-reported defects, production incidents, support response time, and work that reaches production versus work planned for the sprint. A late release is not always a failure. A late release that misses two customer commitments is a warning. Keep the record specific: list the feature, promised date, actual date, and reason for the gap. Ask the people who own customer relationships for a 60-day view of delivery promises. Sales may have committed an integration while an account manager needs a bug fix before renewal. Put those commitments beside the pilot plan. If the reduced team cannot cover them, adjust the workload or extend the test before changing headcount. Set pause limits in advance. Pause if a severity-one incident exceeds its agreed recovery time, support response exceeds its limit for two weeks, or two committed releases miss their dates. The founder and engineering lead should review exceptions together instead of asking the team to work nights to protect the numbers. ## Mistakes that make savings plans fail A payroll reduction fails when a spreadsheet assumes every engineering hour carries the same risk. Some work keeps customers online, some prevents security gaps, and some turns AI-generated changes into code the team can release safely. Treat review capacity as real capacity. AI can produce code quickly, but a senior engineer still needs to read it, test it, ask questions, and approve it. If the plan removes reviewers while increasing AI output, pull requests pile up or weak changes reach production. Do not cut people with production knowledge first. An engineer who knows why a payment retry job exists or how a customer deployment works may write fewer tickets than others. During an incident, that knowledge can save hours of outage time. Velocity charts tell only part of the story. A team can close many small tickets while postponing maintenance, incident follow-up, support work, and release checks. Review actual work from the last 90 days before using velocity to justify a smaller team. One senior engineer cannot cover every absence indefinitely. Illness, holidays, late-night incidents, and difficult releases overlap. Name a primary and backup owner for each production area, then test whether both can diagnose a realistic problem. Do not announce a restructuring before the pilot produces evidence. An early announcement can cause strong engineers to leave and turn a measured test into an emergency. ## A simple startup scenario A SaaS startup has eight engineers and a monthly engineering payroll of $120,000. Revenue is growing, but feature work takes longer than planned and support tickets interrupt the team. The founder wants to reduce payroll, but cutting five roles at once would put customer commitments at risk. The team separates its work into two areas. The billing dashboard has few defects, clear requirements, and repeatable changes such as report fields, permission updates, and email templates. A database migration for a large customer has a fixed deadline, touches account data, and needs fast recovery if it fails. The pilot uses the dashboard, not the migration. For six weeks, one AI-augmented engineer handles routine dashboard tickets. They use AI tools to draft code, tests, release notes, and documentation, then send every change to a senior peer for review. The peer approves production releases. A second experienced engineer keeps incident ownership for the whole product. The pilot engineer does not carry solo on-call duty until the team sees consistent code quality and understands where support is needed. The startup compares costs each week instead of counting merged tickets alone: payroll avoided or redeployed, senior review hours, AI tool costs, release lead time, defects, support volume, delayed revenue, and incident costs. Suppose the pilot suggests that two routine roles could be removed, saving $30,000 a month. But a delayed enterprise migration pushes back $20,000 in monthly subscription revenue, while extra support costs another $4,000. The apparent saving falls to $6,000. That may not justify restructuring yet. If dashboard work remains predictable, incidents do not rise, and senior review stays manageable, the founder has evidence for a narrower change. The migration team remains intact until the work finishes. It is slower than a blanket cut, but it protects commitments customers already paid for. ## Choose the next step from the evidence A pilot should end with a staffing decision, not a vague sense that the smaller team "seemed fine." Put the results beside the next quarter's committed work: customer deadlines, reliability work, security fixes, and product releases. Keep the current team if the pilot exposed missed reviews, delayed incident response, or specialist knowledge that still has no backup. Reduce in stages when the team has spare capacity but pressure rises around releases or on-call weeks. Move to the smaller model only when delivery, quality, and customer support remain stable for the full test period. Write the next-quarter plan in plain numbers. Name the roles or contractor hours you will retain, the work each person owns, the expected monthly payroll, and the conditions that pause another reduction. A startup may keep two engineers through a major customer launch, then reassess after four weeks of normal production traffic. AI-augmented teams need clear guardrails. Decide which code can move quickly with AI help, which changes require senior review, and who owns the response when an automated change causes an incident. A smaller team cannot safely absorb unlimited hidden work. If the numbers remain uncertain, Oleg Sotnikov's Team & AI Audit reviews workload, AI use, and staffing assumptions in five business days. The audit is designed to identify at least $50,000 a year in savings or it is free. Book a consultation through oleg.is if you need fractional CTO support before making a permanent staffing decision. The purpose of an engineering payroll reduction is to remove waste while keeping promises customers rely on. Let the evidence set the pace.