# Should you run a vacancy test before replacing an engineer?

> Use a vacancy test before replacing an engineer to measure unmet work, protect delivery risk, and redesign the role before approving headcount.

Hiring an engineer because someone left is often an expensive reflex. A departure creates anxiety, the team reports more pressure, and the old job description gets reposted before anyone asks whether the company still needs that exact role.

A vacancy test replaces that reflex with a controlled pause. You hold the position open for a defined period, make the work visible, protect the team from unsafe exposure, and decide from evidence whether to hire, redesign the job, redistribute ownership, or stop doing work that has lost its purpose. This is not a headcount freeze dressed up as management. It is a way to stop buying yesterday's org chart.

I have seen companies backfill a role, wait six months, and discover they hired someone to maintain a workflow that should have been automated or retired. I have also seen founders call a role optional because the team managed for two weeks, only to learn that the missing person had quietly been carrying production knowledge, customer trust, and architectural decisions. Both mistakes come from the same failure: nobody measured the vacancy properly.

## A vacancy test is a decision experiment, not a cost-cutting stunt

A vacancy test asks one narrow question: what breaks, slows, or becomes dangerous when this role has no owner for a short, pre-agreed period? The answer should change a staffing decision. If it will not, skip the exercise and make the hire.

The distinction matters because a hiring freeze and a vacancy test produce opposite behavior. A freeze tells managers to make do, which encourages people to hide overload and defer problems. A test asks people to report the work they cannot do, the work they absorbed, and the risk they see. One suppresses information. The other collects it.

The test also does not ask whether the remaining team can work harder. Teams almost always can, for a while. They skip refactoring, answer messages at night, let monitoring alerts pile up, and postpone uncomfortable decisions. That kind of apparent success is useless. If you reward silent compensation, you will conclude that every departure was harmless until the bill arrives as outages, churn, or resignations.

Define the hypothesis before the first day. A useful hypothesis is specific enough to disprove:

- "Without a dedicated mobile engineer, releases will still happen, but app-store release ownership and payment-flow defects will create measurable delay."
- "Without an engineering manager, the senior engineers can run delivery, but cross-team priority decisions will wait too long."
- "Without a platform engineer, deployment work will consume more feature time, but the missing work may justify automation rather than a full-time hire."
- "Without a junior QA role, product engineers can cover release checks if they have a stable test environment and a defined acceptance checklist."

A useless hypothesis says, "The team needs this person." Of course the team may feel that way. The test exists to identify the actual work behind the feeling.

There is a hard boundary: never use a vacancy test to gamble with a duty that has no backup. If a departing person is the only one who can respond to a security incident, restore production data, approve a regulated release, or support a revenue-critical customer obligation, establish coverage before the test begins. You may still test the eventual role design, but do not make an operational single point of failure into an experiment.

## Set a short window and write the rules before work disappears

Most engineering vacancy tests should last four to eight weeks, with a written start date, end date, and decision meeting already on the calendar. A vague "let's see how it goes" turns into delay, resentment, and unreliable memory.

Choose the duration from the work cycle, not from the finance calendar. A role that handles daily support, deployments, or on-call rotation reveals its absence quickly. A role responsible for architecture review, security posture, hiring, or partner integrations may need several weeks before the missing decisions surface. Do not stretch the test simply because a longer pause saves payroll. Once the team starts protecting itself through overtime, your data gets worse every day.

At the start, write a one-page test charter. It should include five items:

1. The role being tested and the responsibilities attached to the person, not the title alone.
2. The test period and the executive who will make the final staffing decision.
3. The work that may not be deferred, such as incident response, customer commitments, or release approvals.
4. The escalation rule for risks that cross the safety line.
5. The possible outcomes: hire, redesign and hire, use temporary coverage, redistribute ownership, automate, retire work, or extend the test for a stated reason.

The escalation rule needs teeth. State who can stop the test and what triggers it. For example: "The VP of Engineering may end the test if the team loses production incident coverage, misses a signed customer delivery because the role has no owner, or spends more than two consecutive weeks with on-call work outside the planned rotation." The precise threshold will differ, but a named decision maker prevents a founder from dismissing every warning as normal startup pressure.

Tell the affected team what you are doing and what you are not doing. Say that the company is testing a role design, not grading individuals on whether they can carry two jobs. Ask people to log absorbed work during normal planning and standups. Do not ask them to build a second reporting system after hours.

This is where leaders often get cute and create a secret test. That is a mistake. A hidden vacancy test makes people fear that any complaint will make them look weak, so they conceal the evidence. Openly state the test window and the rules. Adults can handle a constrained experiment. They cannot handle being quietly assessed for endurance.

## Count unmet outcomes, not the number of tickets

Ticket volume is one of the weakest measures in a vacancy test. A team can close a hundred minor tickets while a single unowned decision blocks a major release. It can also leave tickets untouched because they should never have existed. Count outcomes that matter to the company.

Start with five buckets and keep them separate:

| Bucket | What to record | Why it matters |
|---|---|---|
| Missed delivery | Commitment, original date, new date, and reason | Shows whether the missing role owns throughput or planning decisions |
| Absorbed work | Who took it, hours or capacity used, and what they dropped | Shows the real substitution cost |
| Quality and reliability | Escaped defects, incident delays, skipped maintenance, and review gaps | Shows whether apparent delivery came from borrowing against operations |
| Decision delay | Decision needed, owner missing, waiting time, and consequence | Shows leadership or architecture gaps that tickets miss |
| Customer and revenue exposure | Renewal risk, support delay, sales blocker, or contractual impact | Connects the vacancy to business harm rather than internal discomfort |

Use a simple log. It should be easy enough to update in a planning meeting and specific enough that a leader can audit it later.

```text
Date: 2026-07-08
Work item: Production database upgrade
Original owner: Platform engineer role
Temporary owner: Senior backend engineer
What changed: Upgrade moved from July 10 to July 24
Capacity absorbed: Two planned feature days and one on-call handoff
Risk: Security patch window is now tighter; rollback plan has not been reviewed
Decision needed: Approve temporary contractor or reduce July feature scope
Escalation level: Amber
```

Do not turn the log into a complaint board. Every entry needs a concrete work item, an observed consequence, and an owner. "We are overloaded" may be true, but it does not tell you whether to hire a senior engineer, a release manager, a support specialist, or nobody.

The sharp distinction is between **work that is delayed** and **work that is displaced**. Delayed work still needs an owner later. Displaced work forced another person to give up something else. A company that counts only delayed work will underestimate the vacancy. A company that counts only displacement may keep tasks alive that nobody actually needs.

A third category deserves its own field: work that disappears without harm. When a departing engineer stops producing a weekly status report and nobody misses it, do not assign that report to the replacement. When no one notices that a standing meeting ended, delete it. Vacancies reveal organizational debris. Treat that as useful evidence, not an excuse to claim the old role was worthless.

## Risk must have an owner before it becomes an incident

The danger in a vacancy test usually sits outside the sprint board. It shows up in an expired certificate, a customer escalation with no technical owner, a release that needs a decision, or a production system that everybody assumes someone else understands.

Create a separate risk register on day one. Keep it small and reviewed weekly by the person who can change priorities or approve temporary help. Each risk needs a named owner, a trigger, and a response. If the role has no clear ownership in the register, you have already found part of the problem.

For an engineering role, review these areas directly:

- Production access, on-call coverage, rollback authority, and incident communications.
- Security duties such as dependency response, access reviews, secrets rotation, and vulnerability triage.
- Release responsibilities, including quality gates, change approval, and customer-facing coordination.
- Architecture decisions that need someone to break a tie or accept a technical tradeoff.
- Knowledge held by one person, especially undocumented integrations, infrastructure exceptions, and major customer customizations.

Do not label every risk red. That makes the register performative. Use a plain scale with defined meaning. Green means the team has a documented backup and can execute. Amber means a known owner can handle the work but must displace planned work or relies on incomplete knowledge. Red means nobody can safely execute the responsibility within the required response time.

A red item ends or changes the test. It does not wait for a Friday staffing meeting because someone wants a fuller data set. If production recovery depends on an absent role, appoint coverage immediately. You can later decide whether the permanent answer is a hire, a managed service, a change in architecture, or a better rotation. The company must first be able to operate safely.

Be wary of the popular recommendation to "just document everything" before a person leaves. Documentation helps, but it does not replace judgment under pressure. A runbook can tell an engineer how to restart a service. It cannot always tell them which customer promise to protect, which risky change to reject, or when a seemingly isolated alert signals a broader failure. The test should separate missing documentation from missing decision authority and missing technical depth. Those are different hiring problems.

## The first clean week often lies to you

A vacancy test can look successful at the beginning for the wrong reasons. Teams have slack, unfinished work has not matured into a problem, and senior people tend to cover gaps without being asked. If you decide after five calm days, you are measuring goodwill rather than the role.

Consider a common failure. A startup loses its sole engineering manager and holds the role open. In week one, the senior engineers divide ceremonies, a founder attends planning, and delivery appears normal. The founder concludes that engineering management was overhead.

By week three, two product requests conflict, but no one has authority to choose between them. The most senior engineer becomes the default referee, then skips design review to handle a customer escalation. A deployment slips because nobody forced a decision on acceptance criteria. One engineer quietly spends evenings answering messages that used to go to the manager. The sprint board still shows healthy velocity because the team cuts the harder work into the next cycle.

If the only metric is completed tickets, the experiment says the manager was unnecessary. If the company logs displaced design review, delayed priority decisions, founder time, missed release criteria, and after-hours coordination, it learns something more useful: the missing role owned decision hygiene and cross-team commitments, not meetings.

That evidence may justify hiring another engineering manager. It may also point to a different answer. Perhaps the company is too small for a full manager but needs a staff engineer with explicit delivery authority, a founder who commits to one hour of priority decisions twice a week, and a product lead who owns acceptance criteria. The vacancy test does not automatically produce a backfill. It exposes the work package.

Watch for four forms of false success:

- A senior engineer absorbs the work but abandons architecture, mentoring, or reliability work.
- The team reduces scope without recording what it gave up.
- A founder performs the missing role and calls it free because it is not in the engineering budget.
- Customer or maintenance consequences have not appeared yet because the relevant cycle is longer than the test window.

Ask every temporary owner, "What did you stop doing to cover this?" That question produces better data than "Can you handle it?" Most capable people will say yes to the second question. The first exposes the trade.

## Rewrite the role around outcomes before you open a requisition

A departure gives you a rare chance to strip a job description down to the work the company now needs. Do that before recruiting starts. Copying the old title and bullet list is how companies hire for habits they no longer want.

Begin with the evidence from the log. Group entries into ownership areas, then write the outcome each area requires. Avoid vague phrases such as "support the team" or "drive technical excellence." Those phrases hide the actual decision rights and make interviews fuzzy.

Here is the difference:

| Old job-description language | Outcome-based replacement language |
|---|---|
| Own CI/CD | Keep the release path predictable, with named ownership for failed deployments and a tested rollback process |
| Lead backend development | Deliver the service changes needed for the next product milestone while preserving response-time and reliability targets set by the team |
| Manage engineers | Make priority conflicts visible, assign clear owners, and prevent commitments from being made without delivery capacity |
| Improve quality | Establish release checks that catch the defects found during the vacancy test and remove repeated manual verification work |

Then decide what should not return to the role. If the test showed that a recurring report, meeting, approval, or manual task had no meaningful consequence when absent, remove it. Hiring someone and then handing them dead work because it used to be somebody's responsibility is an easy way to recreate the same expensive structure.

Separate permanent ownership from temporary coverage. A temporary owner might have handled release coordination during the test, but that does not prove release coordination should remain their job. It proves they were willing to absorb it. The permanent design must account for the work they sacrificed.

Also separate seniority from title. Teams frequently say they need a "senior engineer" when they need one of several different things: someone who can make architecture decisions, someone who can stabilize operations, someone who can unblock a customer integration, or someone who can teach a less experienced team to ship safely. Those needs may overlap, but they do not always require the same person.

A good requisition names the first 90-day outcomes, the decisions the person can make without escalation, the interfaces they own, and the work explicitly outside their scope. It should be uncomfortable to write because it forces leaders to choose. That discomfort is cheaper than hiring a generalist job description and discovering, after the person arrives, that three executives expected different work.

## Hiring, automation, and redistribution are different answers

The evidence should lead to a choice, not a ritual. There are six legitimate outcomes, and each has a different burden of proof.

**Approve the hire** when the test shows recurring work with meaningful business or operational consequence, no sustainable internal owner, and no cheaper way to eliminate or narrow the work. The approved role should own defined outcomes, not a list of leftovers.

**Redesign and hire** when the old role mixed unrelated work. This is common after fast growth. One person may have handled infrastructure, customer escalations, hiring, release coordination, and internal planning because they were reliable. That is not a coherent replacement role. Split the work, retire some of it, and hire for the part that remains.

**Redistribute ownership** when the work fits existing roles and the team can take it on without dropping higher-value responsibilities. Put the new ownership in writing. "The team owns it" means nobody owns it.

**Automate or simplify** when the vacancy reveals repetitive work that exists because the company tolerated a manual process. This requires a real plan with an owner and a deadline. Saying "we will automate it" to avoid a hire is fiction unless someone has capacity to do the automation.

**Use temporary coverage** when the need is real but bounded. A contractor, advisor, or part-time specialist can handle a migration, audit, difficult integration, or short hiring gap. Give that person a deliverable and an internal owner. Do not hire temporary help to carry an undefined permanent problem.

**Retire the work** when the company no longer gets enough return from it. This is the answer founders avoid because it can feel like admitting that past effort was wasted. It is usually better to stop a low-value process than to keep paying people to honor its history.

The decision memo should fit on one page. It should state the tested role, window, major unmet outcomes, risks, absorbed capacity, work removed, proposed answer, cost owner, and the first 90-day success conditions. If a leader cannot explain the decision in that format, the company probably has a feeling, not a staffing case.

For teams that have gone through repeated departures, a Team & AI Audit can help make this evidence visible before headcount gets approved by inertia. The useful output is not a generic recommendation to use AI. It is a map of which work requires experienced judgment, which work can be automated, and which role boundaries are costing the company money.

## Do not use AI as an excuse to delete ownership

AI changes the vacancy test because it can remove chunks of execution work. It does not remove accountability for production, product tradeoffs, technical direction, or customer commitments.

A developer using coding agents may produce more code, draft tests, summarize incidents, update documentation, or prepare pull requests faster. That can change whether a team needs another implementation-focused engineer right now. It cannot answer whether the team has enough people who can decide what to build, review risky changes, own an incident, or reject a bad shortcut under deadline pressure.

Run a narrow automation trial inside the vacancy test rather than making a grand claim about replacement. Pick one work category that appeared in the log, such as first-pass support triage, regression test creation, dependency update preparation, or runbook drafting. Assign a human owner, define an acceptance check, and record the time saved and the rework created.

For example, if a departing QA engineer owned repetitive release verification, test whether product engineers can use generated test cases plus a stable release checklist for two releases. Track escaped defects, release delay, review burden, and time spent repairing generated tests. If quality holds and the team does not lose feature capacity, the replacement job may shift away from manual regression work. If the trial creates false confidence and late defects, you have evidence that the work needs a stronger owner.

Do not compare the AI trial with an imaginary perfect employee. Compare it with the actual work package and the actual capacity it consumes. A tool that saves an hour but creates two hours of review is not reducing the role. A tool that handles routine preparation while a senior engineer retains judgment may let you hire later or hire for a different level of work.

The same rule applies to multi-agent pipelines, code review automation, and internal knowledge tools. They can reduce coordination and execution load. They do not create a responsible person when a customer needs an answer or a production change needs approval. Keep ownership visible even when the mechanics become faster.

## Protect people from the test you asked them to run

A vacancy test fails if the team pays for it with invisible overtime. You will get bad evidence, and you may lose the very people who were capable enough to cover the gap.

Set capacity limits at the beginning. Temporary owners should identify the work they will drop before they accept new responsibilities. If no work can be dropped, the company has learned that it needs coverage. Do not congratulate someone for carrying two full roles and then use their sacrifice as proof that the role was unnecessary.

Review workload in a short weekly meeting with the actual decision maker. Ask for facts: what was delayed, what was displaced, where did risk move, and what needs a decision this week? Do not make the meeting a debate about personal resilience. Engineers who feel pressed will often minimize their own load because they want to protect the team or avoid looking less capable.

Keep performance management out of it. If a person struggles during the test, investigate whether the role was poorly transferred, the scope is unreasonable, or they lack authority. Do not use the test as a covert way to rank employees. People who suspect that motive will either overwork or stop reporting problems, both of which corrupt the result.

A founder also needs to log their own absorbed work. If you start approving technical decisions, calming customers, rewriting requirements, or coordinating releases because a role is open, put that in the record. Founder time is not free. It is often the most expensive hidden substitute in an early-stage company because it displaces sales, fundraising, product direction, and hiring.

End the test on the date you set, unless an escalation rule stopped it early. Make the decision while the evidence is fresh. The worst outcome is an open role that remains undefined for months, with a team quietly operating in emergency mode because nobody wants to make a call.

The next time someone says, "We need to backfill this engineer," do not start with the job board. Start with the work that would be unowned, the harm that would follow, and the work that can disappear. If the evidence says hire, hire with a cleaner mandate. If it says redesign, do not pay for the old shape out of habit.