Engineering payroll per shipped outcome: monthly scorecard

Why payroll alone does not explain engineering output

A payroll report shows what the team costs each month. It does not show what customers received for that money. Ten engineers can close 120 tickets and still ship little that customers can use, renew for, or pay more for.

Ticket counts hide too much. A two-hour button-text change counts the same as a week of work that puts a requested export feature into production. Tickets also miss meetings, failed handoffs, production fixes, and time spent helping support.

Use a "shipped outcome" instead: a piece of customer work that reaches production and works for real users. It might be a paid feature, a completed integration, a customer-requested workflow, or a fix that stops a serious problem. The definition does not need to be perfect. It needs to stay consistent month after month.

Planned work is only part of the payroll story. A team may plan six customer outcomes, then spend half the month fixing defects from the previous release, helping a large customer with an urgent setup issue, and waiting for approval. Payroll stays the same while the cost per completed outcome rises.

Engineering payroll per shipped outcome connects monthly payroll to work customers can actually receive. A scorecard should separate customer work from the effort that prevents delivery:

• Planned customer work released to production
• Rework caused by defects, missed requirements, or weak implementation
• Support work that pulls engineers away from planned delivery
• Release delays, including work that is finished but cannot reach users

Consider two teams with the same $100,000 monthly engineering payroll. Team A releases eight customer outcomes and spends little time on support. Team B releases four while engineers repair earlier work and unblock releases. The payroll totals match, but Team B pays about twice as much for each shipped result, before lost sales or customer frustration.

This view also makes hiring less emotional. If demand rises and the team ships steadily, another engineer may make sense. If rework and support consume a large share of payroll, hiring into the same habits only makes the problem more expensive.

Apply the same test to AI engineering tools. Do not judge a tool by the number of code suggestions it produces. Check whether it helps the team release more customer work, reduces repair time, or shortens release delays. At AppMaster.io, Oleg Sotnikov reduced operations from 25 people to two AI-augmented engineers while maintaining output and uptime. The measure was operating output, not the novelty of the tools.

A monthly scorecard turns these observations into evidence. It shows whether payroll pays for new customer value or for recovering time already lost.

Choose a simple definition of a shipped outcome

A shipped outcome is a completed piece of work that customers can use in production. It has passed normal checks, reached real users, and solves a clear problem. A task marked "done" in a tracker does not count if it still waits for review, release, or customer access.

Use one reporting month and one definition across the company. A small startup can usually use a calendar month. A team that releases weekly should still total its outcomes at month end.

Count outcomes, not story points, closed tickets, pull requests, or logged hours. Those measures describe effort. They do not tell a founder whether payroll produced something customers can use.

For a billing product, these might count as separate shipped outcomes:

• A customer can download invoices in the required format.
• An admin can set a spending limit for a team member.
• The app fixes a production error that blocked payment confirmation.
• Support staff can resolve a common account issue without engineering help.

Give every item a short description and a release date. A large feature can count as one outcome if customers receive it as one usable capability. Do not split it into design, API, interface, test, and deployment tickets. Those are steps toward the outcome.

Some work belongs on the scorecard even without a visible button or page. A production fix counts when it restores a blocked customer action. A security patch counts when it protects a customer-facing service. Internal work counts only when it changes a measurable customer or operating result, such as reducing a release process from two days to two hours.

Do not change the definition when a month looks bad. Counting smaller items in a slow month makes payroll per shipped outcome look cheaper without improving delivery. Keep the same rule for several months. If you revise it, document the change and restart comparisons from that point.

Use a practical test: could a customer, support agent, or salesperson describe what changed after the release? If not, record the work as maintenance, discovery, or unfinished delivery. It may still matter, but it should not inflate the outcome count.

Build the monthly payroll total

Start with the full cash cost of people who build, test, release, and maintain the product. Base salaries alone create a falsely tidy number. Use the cost that actually left the business that month.

Include gross salary, employer taxes, required benefits, bonuses paid that month, and overtime. Add contractor invoices for engineering, QA, delivery-related design, DevOps, and technical project management. Use paid amounts rather than annual estimates where possible.

An engineer on a $120,000 annual salary receives $10,000 in monthly salary. If employer taxes and benefits add $2,500, record $12,500. A contractor who billed $8,000 belongs in the same monthly total.

Apply one rule to shared roles

Some people split their time between engineering and other work. A CTO may spend half the month on product delivery and half on fundraising. A designer may support both marketing and the app. Assign part of each person's cost to engineering using a rule you can repeat.

Use a simple percentage based on a timesheet, calendar review, or a manager's documented estimate. Do not chase minute-level precision. Consistency makes monthly changes easier to interpret.

• Include 100% of dedicated engineering, QA, platform, and DevOps roles.
• Allocate split roles using the same stated percentage unless their work changes.
• Include temporary help when that person supports customer delivery or production work.
• Record the allocation rule beside the monthly total.

Keep software subscriptions out of payroll. Coding assistants, cloud services, error tracking, and project tools matter when assessing total engineering cost, but they are operating expenses. Track them separately. Mixing them into payroll makes a hiring decision hard to compare with an AI tool decision.

Add two context fields beneath the total: the average number of people who contributed to engineering and the working days in the month. A team of six with 19 working days because of holidays should not look less productive than the same team with 23 available days.

If two engineers join halfway through the month, record their partial cost and note the change in team size. The payroll-per-outcome figure will then explain a transition rather than create a mysterious spike.

Track the work that changes the cost

Payroll tells you what engineering cost. It does not tell you where the month went. Track work that reached customers, then separate the work that consumed time without creating a new outcome.

Start with every customer request released during the month. It can be a feature, a meaningful improvement, an integration, or a customer-requested fix. Give each item a short name, release date, and owner. If five small tasks form one customer-facing update, count one outcome.

Then record rework. Rework includes defects found after release, misunderstood requirements, and work rebuilt because the first version did not solve the stated problem. Record the engineering hours and the original request. A founder who sees that a billing update took 40 hours, followed by 18 hours of repair, has a clearer picture than one who only sees "billing shipped."

Put support load on the same scorecard. Count time engineers spend answering tickets, investigating incidents, helping sales with technical questions, or manually correcting customer data. Some support work is necessary. A rising support total can explain falling output even when payroll and headcount stay flat.

Log release delays as well. For each planned release that misses its date, record the planned date, actual date, delay in working days, and reason. Use plain categories such as unclear scope, dependency, defect, review backlog, or infrastructure issue. One difficult month does not define a team, but repeated patterns do.

A compact monthly record might include:

• 12 customer requests released
• 76 engineering hours of rework
• 54 engineering hours spent on support
• Four delayed releases totaling 19 working days
• Two delays caused by unclear requirements

These numbers give hiring and AI tools a fair test. If support and rework consume 130 hours each month, another feature developer may not remove the bottleneck. Better requirements, automated checks, or an AI-assisted support workflow may return more capacity first.

Keep categories stable for three months before drawing strong conclusions. Many teams find that an apparent delivery problem is really a support, quality, or planning problem.

Set up the scorecard

Use one monthly sheet and update it on the same day each month. Pull payroll from finance, completed work from the product tracker, and release dates from the deployment record. Stable definitions matter more than a complicated spreadsheet.

1. Add full monthly engineering payroll, including salaries, contractor invoices, employer costs, and the people managing engineering work. Leave out sales and general administration.
2. Count customer outcomes that reached production that month. Divide payroll by the outcome count to calculate engineering payroll per shipped outcome.
3. Ask engineers to tag time as new customer work, rework, support, internal maintenance, or other. Keep the categories broad enough to avoid arguments.
4. Calculate rework and support as percentages of total team time.
5. Record each release that missed its agreed date and the number of days late. A release moved from April 12 to April 22 is 10 days late.

Use percentages beside raw hours. If a five-person team spent 180 of 720 available hours on support, support load was 25%. Hours show the workload; percentages allow comparison when holidays or staffing change.

Add a previous-month column beside every measure. Use the same calculations each time:

• Monthly payroll per shipped outcome = total engineering payroll / completed outcomes
• Rework rate = rework hours / total team hours
• Support load = support hours / total team hours
• Release delay = total days late, with the number of delayed releases

A team with $90,000 in monthly engineering payroll that ships 15 outcomes spends $6,000 per outcome. If the prior month showed $5,000, do not rush to hire or blame the team. Check whether support rose, whether outcomes required repair, or whether fewer releases arrived on time.

Write one brief note beside each unusual change. "Two engineers spent nine days on a customer incident" explains a higher cost better than a red number. This startup engineering scorecard turns a payroll discussion into evidence about work, delays, and capacity.

A realistic monthly example

A six-person product team costs $90,000 in payroll for the month. Use loaded payroll where possible, including salary, contractor payments, payroll taxes, and benefits. For an initial pass, $90,000 works if the team uses the same method every month.

The team reports 12 completed customer outcomes. Eight are new or expanded customer requests. Four are fixes for defects customers encountered. Show both numbers. A fix closes work, but it does not create the same progress as a requested capability.

Support changed the month as well. Two engineers spent about one quarter of their time handling urgent tickets, checking production issues, and answering customer questions. That equals roughly half of one full-time engineer for the month. Support used about $7,500 of the $90,000 total.

A paid customer requested a release that did not finish before month end. Move that outcome into next month's count. Do not count work that is nearly ready. The customer waits, sales cannot close the request, and the next month begins with unfinished work.

The scorecard

The first figure, $7,500, gives a useful monthly baseline. The second often tells a clearer story. A team can ship many fixes and make its overall cost look lower while customers wait for planned work.

Add a short note beside the numbers: "One paid release moved to next month; support consumed half an engineer-month." Context prevents a poor reaction, such as hiring immediately because output fell or celebrating a low cost per outcome while defect work grows.

If the pattern continues for two or three months, investigate support and rework before adding headcount. An AI tool might reduce repetitive support investigation or speed up fixes, but the scorecard should show that those hours return to customer work.

Mistakes that distort the numbers

The common error is treating every closed ticket as a completed outcome. A ticket may close because someone answered a question, changed one word, or split a large request into smaller tasks. That does not mean a customer received a useful improvement.

Count work at the level a customer can notice: a released checkout fix, an approved integration, or a reporting feature users can access. Keep supporting tickets beneath that outcome for context, but do not let them inflate output.

Another problem appears when all releases carry the same weight. A two-minute copy edit should not count the same as a request that took three engineers six weeks and required extensive testing. You do not need a complicated points system. Add a simple size label, such as small, medium, or large, and compare outcomes within those groups.

Do not hide support and rework

Founders often track roadmap work and leave support outside the scorecard because it lacks a neat product label. That creates a flattering but false view of engineering capacity. If two engineers spend half the month resolving incidents, answering enterprise questions, and repairing old releases, include those hours and explain the source.

Treat rework the same way. If a feature returns because requirements changed, testing missed a defect, or a release caused an incident, record the effort against that outcome. Otherwise, its first delivery looks cheaper than it was.

A monthly split might look like this:

• 55% on new customer outcomes
• 20% on support and incident response
• 15% on rework after release
• 10% on internal maintenance

This split gives a founder a clearer reason for rising payroll per shipped outcome. Support load or weak release checks may be the cause, rather than slow coding.

Treat a bad number as a process clue

Do not use the scorecard to rank or blame individual engineers. A high cost per outcome often begins earlier: unclear priorities, late founder decisions, too many items in progress, brittle tests, or manual release steps. One developer may appear slow because they handle the hardest legacy area or carry most of the support duty.

Ask the team to explain unusual movement with evidence. If release delays doubled after a new integration, check approval time, test failures, and customer acceptance notes. Change one constraint, then watch the next month. Numbers should guide investigation and decisions about hiring or AI tools, not create a monthly blame ritual.

Quick checks before acting on the scorecard

A scorecard can look precise while missing much of the cost. Before changing hiring, cutting a tool, or shifting work to AI tools, spend ten minutes checking the inputs. A bad baseline leads to expensive decisions.

Include every person who spends meaningful time on engineering work: employees, contractors, part-time specialists, engineering managers who still code, and founders who regularly unblock releases. Include employer taxes, benefits, and contractor invoices when they apply. Leaving out a $6,000 monthly contractor makes cost per outcome look better than it is.

Only count work that reached production and was available to customers during that month. A feature that passed internal review but waited two weeks for release does not belong in the shipped total. The same rule applies to fixes, integrations, and customer requests.

Use these checks before discussing the numbers:

• Every engineering contributor appears in the monthly cost total.
• Each counted outcome has a production date and a customer-facing description.
• Rework has a visible label, owner, and reason, such as unclear scope or a production defect.
• Delay days compare the actual date with the original committed date, not a revised plan.
• The team can explain large month-to-month changes with evidence.

Pay close attention to rework because teams often hide it inside ordinary feature work. Ask owners to tag work that corrects an earlier delivery, even if it takes only a few hours. If a checkout update requires four follow-up fixes, those fixes belong in the original outcome cost.

Keep the first committed release date in the scorecard. Teams often move dates after a dependency slips and then report that the release arrived on time. Add a revised date for planning if needed, but retain the original date to show whether delays come from scope changes, staffing gaps, review queues, or technical issues.

Do not react to one unusual month. A large customer migration, holiday absences, or a delayed launch can distort the figure. Compare at least three months and read the notes beside the totals. If payroll stays flat while shipped outcomes rise and rework falls, the team is improving. If outcomes rise but support load and delayed releases rise too, the gain may not last.

When the figures remain unclear, a Team & AI Audit can separate a measurement problem from a delivery problem before you make a costly staffing decision.

Use the evidence for the next decision

A monthly scorecard should change a decision, not fill a spreadsheet. Start with the most expensive recurring pattern. If customer work repeatedly returns for fixes, identify the cause before adding people or buying more tools.

Rework often begins before anyone writes code. A founder gives a broad request, the team interprets it differently, and testing happens near release. Track where each rework item started: unclear request, design decision, coding defect, or missed test. Two months of data usually provides a better answer than a general feeling that the team is "slow."

Capacity is different. Compare the fully loaded monthly cost of a hire with work that genuinely waits because nobody has time to do it. Count blocked customer requests, delayed revenue work, and releases that cannot proceed. A long backlog alone does not prove you need another engineer.

Before hiring, state the constraint in one sentence. For example: "Two enterprise onboarding changes waited 18 days because our only backend engineer handled production support." That is a capacity problem you can price. If the scorecard instead shows 30% rework, hiring may simply increase the cost of rework.

Apply the same standard to AI engineering tools. Pick one narrow bottleneck, such as writing repetitive test cases, investigating support bugs, or preparing a release checklist. Record a baseline for a month, introduce the tool with clear ownership, then compare the next month. Watch completed outcomes, rework hours, support load, review time, and release delays. A tool that creates more review work than it saves does not earn its subscription.

Use this decision test:

• Fix requirements or testing when rework repeats around the same work.
• Hire when measured blocked work costs more than the role you plan to add.
• Keep an AI tool when it improves a named measure in the following month.
• Stop or change an experiment when results stay flat or quality drops.

The aim is not the lowest payroll. It is paying for work that reaches customers without returning as an avoidable problem. For an outside review, Oleg Sotnikov's Team & AI Audit examines engineering spend, workflow, and practical savings opportunities in five business days. The fixed price is $5,000, and the audit is free if it does not identify at least $50,000 a year in savings.