# Engineering cost audit: evidence to collect in five days > Run an engineering cost audit in five days: collect delivery, toil, cloud, vendor, and review data before changing headcount or risking commitments. ## Why headcount cuts can break delivery promises Payroll is often the largest engineering expense, which makes headcount cuts look like the fastest way to reduce costs. But an org chart does not show who keeps a customer launch moving, reviews risky changes, or responds when production fails at 2 a.m. A rushed cut often shifts costs instead of removing them. Releases wait for review, senior engineers spend more time on support, and planned work slips. Customers get slower answers, which can hurt renewals and referrals. The apparent saving can disappear quickly. Protect active commitments first. These include contracted launch dates, reliability work for paying customers, security fixes, on-call coverage, and the review capacity needed to ship safely. Removing people assigned to this work without a replacement plan puts revenue at risk. Waste looks different. It can include duplicate subscriptions, cloud resources with no owner, weekly manual reports, or repetitive work that a small AI-assisted workflow can handle. These costs need evidence, not assumptions. A useful engineering cost audit asks what each person and recurring expense supports today. An engineer who spends ten hours a week copying data between tools may have work that can be reduced. An engineer who alone can approve changes for an enterprise customer's launch protects delivery. Those situations should not lead to the same decision. Before discussing headcount, collect a short evidence list: - Customer commitments, dates, and named owners - Work waiting in delivery, support, and review queues - On-call duties, incident history, and single-person dependencies - Repeated manual tasks and the hours they consume - Cloud, vendor, and software costs with a real owner The aim is not to protect every existing role. It is to separate waste from capacity that protects revenue and customer trust. Five focused days can give founders enough information to make staffing choices without gambling on a promised release. ## Set the audit boundary before collecting data An audit fails when the starting instruction is simply "find savings." That mixes urgent customer work, old contracts, experiments, and opinions into one spreadsheet. Set the boundary first so every number has a clear meaning. Name the products and internal systems under review. Include the teams that build, run, support, or approve work on them. List the contracts connected to that work: cloud accounts, monitoring tools, source control, contractors, software seats, and outsourced services. Leave costs from unrelated products out of the first pass. Use a period that reflects normal work. Eight to twelve recent weeks usually show more than one unusually busy month. Mark major outages, migrations, or seasonal sales peaks. They can explain a spike, but they should not define the team's normal operating cost. Write down commitments before anyone proposes a staffing change. These commitments set the limits for cost reductions: - Customer launch dates and contractual delivery dates - Support coverage, response targets, and on-call duties - Security, compliance, and reliability work with fixed deadlines - Revenue work promised to customers or partners - Projects another team cannot finish without engineering input A startup might find that two engineers spend much of their time on a low-revenue product. That may look like an easy cut. But if those engineers own an integration needed for a signed customer launch in three weeks, moving or removing them could cost more than it saves. Give each data source a named owner. Finance owns invoices and payroll figures. Engineering leaders own delivery queues, incident records, and staffing details. A cloud owner explains account charges. Product or sales confirms customer dates. One decision owner should resolve conflicts when sources disagree. Keep the scope in a short note that everyone can see. State what is included, what is excluded, the review dates, and commitments that cannot slip. This keeps an AI team audit grounded in evidence rather than turning it into an argument about people. ## Map delivery queues and customer commitments Start with promised work, not the org chart. Before reducing headcount or moving work into AI-assisted workflows, understand what the team must deliver over the next 30 to 90 days. Pull active backlog items, open incidents, support tickets, and the release calendar into one view. For each item, record the owner, status, target date, customer impact, and when it entered the queue. A ticket untouched for six weeks is different from one that has waited a day for a customer decision. Mark work tied to a paying customer, security issue, or contract date. Keep the marking simple. You need to separate work the company must protect from work that can wait, shrink, or stop. Group items into four practical categories: - Customer commitments with a fixed date or renewal risk - Security, reliability, and incident work - Revenue or product work without a fixed promise - Internal requests, experiments, and old backlog items Then inspect where work waits. A large queue before development can mean the team lacks capacity. A large queue after development often points to slow reviews, unclear requirements, delayed testing, or one person approving every release. Cutting builders will not fix an approval bottleneck. A company may see 40 open tickets and assume it needs every engineer. The audit could show that 18 wait for product clarification, nine wait for customer feedback, and seven wait for code review. Only six are ready for development. That changes the staffing discussion. Record the evidence, not just totals. Note the customer commitment, deadline, queue stage, blocker, and responsible person. This gives leaders a defensible list of work that needs coverage and exposes work that exists because nobody has decided to close it. ## Measure recurring toil and manual work A team can look expensive because engineers spend too much time on work that does not move the product forward. Before cutting roles, collect two weeks of real work records. Ask engineers to note repeated tasks, how often they occur, and roughly how long they take. Keep the record simple. "Fixed failed import, 45 minutes, three times this week" tells you more than a general complaint about interruptions. Include work outside planned tickets, because hidden costs often sit there. Separate planned maintenance from avoidable manual work. Scheduled dependency updates, security patches, capacity checks, and documented operating duties need owners. Removing the person responsible can create outages later. Avoidable toil repeats because a tool, workflow, or handoff creates unnecessary work. It often includes manual release steps, weekly customer reports, repeated spreadsheet corrections, unclear alerts, and support questions that a current guide could answer. Estimate weekly hours for each item and record the trigger. A team might spend six hours repairing failed imports, four hours preparing reports, and three hours helping with manual releases. That is 13 hours each week before planned work begins. Use conservative estimates. The point is not to automate every repeated task. Find work with a clear cost and a safe fix. A small script, better alert, or AI-assisted support workflow that removes five hours a week can protect delivery commitments without adding headcount. For every item, ask: "What happens if nobody does this for two weeks?" The answer separates customer protection from work that should be automated, moved to another function, or stopped. ## Trace cloud spend to products and owners A cloud bill without owners encourages bad cuts. Finance may see a large total, while an expensive database supports the product that keeps a major customer online. Assign each cost to a product, environment, and person who can explain why it exists. Start with simple labels: production, staging, development, internal tools, and experiments. Then group costs by product or customer where possible. If a shared service supports several products, record the split and name the person responsible for reviewing it. A cloud spend review often finds costs that no customer would notice if removed: - Development environments left running after a project ended - Instances sized for a traffic peak that passed months ago - Old snapshots, logs, and storage with no retention rule - Data-transfer charges caused by duplicate processing or a region change - Test databases and queues from abandoned experiments Compare the last three to six months of spending with release dates, traffic, and customer activity. A 40% increase after a product launch may be justified. The same increase with flat traffic needs an explanation. Ask the owner to connect each jump to a real event, such as a new customer, more requests, or a deployment that added duplicate processing. Do not treat every reduction as a win. Reducing staging capacity might save money but slow releases if the team cannot test realistic loads. Target waste that has no delivery or customer purpose. An old preview environment that costs $900 a month and has had no deployments in 60 days is worth reviewing. For each finding, record the monthly amount, owner, evidence, customer risk, and proposed action. That turns the audit into a list of decisions rather than a vague request to lower the cloud bill. ## Find vendor overlap and unused seats Software spending often hides in small monthly charges. A $25 seat seems harmless until teams buy similar tools, former staff keep licenses, and annual renewals arrive without a usage check. Build one subscription list for the engineering team. Include the tool name, owner, paid seats, active users, cost, renewal date, and the job the tool supports. Finance can provide card charges and invoices, while team leads confirm how each tool is actually used. Look for inactive accounts, overlapping products, duplicate monitoring services, and advanced plans used by only one person. A company may have ten licenses for a developer tool but only six recent users, or three documentation products that began during separate projects. Duplicate tools do not always equal waste. Support may need a separate system because it holds customer history or meets a contract requirement. Check the workflow first: who uses the tool, how often, what data it contains, and what would break if it disappeared. Review plan tiers as well as seat counts. Teams sometimes buy an advanced package for one feature used by one person. A smaller separate plan, or an existing tool, can cut the bill without a risky migration. Treat renewal dates as decision points. Cancel inactive seats before the renewal window, assign an owner to each remaining subscription, and review access when someone joins or leaves. This usually produces quick savings and reduces procurement and security clutter. Record the monthly saving, owner, renewal deadline, migration effort, and delivery risk for every proposed cut. That distinguishes safe reductions from changes that would create more work than they save. ## Check review capacity and bottlenecks A payroll sheet can make a team look overstaffed while delivery depends on two people approving almost every production change. Cutting a developer before checking review capacity can slow releases, encourage rushed approvals, and risk customer commitments. Use the last four to eight weeks of pull request data. Measure time from opening to first review, final approval, and merge. Separate small fixes from larger changes where possible. Requests waiting more than a day for review deserve attention when a release depends on them. Do not rely on averages alone. A team may report a six-hour average review time while a few requests wait three days because only one person can approve database, payment, or deployment changes. The slowest path can determine the release date. Identify who approves most production changes, which repositories have only one regular reviewer, and which decisions require a manager or senior engineer. Check what happens during meetings, holidays, and leave. Also look for missing rollback notes or review rules. A startup may have eight developers, but one staff engineer reviews every infrastructure change. Removing a lower-output engineer may achieve little if that person handles first-pass reviews and gives the staff engineer time for production work. The review queue then grows and releases slip. Repeated rework can point to a different problem. If reviewers return the same types of changes, the team may need clearer templates, automated checks, or shared system knowledge. AI can draft tests and catch simple issues before review, but an accountable person still needs to approve changes affecting customers, security, or costs. Mark every single-reviewer dependency before making a headcount decision. Keep enough review coverage for launches, on-call work, and ordinary absences. ## Follow a five-day evidence plan Keep the review tight: one product area, one engineering group, or one upcoming customer commitment. A narrow scope makes the data easier to check and avoids a debate about every tool the company owns. On day 1, name the owners for delivery, infrastructure, finance, and vendor contracts. List committed releases, support obligations, and deadlines for the next 60 to 90 days. Ask each owner for the same evidence and set a submission deadline. - **Day 1:** Define scope, commitments, owners, payroll costs, contractor terms, active projects, incident history, cloud invoices, and subscriptions. - **Days 2-3:** Collect queue data, examples of repeated manual work, cloud use by product or environment, and vendor seat counts. Use exports, tickets, invoices, and access logs. - **Day 4:** Test findings with team leads. An apparently unused subscription may support a scheduled launch. A slow review queue may reflect a temporary absence. - **Day 5:** Rank actions by savings, delivery risk, and effort. Label each one safe now, needs validation, or defer until after a customer commitment. A spreadsheet is evidence, not the final answer. Team leads can explain whether a test environment still matters or whether a contract's cancellation window changes the timing. Finish with a short action register. For each item, record the owner, expected annual saving, customer risk, start date, and proof needed after the change. Safe early actions often include removing inactive seats, shutting down abandoned environments, and reducing recurring manual checks with AI-assisted tooling. If the evidence points to broader team changes, keep them separate from immediate waste cuts. The staffing discussion needs its own plan for ownership, review coverage, and customer support. ## Protect a launch while cutting waste Consider a small SaaS company with a customer launch in four weeks. After a slow sales quarter, the founders want to reduce engineering costs. Cutting two engineers would threaten the date, so the team separates launch work from spending with little customer impact. The release plan shows that four engineers own launch features, defect fixes, integration testing, and production readiness. Their work stays protected. The company does not move them onto savings projects or burden them with new reporting. It finds savings elsewhere. Three unused staging environments still run overnight and on weekends. An engineer confirms that no active test or customer depends on them, then shuts them down. The company also removes inactive accounts for former contractors and consolidates overlapping project tracking, error monitoring, and design subscriptions. The team identifies recurring operations work as well. One engineer manually copies support reports into a spreadsheet, checks routine deployment status, and restarts a test service after scheduled jobs fail. The company gives that engineer two days to create scheduled reports, add failed-job alerts, and automate the safe restart. It does not spend two weeks rebuilding internal systems. The result is a practical decision list: pause environments with no active owner, remove inactive seats, retain people assigned to launch work, and automate routine checks with clear rules. Each action has a cost, owner, proof that it is safe, and expected saving. ## Avoid mistakes that distort the numbers The common error is treating activity as value. A team that closes 80 small tickets may contribute less to revenue or retention than one engineer who fixes a deployment risk before a major launch. Ticket counts also hide uneven work. One ticket may change a button label. Another may need a week of investigation, a security review, and a careful release. Read a sample alongside the customer commitment, expected result, and time spent. Do not remove the only person who can approve a release, run a deployment, or handle a production incident. These duties may take few hours in a normal week, so utilization reports can miss them. A single absence can still delay every release or turn a short outage into a long one. Before changing headcount, list who reviews production changes, has deployment access, understands each critical service, and knows customer escalation paths. Confirm backup coverage through a real handoff or supervised release. Include on-call load, incident history, and planned absences. Keep two audit columns: identified opportunity and confirmed saving. A canceled software seat saves nothing until an owner confirms it is unnecessary, the contract permits the reduction, and the renewal date is known. Cloud savings are real only after someone changes the workload, verifies customer impact, and sees the lower bill. AI can reduce repetitive implementation work, but it does not replace release approval, architecture judgment, or incident ownership. Know who will carry those duties on Monday morning before you cut a role. ## Turn evidence into next steps Put every finding in a short action list and score it by annual savings, customer risk, and effort. A $12,000 software contract with no active users should rank above a larger apparent saving that would slow a promised launch. Start with waste that does not change delivery ownership. Cancel idle cloud resources after the product owner confirms they are unnecessary. Remove duplicate seats. Replace a repetitive manual task only after the team documents the existing steps and tests the new workflow on a small job. A sensible order is to stop unowned spending, consolidate overlapping vendors, automate recurring work, and then consider moving work between people. Consider headcount changes last, with written ownership and support coverage. Assign one person to every action and set a verification date. "Cancel unused seats" is vague. "Finance cancels 18 inactive seats before renewal and confirms the next invoice drops by $4,320" can be checked. Keep customer commitments beside the savings plan. If a release needs two senior reviewers, do not remove either role until another reviewer has product knowledge and time available. Savings that create missed dates, slow incident response, or support backlogs cost more than they return. For an outside review, Oleg Sotnikov's Team & AI Audit costs $5,000 and takes five business days. It reviews team work, AI use, and operating costs, with a guarantee of at least $50,000 a year in identified savings or the audit is free. The result is a prioritized plan for what to stop, what to automate, who owns each change, and which customer commitments need protection.