# Engineering payroll by demand source shows where teams go

> Engineering payroll by demand source shows whether product work, support, sales promises, setup, maintenance, or incidents consume your team.

Engineering payroll is often discussed as a headcount problem. It is usually a demand problem first.

A founder sees six engineers, a growing payroll, and a roadmap that keeps slipping. The usual response is to ask whether the team needs more people, better estimates, or tighter execution. That skips the useful question: what is causing the work to arrive? If half the team's time comes from customer setup, sales exceptions, support escalations, and incidents, hiring another product engineer will not produce twice as much product.

Map twelve weeks of work by the business demand that started it. Classify every meaningful block of engineering time into product development, support, customer setup, sales requests, maintenance, or incidents. The result is not a productivity scorecard. It is an operating map that tells you what your engineering payroll actually buys.

## The request that started the work is the unit that matters

Classify work by demand source, not by ticket label, code repository, or technical activity. Engineers often write tickets such as "add webhook retries," "fix permissions," or "move data to a new region." Those descriptions tell you what changed. They do not tell you why the company paid to change it.

Consider three tickets that all alter authentication code:

- A planned account-management feature requested by the product team is product development.
- A configuration change needed to launch a signed customer is customer setup.
- An exception promised during a deal cycle is a sales request.

The code may share a module, reviewer, deployment, and test suite. The commercial meaning does not match. Treating all three as product work makes the roadmap look larger than it is and hides the cost of promises made elsewhere in the company.

This is the distinction teams blur most often: **technical destination is not demand source**. A task can land in the infrastructure backlog while sales caused it. It can look like a bug fix while a customer-specific setup caused it. It can sit under a product epic while support escalations forced it into the sprint.

Getting this wrong creates two bad decisions. First, leaders give product managers credit for work that came from somewhere else. Second, leaders approve more product headcount to absorb work created by sales, operations, or unreliable systems. The team gets larger, the same demands keep arriving, and the roadmap still loses.

Use six categories and keep their definitions narrow enough that two people can apply them consistently.

| Demand source | Put work here when | Do not put work here when |
|---|---|---|
| Product development | The company chose the work to improve the standard product for its intended market | A specific customer, sales promise, or live failure forced the priority |
| Support | A user problem required engineering investigation or intervention, but production service was still operating | The service was degraded or unavailable for users at large scale |
| Customer setup | Engineering work was needed to launch, configure, migrate, import, integrate, train, or adapt the product for a particular customer | The work became a reusable product capability chosen through normal product planning |
| Sales requests | A prospect, renewal, expansion, security review, proof of concept, or deal promise created the work | The request arrived after contract signature and belongs to implementation |
| Maintenance | The team planned work to keep software operable, secure, understandable, supported, or affordable | A live production failure triggered the work |
| Incidents | A production failure or serious degradation demanded urgent response, mitigation, recovery, or investigation | The work was planned reliability improvement without an active event |

These labels do not need to solve every philosophical argument. They need to expose a pattern that is presently invisible in your financial reports.

## Twelve weeks is long enough to catch the work that repeats

A twelve-week sample gives recurring demands enough time to show themselves without turning the exercise into an accounting program. One sprint can lie to you. A large launch can make product work look dominant. A broken integration can make support look permanent. A twelve-week window catches the second and third occurrence, which is where a one-off becomes a staffing model.

Do not wait for perfect time tracking. Most engineering organizations do not have it, and introducing detailed daily timesheets before you have a question worth answering will get you rehearsed compliance instead of useful evidence. Start with available records, then ask engineers to resolve the gaps while the period is still fresh.

Pull evidence from:

- issue tracker exports, including creation date, labels, reporter, parent issue, and completion date
- support escalations and account notes
- calendar entries for customer calls, deal calls, incident calls, and implementation sessions
- deployment records, incident channels, and postmortems
- payroll cost by engineer or team, including contractors if they do recurring engineering work

Create one row for each meaningful unit of work. A ticket often works, but it is not mandatory. A two-hour emergency call and its next-day patch should be one row if they belong to the same event. A large customer migration may need separate rows for discovery, data import, and integration work if different people performed them or if you need to see where the time went.

Use this starting sheet:

```text
week_start,engineer,work_item,source,requestor,customer_or_deal,hours,status,reason
2026-04-06,Maya,SCIM mapping change,customer setup,implementation,Northstar,11,done,contracted launch requirement
2026-04-06,Jon,Retry failed exports,support,support team,,5,done,three users blocked but service available
2026-04-13,Maya,Role templates,product development,product,,18,done,planned roadmap item
2026-04-13,Jon,Database failover,incident,on-call,,9,done,production write errors
2026-04-20,Rina,Security questionnaire evidence,sales requests,sales,Northstar,4,done,pre-contract review
2026-04-20,Rina,Dependency upgrade,maintenance,engineering,,7,done,supported version nearing end of support
```

The `reason` column does more work than most people expect. Require one plain sentence that explains why the work existed. "Needed it" is not a reason. "Prospect required evidence before signing" is a reason. "Customer could not import historical records with the standard format" is a reason. That sentence lets a reviewer correct classifications without reverse-engineering the code.

Do not invent decimal precision. If an engineer cannot separate three small tasks that happened on the same afternoon, record a rounded total and add a note. You are finding proportions and repeated causes, not billing a client by the minute.

## Product work needs protection from urgent but valid demands

Product development is work the company deliberately chooses to improve the standard offering. The phrase "standard offering" matters. A feature can serve many customers and still be customer-driven. If a signed customer forced the timing and the company would not have built it now otherwise, record the initial work under customer setup. You can later decide whether to turn it into a product feature.

This classification may feel unfair to the engineer who built a clean, reusable implementation. It is not a judgment about quality. It records who created the demand and whether the company could have said no.

Product work gets crowded out because the other categories arrive with people attached to them. A support escalation has a frustrated customer. Customer setup has an account manager waiting for launch. A sales request has a forecast and an executive message. An incident has alarms. Product work often has none of those things, only a plan.

If you do not protect planned capacity, the team will describe itself as busy while the product becomes a collection of interruptions. The payroll map makes that visible. If product development takes a small minority of work over twelve weeks, do not first ask why the team is slow. Ask who has permission to create engineering work outside the product plan.

Look for a pattern where product work begins each week and gets displaced by the same kinds of interruptions. That tells you the problem is not estimation. The company has built an intake system where urgency defeats selection.

A useful review question is: "Could we have declined this request without breaking a signed promise, violating an obligation, or leaving users unable to use the service?" If yes, the request belongs in a queue with an owner and a decision. It should not enter an engineer's direct messages as an implied command.

## Customer setup is a delivery cost, even when engineers call it onboarding

Customer setup includes the work required to get one customer live or keep that customer's implementation moving. Data imports, integration mapping, identity configuration, tenant changes, custom reports, migration scripts, access-model adjustments, and customer-specific training support all count when engineering must do them.

Founders regularly undercount this category because the labor appears in harmless places. An engineer joins a call "for fifteen minutes." A customer success manager asks for a small import script. An account manager needs a field added before a launch. A developer debugs an integration during a weekend handover. None of these look like a project in isolation. Together, they can consume the team meant to build the product.

The popular but wrong recommendation is to call all of this product feedback. The idea is attractive because it makes customer work sound strategic. Some of it is strategic. Much of it is implementation labor that the company has not priced, staffed, standardized, or limited.

Separate three cases:

1. **Standard setup:** the customer follows documented configuration and engineers do not intervene. This should be near zero engineering time.
2. **Repeatable assisted setup:** engineers or technical specialists use known scripts, mappings, and checks. This is a delivery operation that can be documented, assigned, and priced.
3. **Bespoke setup:** the customer needs unique code, data treatment, architecture decisions, or exceptions. This is paid implementation work or a product decision, not a free favor hidden in payroll.

A high customer-setup share does not prove that you need fewer engineers. It proves that the company needs an explicit choice. You may need a technical implementation function. You may need to make setup self-serve. You may need to refuse unsupported arrangements. You may decide the revenue justifies the work, but then price it as delivery rather than claiming it as product margin.

The worst version is an informal promise: sales says "our engineers can help," customer success assumes engineering will finish the details, and engineering discovers the request after the contract is signed. The expense lands in payroll, but nobody owns the decision.

## Sales requests need a price and an approval path

Sales requests are work created to win, retain, or expand revenue before the customer needs operational delivery. Security questionnaires, proof-of-concept environments, custom demonstrations, technical calls, architecture reviews, procurement evidence, feature commitments, and one-off prospect integrations belong here when a deal created the request.

Do not use this category to blame sales. Sales needs technical support, especially for complex products. The purpose is to put a cost beside a commercial choice. If a deal needs thirty engineering hours before signature, that is part of the deal's cost of acquisition. If renewals repeatedly trigger bespoke security evidence, that is a product packaging or compliance operations problem.

The map will often expose a common failure: an engineer receives a request through a sales channel, treats it as urgent because a deal is at risk, and does the work before anyone asks whether the contract value supports it. By the time the founder sees the cost, the answer has become theoretical. The work is already done.

Set a simple gate for requests that need more than a small amount of engineering time. The gate should answer five questions:

- What deal, renewal, or expansion created this request?
- Is there a signed obligation, or is this pre-contract work?
- Can sales answer with existing materials or a product demonstration?
- Will the work become part of the standard product or remain specific to this deal?
- Who approves the engineering cost and the customer commitment?

The gate is not bureaucracy for its own sake. It stops a salesperson, founder, or customer success manager from spending engineering capacity without seeing the tradeoff. If someone wants an engineer to create a proof of concept, they should be able to state what planned work will move.

Treat verbal feature promises as sales requests even when they later become product work. The initiating promise matters. Otherwise the company can promise enough future features to fill two quarters, then label the result a product roadmap.

## Maintenance is planned work, and incidents are the bill for skipped work

Maintenance is deliberate work that keeps the system supportable. Dependency upgrades, database tuning, test repairs, build cleanup, observability improvements, obsolete code removal, capacity planning, documented recovery exercises, and supported-version migrations fit here when the team schedules them before a live failure forces action.

An incident is different. It is an unplanned production failure or serious degradation that demands immediate attention. The incident category includes mitigation, communication, recovery, direct investigation, and the engineering follow-up needed to restore the service. It does not include every improvement discovered during the postmortem.

This boundary matters because a team can hide a dangerous pattern by classifying all reliability work as maintenance. If engineers spend Mondays cleaning up the effects of Saturday outages, that is incident cost. If they reserve a Thursday to replace a component before it fails, that is maintenance.

Use an incident record that preserves the connection between the live event and the labor it created:

```text
incident_id: INC-042
start: 2026-05-18 14:10 UTC
service effect: customers could not create new records
immediate cause: exhausted connection pool after traffic spike
response work: rollback, pool limit change, customer communication
hours charged to incident: 16
follow-up classified separately: load test and capacity alert
follow-up source: maintenance
```

The separate follow-up field prevents a familiar argument. One person says the load test is incident work because the outage revealed it. Another says it is maintenance because the team scheduled it later. Both descriptions are partly true. For payroll analysis, count the emergency response under incidents and the planned prevention under maintenance. Then you can see both the immediate cost of failure and the amount you invest to reduce recurrence.

Do not treat low incident hours as automatic proof of reliability. Teams sometimes avoid recording the hidden recovery work: manual corrections, customer explanations, temporary scripts, and long nights spent making a fragile workaround safe enough for business hours. The reason column needs to capture this.

A maintenance category that stays near zero while incidents recur is a warning. The company is asking engineers to repair damage without allocating time to remove the cause. That pattern burns out capable people because they know the same failure will return.

## Support work reveals where the product still needs an operator

Support work begins when a user problem reaches engineering but has not become a broad production incident. A user cannot complete an action, an integration returns unexpected data, a report is wrong, permissions do not behave as intended, or support needs an engineer to inspect internal state. The service may be available, but the customer cannot get the outcome they need.

Support is not automatically a defect bucket. Some support work comes from unclear product behavior, missing documentation, weak operational tooling, incorrect data, partner systems, or a configuration the customer controls. The map is useful because it exposes the engineering cost regardless of whose fault it is.

Classify the initial investigation under support. If the team later chooses a general fix, put that subsequent planned work under product development or maintenance based on why the company scheduled it. If the same support pattern happens often, do not quietly reclassify every occurrence as product work just because you hope to solve it someday.

The repeated shape matters more than a single ticket. For each support row, record a short failure mode such as:

- configuration confusion
- missing operator tool
- data repair
- product defect
- integration behavior

After twelve weeks, group support hours by failure mode. You may find that the largest cost is not a difficult bug. It may be a missing internal tool that forces engineers to inspect records manually, or an integration setup that support cannot diagnose without code access.

That is where a small product or operations investment can release real capacity. The answer is rarely "tell support to stop escalating." If support lacks the tools and authority to resolve a class of problem safely, the escalation is doing exactly what the system requires.

## Turn hours into payroll without pretending every hour costs the same

Start with hours because they reveal the demand pattern. Then translate those hours into fully loaded engineering payroll so the company can make budget choices.

For each engineer, calculate an hourly loaded cost using annual compensation, employer taxes, benefits, recurring equipment, and any predictable employment costs. If you use contractors, use their actual billed rate. Keep founders separate if you want to see cash payroll, but do not erase founder engineering time from the capacity view. Unpaid effort can still hide a broken operating model.

A simple calculation looks like this:

```text
loaded_hourly_cost = annual_loaded_cost / annual_work_hours
source_cost = hours_in_source * loaded_hourly_cost
```

You do not need to argue over whether annual work hours should be one exact number. Pick one documented assumption and use it for every employee in the report. The point is to compare categories on the same basis.

Suppose an engineer spent 42 hours on customer setup in the sample and their loaded hourly cost is $95. The mapped cost is $3,990. That number does not mean the customer should receive an invoice for exactly $3,990. It means the company can no longer say customer setup is free.

Roll up the data in two views. The first shows hours by source, which identifies where capacity went. The second shows cost by source, which shows where expensive specialist time went. A team with a wide pay range may find that senior engineers absorb sales requests and incidents while less expensive engineers handle planned work. That can be reasonable, but it should be intentional.

Do not turn this report into a contest between categories. Product development, maintenance, support, and customer work can all be legitimate uses of engineering time. The report asks whether the mix matches the company you believe you are running.

If you sell a scalable product but customer setup dominates payroll, either fix setup or admit that part of the business is services. If you claim reliability matters but maintenance barely appears, reserve time and protect it. If sales requests take a large share of senior capacity, change qualification and approval rules before hiring another engineer to absorb the consequence.

## A weekly review keeps the map honest without creating timesheet theater

Review classifications once a week with one engineering leader and the people who own product, sales, and customer delivery. Keep the meeting short. The goal is to resolve ambiguous rows while everyone remembers why work happened, not to defend personal effort.

Use these questions for each disputed item:

1. Who asked for this, or what event created it?
2. Could the company have deferred or declined it?
3. Did a particular customer or deal make the timing necessary?
4. Was production already failing or materially degraded?
5. If we see this again next month, who should own the decision before engineering starts?

The fifth question changes behavior. A classification report is backward-looking, but it should improve the next request. If three sales requests consumed a week, establish a sales engineering intake. If one customer launch required repeated code changes, add a launch-readiness review before the next contract. If incidents ate two sprints, assign maintenance capacity before the next roadmap commitment.

Do not make engineers carry the burden of proving every interruption was legitimate. The organization created the demand. Leaders need to decide whether to reduce it, price it, staff it differently, automate it, or accept it openly.

After the first twelve weeks, continue with a lighter monthly map. You do not need the same forensic detail forever. Repeat the full review when you change pricing, sales motion, onboarding, architecture, support model, or team size. Those are the moments when an old demand pattern can quietly become a new payroll problem.

If you want an outside review before adding headcount, Oleg's Team & AI Audit examines demand, workflow, and engineering cost over five business days, with a stated guarantee of at least $50,000 per year in identified savings or the audit is free. Bring the raw work map, not a polished story. The messy entries usually explain the payroll better than the roadmap does.