Engineering wait states and their payroll cost

Engineering payroll is visible in every budget. Engineering wait states usually are not, which is why founders tolerate them far longer than they should.

A developer who waits for a product answer, a review, production access, or a usable test environment still costs the same per hour. Worse, the unfinished work often holds up sales, onboarding, support fixes, experiments, and decisions that depend on a release. The payroll loss is easy to calculate. The delay loss takes more discipline, but it is often the larger number.

Most teams describe this as a productivity problem. That description is too soft. A wait state is an operating failure with an owner. If a founder is the only person allowed to make routine product choices, the founder owns that queue. If a senior engineer reviews code whenever they find time, that engineer owns the queue. If access requires a chain of informal messages, leadership owns the queue.

Wait states are paid idle time with a business consequence

An engineering wait state begins when someone has work they can reasonably continue, but an external dependency prevents the next meaningful action. The dependency might be a person, permission, system, decision, or missing fact.

That definition excludes normal engineering work. Investigating a hard bug, reading unfamiliar code, running tests, and reconsidering a bad approach are not wait states. They may be expensive, but they are part of the job. A wait state means the engineer cannot proceed because someone else has not done their part.

The distinction matters because teams often hide external delays inside phrases such as "research," "alignment," or "in progress." Those labels make a queue look like productive work. They also make the person waiting look responsible for a delay they cannot fix.

A practical classification has four buckets:

• Founder or product approvals: a decision waits for a founder, product owner, or customer-facing executive.
• Review queues: code, architecture, security, design, or release review waits for a qualified reviewer.
• Environment and access: missing credentials, test data, logs, deployment permission, accounts, or a working environment.
• Unclear requirements: the team lacks an accountable decision about scope, behavior, priority, or acceptance.

Use a fifth bucket, "other external dependency," only temporarily. If it becomes common, split it. A category that catches everything teaches you nothing.

The visible symptom is an engineer asking in chat, "Can someone take a look?" The actual cost starts earlier. Work fragments when someone leaves a task to find another task. Context rebuilds when the answer arrives. A release window moves. The engineer then has to remember why the decision mattered and whether the code around it changed.

This is why counting only fully idle hours understates the loss. Engineers can often pick up a second task while waiting, especially in a large codebase. That does not make the wait free. It creates parallel work, more half-finished branches, more coordination, and more opportunities for the second task to block too.

Separate blocked time from calendar time

Calendar time tells you how long an item took. Blocked time tells you why it took that long. You need both, but they answer different questions.

A pull request that waits 30 hours for review did not necessarily consume 30 paid engineering hours. The author may have moved to another task. But the 30-hour delay still affects when the work can merge, test, deploy, and reach a customer. It also adds a recovery cost when the author returns to it.

Track three fields for every material wait:

1. Blocked start: when the engineer could no longer make a meaningful forward change.
2. Blocked end: when the missing decision, review, access, or information arrived.
3. Blocked impact: which people and business events depended on that work.

Do not ask engineers to fill out a five-minute form every time they wait. That creates another queue. Add a lightweight blocked status to the tool where work already lives, then require a short reason and owner when the block survives beyond an agreed threshold. For many startup teams, a block that lasts through the next working day deserves an entry. Urgent work deserves one immediately.

The entry can be as small as this:

Work item: Billing retry rules
Blocked at: 2026-07-22 10:15
Category: Founder approval
Waiting on: Product founder
Question: Can retries continue after an account is marked past due?
People blocked: 1 engineer
Dependent event: Enterprise prospect needs confirmation before Friday demo
Unblocked at: 2026-07-23 14:40

That record does two useful things. It separates a specific unanswered question from a vague complaint about communication. It also makes the owner visible without turning the process into a blame ritual.

A common objection is that teams cannot record every interruption. They should not. Record waits that alter planned work, delay a release, force a task switch, or block more than one person. The aim is to expose repeatable sources of delay, not to produce a perfect time-and-motion study.

Treat short, repeated waits seriously. Fifteen minutes of daily access chasing feels too small to report. Across four engineers and a month, it becomes a recurring loss and a signal that the access model is broken. People ignore it because each incident looks harmless by itself.

Put a payroll price on the wait before arguing about revenue

Start with the cost you can defend without making speculative revenue claims: loaded payroll cost for the people prevented from doing planned work.

Use this formula:

Direct wait cost = blocked person-hours × loaded hourly cost × displacement factor

Loaded hourly cost includes salary, payroll taxes, benefits, equipment, software, management overhead, and any contractor margin. If you do not have an exact internal figure, use a conservative estimate approved by finance. Precision theater is worse than a reasonable assumption written in plain sight.

The displacement factor handles the fact that a blocked engineer may switch to other work. Use 1.0 when the wait prevents useful work, such as a production incident where the only qualified engineer lacks access. Use a lower factor when the engineer can progress elsewhere, but still must rebuild context later. A team might use 0.4 or 0.5 for normal review waits, then revisit that assumption after looking at actual patterns.

For example, assume an engineer has a loaded internal cost of $150 per hour. A four-hour hard block costs $600 before you count delayed revenue, missed learning, or the extra coordination it causes. If the engineer spends two hours on unrelated work and loses momentum, a displacement factor of 0.5 puts the direct cost at $300. That is still not free.

Do not turn this into a fake invoice to individuals. The number is a decision aid. It gives leadership a way to compare the cost of fixing a workflow against the cost of living with it.

An approval process that saves a founder 20 minutes but causes four engineers to wait half a day has failed its own economics. The founder may be protecting quality, but the company should test whether a clear decision boundary, a product principle, or a delegated owner would protect quality at lower cost.

Keep the first calculation narrow. Use only documented blocked time and a transparent hourly cost. Once people trust the direct number, add business consequences with separate assumptions rather than burying them in the same formula.

Founder approvals need decision boundaries, not faster chasing

Founder approval is expensive when it becomes the default route for decisions that a team could make from written principles. Founders often create this queue accidentally. Early in a company, the founder knows the customers, remembers every compromise, and can make a call in two minutes. The company grows, but the decision pattern does not.

The result is familiar: an engineer posts a question, a founder is in meetings or selling, the question waits, and the engineer either guesses or starts another task. By the time the founder responds, the underlying context has changed. The answer now starts a second round of clarification.

The fix is not demanding that the founder reply faster to every message. That simply turns the founder into a more efficient bottleneck. Define which decisions require founder judgment and which ones do not.

A useful decision note has five parts:

• The decision being made in one sentence.
• The person who can decide it without escalation.
• The customer or business principle that constrains the choice.
• The default choice if no response arrives by a stated time.
• The cases that do require escalation.

For a billing product, the rule might say that an engineer and product lead can choose error wording and retry timing within existing pricing policy. The founder decides changes that affect contract terms, account suspension, or a promised enterprise behavior. That is specific enough to act on and narrow enough to respect the founder's role.

The default matters. Without one, silence means stop. With one, silence means the team takes a known, reversible path and records it. Some founders resist defaults because they fear bad decisions. That fear is reasonable when decisions are irreversible. It is wasteful when the choice is a reversible interface detail, a logging field, or an experiment that can be rolled back.

Track approval age separately from approval volume. A founder who approves 50 decisions quickly is not the issue. A founder who leaves five decisions unresolved for three days may hold up a material share of the roadmap.

Code review queues punish small teams twice

A review queue delays the author, but it also consumes the reviewer at the wrong time. The author has moved on and must reconstruct the change. The reviewer sees a larger diff, less fresh context, and more unrelated commits around it. Both people pay for the wait.

Measure review work with four timestamps: pull request opened, marked ready, first substantive review, and merged. The gap from ready to first substantive review is the review queue. A thumbs-up from someone who did not read the change is not a substantive review. Neither is an automated status message.

Teams often focus on review duration because it is visible. The queue is usually the bigger problem. A reviewer can finish a thoughtful review in 20 minutes, yet the author may wait two days for that 20 minutes to happen.

Do not respond by setting a simplistic rule that every pull request must receive a review within an hour. That creates interruption pressure and shallow review. Instead, establish a review service level based on work type. Production fixes may need immediate attention. Normal changes may need a same-working-day first response. Larger design changes should enter a scheduled review slot before anyone writes hundreds of lines around an unresolved choice.

The popular recommendation to require two reviewers on every change also deserves pushback. It feels safe because more eyes sound safer. On a small team, blanket double review often creates a queue with little risk reduction, especially for low-impact changes covered by tests and a clear rollback path. Match review depth to risk:

• Require deeper review for permissions, money movement, data deletion, and public API changes.
• Use one qualified reviewer for ordinary code changes.
• Let ownership rules route changes to people who can actually assess them.
• Keep changes small enough that a reviewer can understand the intent in one sitting.

A review queue also exposes a staffing truth that teams avoid: if one person must review everything, that person is a single point of failure. AI can help draft tests, summarize a diff, and identify obvious omissions, but it cannot grant accountability to a reviewer who has no time or system knowledge. Fix ownership and scheduling first.

Environment access is delivery capacity, not administration

If an engineer cannot inspect a log, reproduce a customer issue, use a test account, or deploy an approved change, the company does not have the capacity it thinks it has. Calling this an IT ticket does not alter the delivery effect.

Access work creates especially ugly waits because it crosses teams. The engineer asks a manager, the manager asks security or operations, someone discovers an outdated group, and the request may be delayed further because nobody can explain the actual permission needed. Meanwhile, the engineer starts guessing.

The answer is not broad permanent access for everyone. That trades delivery delay for avoidable security exposure. Build role-based paths that match real work, then make the common paths fast.

For each environment, define:

Role: Application engineer on incident rotation
Can read: service logs, traces, error reports, sanitized production records
Can change: feature flags and approved deployment settings
Cannot change: customer billing records, user roles, raw secret values
Access duration: expires after incident rotation unless renewed
Approval owner: engineering operations lead

This artifact forces the right conversation. It distinguishes observation from mutation, and operational need from convenience. Teams often grant too much access because the request process is so slow that every exception feels justified. A faster, narrower path reduces both problems.

Measure access wait from the first request that contains enough information to act on. Do not start the clock after three rounds of clarification; those rounds are part of the failure. Then identify the most frequent request types. If engineers routinely need a particular log or test account, the request should become self-service within a controlled role.

Environment reliability belongs in the same report. A test environment that fails every few days may not appear as an access issue, but it produces the same pattern: engineers wait, switch tasks, and return later with less context. Record the failure cause, duration, and people affected. "Staging was broken" is too vague to fix.

Unclear requirements are expensive because the work keeps moving

An unclear requirement does not always stop an engineer immediately. That makes it more dangerous than a missing approval. Engineers often build the obvious parts, make reasonable assumptions, and discover days later that the missing answer changes the architecture, data model, or customer flow.

The expensive version of ambiguity is not "the ticket could use more detail." It is an unanswered choice with consequences. Who can perform the action? What happens when the request fails halfway through? Does the customer see an error, a pending state, or an automatic retry? Which existing behavior wins when two rules conflict?

Write requirements around decisions and observable outcomes. A concise delivery note should contain the problem, the intended user behavior, the acceptance test, the owner for unresolved choices, and explicit non-goals. It does not need a page of prose if the decision is small.

Consider a request: "Add retry support for failed payments." That statement sounds clear until implementation starts. Does retry happen automatically? How many attempts? What notices does the customer receive? Can a user retry manually? What happens to account status during the retry window? Which failures should never retry?

A team that starts coding before those answers exist has not moved faster. It has moved uncertainty into code, where it costs more to expose and reverse.

Use a requirement block when ambiguity has delivery consequences:

Outcome: The system retries temporary payment failures automatically.
Owner: Product lead
Acceptance test: A temporary provider failure creates a visible pending state and retries under the documented policy.
Decision still open: Whether past-due accounts keep full access during the retry window.
Default by Thursday 3:00 PM: Keep access, log the exception, and flag the account for support review.
Non-goal: Changing plan pricing or collection policy.

The default is not a substitute for product judgment. It keeps ordinary uncertainty from becoming silent engineering idle time. If the open decision affects legal commitments, money movement, privacy, or a hard-to-reverse data change, stop and escalate. Teams need judgment here, not a blanket rule.

Compare delay cost with payroll cost without lying to yourself

Payroll cost answers, "What are we paying for the team?" Delay cost answers, "What does the team fail to deliver because work waits?" A useful operating review shows both numbers side by side without pretending either is exact to the dollar.

Use a monthly table with direct wait cost first, then business effect that you can tie to a specific event.

The dollar figures in this example assume different loaded hourly costs for the people involved. Your table should show the rate source and displacement factor behind each category. If finance challenges a number, that is useful. Refine the assumption instead of arguing from intuition.

Now compare the direct wait cost with the payroll you are trying to optimize. Suppose a five-person product team costs $1.2 million annually when fully loaded. If documented external waits produce $15,000 per month in conservative direct cost, that is $180,000 annually before business delay. The team does not need a sixth engineer to recover that capacity. It may need clearer delegation, review coverage, and access paths.

This comparison changes hiring decisions. A founder may conclude that engineering is slow and approve another hire. If the existing team spends a material part of its time waiting on the same two people, the hire joins the same queues. Payroll rises while throughput barely moves.

It also changes AI conversations. An AI coding tool can reduce time spent writing routine code. It cannot answer a founder's unanswered product decision, review a security-sensitive change with accountable judgment, or grant a production role. Use AI to shorten active work, then remove the waits that keep active work from starting.

Run a two-week wait-state audit before changing headcount

You do not need a six-month transformation program to find the obvious losses. Run a two-week audit over current work, then use the evidence to change one or two operating rules.

Start by selecting a scope that includes customer-facing delivery, production support, and normal engineering work. Assign one person to review the records at the end of each day. That person should ask for missing timestamps, not decide whether someone's wait was legitimate.

At the end of the two weeks, sort waits by total blocked hours, age, frequency, and number of people affected. One long incident may matter, but recurring one-hour approvals may deserve the first fix because they will return next month.

Then choose changes that have named owners and observable outcomes. Examples include delegating a class of product decisions, setting review coverage for each working day, creating a pre-approved incident access role, or requiring acceptance tests before a ticket enters active development.

Do not create a new committee to oversee every blocked item. The audit should remove decision layers, not add them. If the remedy requires three approvals to make an approval faster, stop and redesign it.

A Team & AI Audit can put this evidence into a broader view of staffing, delivery flow, and AI-assisted engineering work. The useful output is a costed list of constraints and the operating changes that remove them, not a generic productivity score.

Your next budget conversation should include one question beside payroll: where did the team wait last month, who owned each queue, and what did that waiting delay? If nobody can answer, do not assume the cost is small. Assume you have not measured it yet.