Your engineering headcount floor is higher than feature planning says

Feature planning produces a flattering staffing number because it counts the work everyone can see. A SaaS business needs engineers for the work customers experience when nothing is being announced: keeping production safe, getting implementations over the line, answering hard security questions, reviewing changes, and repairing the same weak spot before it pages someone again.

That is why the engineering headcount floor is usually higher than the roadmap estimate. It is the smallest team that can carry the business you already sold without borrowing time from reviews, sleep, incident follow-up, or the next quarter's product work.

A floor is not a hiring plan and it is not an org chart. It is a constraint. If your present team sits below it, one of three things must change: scope, customer commitments, or headcount. Founders often try a fourth option, asking people to work harder. That option hides the shortage for a few months and then sends the bill through churn, security gaps, delayed releases, or resignations.

The floor is an operating constraint, not a feature estimate

Your staffing floor is the larger of two numbers: the annual workload your company creates and the minimum number of qualified people required to operate it safely. Both matter.

Annual workload asks a simple question: how many engineer hours will the business consume over the next twelve months? It includes delivery, customer work, operations, security work, and review. Divide that by usable annual capacity per engineer and you have a workload number.

The coverage number catches a different failure. A team may have only enough incidents to consume a fraction of one engineer's time, yet still need several people who can take a primary rotation, approve a production change, and recover a service without calling the only person who understands it. You cannot solve that with a spreadsheet division.

Use this formula as the first pass:

workload FTE = CEILING(total annual engineering hours / usable hours per engineer)
engineering headcount floor = MAX(workload FTE, coverage minimum)

Do not put every working hour into the denominator. Start with 2,080 annual hours for a full-time employee, then subtract the time your company actually spends on holidays, vacation, company meetings, hiring, one-to-ones, planning, incident interruption, and internal support. The remaining number is usable capacity. For many small SaaS teams, 1,250 to 1,450 usable hours is a more honest planning input than 2,080, but use your own calendar and time data rather than adopting a number because it looks efficient.

The distinction matters. A founder can say, "We need 2.4 engineers of work," then decide that two engineers will handle it. That is a staffing decision. If the same two engineers also form the entire production rotation and each owns irreplaceable areas of the product, it is a risky decision, regardless of the decimal.

The worksheet in this article separates these two ideas so you can see where the shortage comes from. Do not start by debating titles. First make the work visible.

Build the worksheet around work that can interrupt shipping

Create one spreadsheet with five workload tabs and one summary tab. The tabs are product domains, customer implementations, production and on-call, compliance and security, and review capacity. Give every row an owner, an annual hour estimate, and a confidence note. A blank row is better than a fake precise number.

On the summary tab, use these fields:

Input: usable annual hours per engineer                    1,350
Input: planned product domain hours                         [sum]
Input: customer implementation hours                        [sum]
Input: production and on-call active work                   [sum]
Input: compliance and security work                         [sum]
Input: review and release capacity                          [sum]

Total annual engineering hours = SUM(all five categories)
Workload FTE = CEILING(total annual engineering hours / usable annual hours)
Coverage minimum = [qualified people required]
Headcount floor = MAX(workload FTE, coverage minimum)

Use hours rather than story points. Story points can help a delivery team discuss uncertainty, but they cannot compare a customer data migration with a weekend incident or an evidence request from an enterprise prospect. You need one unit for this calculation.

Estimate in ranges when the work varies. For example, a standard implementation may take 18 to 30 hours while a customer that requires identity integration, historical data import, and bespoke reporting may take 70 to 120. Put the expected mix into the sheet. If you sell twelve standard implementations and four complex ones, the annual estimate should show both assumptions.

Do not use last quarter's engineering time as your only forecast. It may include heroic effort that nobody wrote down, or it may omit work deferred until the next audit, renewal, or outage. Ask each engineer to list the work they do that never appears in a roadmap ticket. That list is usually where the floor rises.

The worksheet should also identify work that should disappear. Google SRE defines toil as operational work that tends to be manual, repetitive, automatable, reactive, without lasting value, and proportional to service growth. That is a useful test, but do not label all non-feature work as toil. A difficult incident review that removes an entire failure mode has lasting value. Rebuilding a brittle deployment path has lasting value. A human repeatedly copying customer data between systems does not.

Product domains need named ownership before they need more people

A product domain is an area of the business that can change, fail, expose data, or block revenue independently. Count domains by operational responsibility, not by the number of services in your architecture.

For a typical B2B SaaS company, domains may include identity and access, billing, tenant and permission rules, the core workflow, reporting and data exports, integrations, data movement, and delivery infrastructure. Your product may combine several of these. The test is whether a production problem or a customer commitment can demand focused knowledge that other engineers do not have.

Make a table like this:

The hours in the first two numeric columns go into your workload calculation. The last two columns reveal your coverage risk. Every revenue, security, or availability-sensitive domain needs a primary and a backup who can diagnose and change it. A backup is not the person who knows where the repository is. A backup can make a safe production decision when the primary is asleep or unavailable.

Do not create a staffing rule that says each domain requires two full-time engineers. That would be absurd for most early SaaS products. One capable engineer can own multiple quiet domains. The mistake is different: assigning one person six domains that all generate support, release, and incident work in the same week. That person becomes the schedule.

A useful pressure test is to remove one engineer from the board for two weeks. Do not let them answer questions. Can the remaining team release a fix, complete a customer implementation, respond to an incident, and pass a security review? If the answer depends on "nothing unexpected happens," you do not have backup coverage.

Avoid counting microservices as domains. Splitting a monolith into fifteen deployable units does not create fifteen independent staffing needs. It can create more maintenance work, however. If service boundaries force separate deployment, monitoring, credentials, alert handling, and upgrades, put that operational cost into the domain's maintenance hours.

Customer implementations often consume the first hidden engineer

Customer implementation work belongs in the staffing model when engineers configure, integrate, migrate, validate, or troubleshoot customer environments. Calling that work "solutions," "success," or "pre-sales" does not make the engineering hours disappear.

Build an implementation catalog with the actual motions your team performs. Do not average everything into one number if the work has distinct shapes.

In this example, implementation work totals 1,598 hours. With 1,350 usable annual hours per engineer, that workload alone exceeds one full-time engineer. A founder who budgets only for product features will conclude that the team misses commitments for mysterious reasons. There is nothing mysterious about it. The company sold more engineering work than it counted.

Add discovery calls only when an engineer must attend. Add proof-of-concept work only if sales expects engineering to produce it. Add rework from unclear requirements. Add the first month after launch if the customer commonly finds edge cases once real users arrive. Skip the passive time that a customer waits for an answer. Count the active time your people spend.

There is a popular recommendation to protect product engineers by moving every implementation to customer success. It sounds clean because it moves a cost center off the engineering spreadsheet. It is wrong when the implementation includes production integrations, data correctness, permission mapping, performance limits, or changes that create a support burden later. Customer success should own communication, coordination, training, and routine configuration. Engineers should own the work that changes the product's behavior or risk profile.

The answer is not always another hire. Sometimes the right answer is to stop selling the custom path. If one implementation requires bespoke fields, special permission behavior, and a custom export, charge enough to fund it or decline it. A product company that treats repeated custom work as free onboarding becomes a services company by accident.

Track implementation hours by customer cohort for one quarter. The result will tell you whether you have a staffing issue, a packaging issue, or a product gap. Those are different problems and deserve different responses.

On-call capacity is active work plus a minimum safe rotation

Do not calculate on-call by multiplying 168 hours by the number of weeks in a year. Engineers are available during a rotation, but passive availability is not the same as active labor. Count pages, triage, customer updates, investigation, repair, follow-up, alert tuning, and the delivery work displaced by interruptions.

Your production tab can use this shape:

Pages per month x average active hours per page             [hours]
Customer-impacting investigations per month x hours         [hours]
Post-incident repair and prevention per month x hours       [hours]
Release support, upgrades, backups, access changes          [hours]
Operational tickets and recurring manual work               [hours]
Annual production and on-call active work = 12 x monthly total

If an alert wakes an engineer for 45 minutes and creates six hours of investigation and repair the next day, record 6.75 hours, not 0.75. The follow-up is the actual cost. Founders often count only the page because the repair work gets absorbed into a sprint and loses its label.

Then set a coverage minimum outside the hour calculation. For a customer-facing service with a real 24/7 commitment, I would not run a primary rotation with fewer than four qualified engineers. Four is not a magic compliance number. It is a practical minimum that leaves some room for vacation, illness, a concurrent incident, and basic human limits. If the product has a serious security or availability promise, add a trained secondary path rather than assuming the primary can solve every problem alone.

Google's SRE guidance makes the same structural point from a larger-company setting: a rotation creates an unavoidable operational load even before page volume spikes. Its example shows that primary and secondary duties consume a meaningful fraction of time in a six-person rotation, and it argues that teams should put an explicit upper bound on operations rather than treating it as invisible. Your team does not need Google's model, but it needs a visible limit.

A quiet pager does not prove that your coverage is adequate. It may mean the product is stable. It may also mean alerts are weak, customers report incidents through support, or engineers silently intervene before the system pages. Review incident records, support escalations, and release rollbacks together.

If only one person can repair production, the coverage minimum is not one. It is at least two trained people, and your immediate work is knowledge transfer. If only two people can operate production and both also carry every customer escalation, your coverage problem is already affecting delivery capacity.

Compliance work is recurring engineering labor

Compliance does not begin when an auditor sends a list. The engineering work starts when a customer expects access controls, software change evidence, vulnerability handling, secure development practices, recovery procedures, or a credible answer to a security questionnaire.

NIST SP 800-218 organizes secure software development around preparing the organization, protecting software, producing secure releases, and responding to vulnerabilities. That structure is useful for staffing because each group creates work that must happen before and after a release. A policy document may satisfy a checkbox, but engineers still maintain the build path, dependency process, access controls, security fixes, and technical evidence.

List recurring work in your compliance tab:

• Access and permission reviews that require engineering judgment.
• Dependency, vulnerability, and security remediation.
• Evidence collection for changes, releases, backups, and recovery tests.
• Security questionnaires and technical architecture reviews for prospects.
• Control fixes after an audit, customer assessment, or incident.

Estimate each item as annual active hours. If a person spends two hours every Friday resolving dependency findings, reviewing access exceptions, and attaching evidence to changes, that is about 100 hours a year before a single audit meeting. If sales sends ten large security questionnaires and engineers spend six hours on each, add 60 hours. Small lines accumulate quickly.

Do not count every compliance activity as engineering. Legal, finance, HR, and security leadership may own large parts of the program. Count the portion that requires someone who understands the system and has permission to change it. This keeps the worksheet honest without pretending engineering can delegate technical accountability to a compliance coordinator.

The worst version of this problem appears when a company delays controls until an enterprise contract is close. Engineers then stop roadmap work, reconstruct evidence from months ago, add emergency access restrictions, and answer a questionnaire with architecture that was never written down. The sales team calls it a final push. Engineering calls it three months of unplanned work.

Put baseline security and release practices into normal capacity before enterprise sales forces the issue. If the company has no enterprise motion and no regulated customer requirement, keep the estimate modest. If your product handles sensitive customer data, supports larger accounts, or faces frequent security review, pretending compliance is someone else's work makes your floor fictional.

Review capacity cannot be the leftover fraction of a sprint

Every meaningful change needs a second engineer's attention. Review is not only a pull request approval. It includes design discussion, test strategy, release judgment, incident review, pairing on risky fixes, and time spent making another person's change understandable.

The usual planning error is simple: leaders allocate every engineer's week to authored work, then assume review happens between meetings. It does not. Reviews wait. Engineers approve changes too quickly. Senior people become the permanent bottleneck. Junior engineers stop getting useful feedback because the people with context are busy fixing production.

Use a direct estimate in the worksheet:

Annual authored delivery hours x review ratio = annual review hours

For a team that works through unfamiliar systems, difficult integrations, or security-sensitive changes, a 20% to 30% review ratio is a defensible starting assumption. For mature, well-tested code with small changes, the ratio may be lower. Do not copy the ratio blindly. Pull a sample of completed work from the last six weeks and compare author time with reviewer time, including comments, follow-up, and release support.

Suppose your product, implementation, and compliance tabs contain 4,000 hours of authored change. At a 25% review ratio, reserve 1,000 hours for review. With 1,350 usable hours per engineer, that is 0.74 FTE. Rounding it away is exactly how a three-person team becomes permanently late.

Review also has a coverage rule. A change in a sensitive area should not rely on the only person who understands that area approving their own work under time pressure. You need enough overlapping knowledge for a second engineer to challenge an assumption. Automated tests help, but a test suite cannot decide whether a billing migration breaks an enterprise contract or whether a permission change exposes tenant data.

Google's release guidance connects automation with consistency, rollback ability, and peer review. I agree with the direction but not with the lazy conclusion that automation removes the need for review. Automation reduces repeated mechanics. It makes review capacity more effective because reviewers can focus on behavior and risk instead of manually shepherding a release.

If review queues are long, do not solve it by dropping review requirements. Reduce change size, remove work in progress, improve tests, spread domain knowledge, or add capacity. Skipping the second set of eyes is a debt instrument with an unpleasant interest rate.

Work through one honest SaaS example

Consider a SaaS company with a core workflow, billing, tenant permissions, reporting, several customer integrations, and a production service that customers expect to be available outside business hours. The founders have three engineers and believe they need one more because the roadmap has slipped.

The worksheet shows the following annual active work:

With 1,350 usable annual hours per engineer, the workload calculation is 6,830 / 1,350 = 5.06, which rounds to six engineers. The coverage map also requires four qualified people for the primary production rotation. The floor is six, not three and not four.

That result does not automatically mean hire three engineers. Read the categories. The company has 1,450 hours of implementation work, which is more than one full-time engineer's usable annual capacity. It also spends 820 hours operating production. Before hiring, the founders should decide whether their commercial model supports a dedicated implementation path, whether some integrations should become repeatable product work, and whether recurring production tasks should be automated or eliminated.

Assume they make three changes: they package the most common integration, eliminate 250 annual hours of manual implementation work, automate a recurring operational procedure that removes 140 annual hours, and reduce unnecessary custom reports by 180 hours. Their new total is 6,260 hours. The workload floor remains five engineers after rounding. The operating model improved, but the original team is still short.

This is the point of the exercise. It tells you whether a promised efficiency program changes the staffing decision or merely makes an overloaded team slightly less overloaded. It also prevents false savings. If someone proposes cutting an engineer, ask which row disappears, who owns the remaining work, and how the coverage map still holds.

A lower floor requires a different business design

You can lower the headcount floor, but you cannot do it with a slogan about productivity. You lower it by removing work, making work repeatable, or changing the promise you make to customers.

The best candidates are repeated implementation steps, manual release gates, duplicate support paths, fragile integrations, overly broad permission models, and reports that exist for one customer. Google SRE's definition of toil is useful here because it points at work that grows with the business without leaving the system better than it was. Find that work and remove it before adding people to perform it faster.

AI tools can reduce the floor when they remove measured hours from a real category. They can draft tests, speed up investigation, create migration scaffolding, summarize support context, and handle routine code changes. They do not erase the need for a person who owns a production decision, reviews a risky change, understands a customer's data boundary, or decides that a repeated request should become product work.

Run the worksheet before and after a change. If an AI workflow saves 300 hours per year in implementation and review, subtract 300 hours. Do not subtract a whole engineer because the team feels faster. If the remaining number still rounds to the same headcount, use the recovered time to reduce backlog, improve reliability, or increase margin. Those are real gains.

If your calculation exposes a gap and you want an outside view, a Team & AI Audit should inspect the ticket history, implementation load, operational records, and ownership map. A staffing spreadsheet is useful only when its inputs come from the business you are actually running, not the business you describe in a board deck.

The first useful action is to schedule ninety minutes with your engineering lead and list every recurring activity that interrupts feature work. Put the hours in the sheet without defending them. The number may be uncomfortable. It will still be cheaper than discovering it during the next enterprise launch or production incident.