The two-engineer continuity drill for release safety

A two-person engineering team does not need a theoretical continuity plan. It needs proof that one engineer can keep the business safe for a week when the other is suddenly unavailable.

Most founders misread the risk. They see a small team delivering quickly and assume the work is shared because both people attend the same standup, touch the same repository, and appear in the same chat channels. That is capacity. Continuity is different. Continuity exists only when either person can release, investigate, communicate, and recover without private knowledge or private access held by the other.

The two-engineer continuity drill is a one-week operating simulation. One engineer remains available. The other performs no engineering work, gives no technical answers, approves no pull requests, and does not rescue the exercise from the sidelines. You run normal work through that constraint, inject a few bounded tasks that reveal dependencies, preserve evidence, and score what happened. The point is not to prove that one person can absorb two jobs forever. The point is to find the exact places where a routine absence turns into unsafe delivery or customer harm.

This drill measures continuity, not heroic output

A continuity drill asks whether the company can operate safely with one engineer missing. It does not ask the remaining engineer to clear the whole backlog, maintain normal feature velocity, or work late enough to make the score look respectable.

That distinction matters because teams often fail the test, then hide the failure behind effort. An engineer who stays online until midnight, messages the absent teammate for a database detail, pushes directly to production, and answers customers from memory did not preserve continuity. They bypassed the controls that should protect the company when the real absence lasts longer or occurs during an incident.

Set the rule before the week begins: reduce planned delivery to a minimum viable operating load. Keep one small, ordinary change in scope. Keep normal support and on-call duties. Do not add a large migration, a launch with contractual consequences, or an artificial disaster that could damage production. You want ordinary friction to appear clearly.

The test has four scored areas:

• release safety: can the engineer change production through a controlled path and reverse it?
• incident response: can the engineer detect, investigate, mitigate, and document a service problem?
• customer support: can the company give customers accurate, timely answers without private technical knowledge?
• access ownership: can the engineer reach and recover every account required to operate the service?

Keep a fifth category outside the score: workload. Record interruptions, hours, and deferred work, but do not let them dominate the result. A team may score well on continuity and still need more capacity. It may also have spare capacity while failing badly on access ownership. Those are separate management problems.

Write a one-page drill charter and send it to everyone who may be pulled into it. The charter prevents the familiar outcome where sales, support, or a founder quietly asks the unavailable engineer for help because a deadline feels important.

Continuity drill: [start date] through [end date]
Unavailable engineer: [name]
Available engineer: [name]

Rules
- The unavailable engineer performs no engineering, support, approval, or access-recovery work.
- The available engineer uses normal production controls.
- Anyone may clarify a business priority. Nobody may supply hidden technical knowledge.
- The facilitator records blockers, workarounds, time to first useful action, and evidence.

Success condition
The company can safely release a bounded change, handle one service issue,
answer selected customer requests, and demonstrate organization-owned access.

Make the founder or an operations lead the facilitator. The remaining engineer should not grade their own work while trying to keep the business running. The facilitator does not need to understand every line of code. They need to ask plain questions: Where is that documented? Who can approve this? Can you prove the backup works? What would you tell the customer right now?

Pick a week that resembles real operating conditions

The cleanest drill week has active work, ordinary customer traffic, and no exceptional event that would distort the result. A quiet week that contains no deployment, no support request, and no operational decision produces a comforting score with very little evidence.

Start with the calendar. Select one bounded release that the available engineer did not design alone. It can be a bug fix, a configuration change, a small feature behind an existing release control, or a dependency update with a documented impact. Avoid a cosmetic documentation-only change. That proves repository access, not release safety.

Then choose one customer scenario that requires technical interpretation. Examples include a report of incorrect data, a failed integration, a confusing invoice caused by usage behavior, or a request for a status update during a service degradation. The support task should force the engineer to locate facts in logs, dashboards, application records, and account settings. It should not ask them to recite an answer already written in a help center article.

Finally, schedule an access verification session during the week. Do not ask people whether they think access exists. Log into the relevant systems with the available engineer's normal identity and confirm that the organization can recover privileged access if that identity disappears too.

A useful schedule looks like this:

1. On Monday, freeze the drill rules, capture the starting access inventory, and hand the remaining engineer the ordinary work queue.
2. On Tuesday or Wednesday, run the bounded release through the usual review, build, deployment, and observation process.
3. On Thursday, inject the incident or customer scenario at a time when the engineer has other work underway.
4. On Friday, verify recovery paths, score the evidence, and assign owners and dates for fixes.

Do not announce the exact incident timing to the available engineer. Do announce that an incident exercise will occur. Surprise should test prioritization and discovery, not whether someone happens to be staring at a dashboard at the exact moment a synthetic alert fires.

A missed deadline during this week is evidence, but it is not automatically a failure. Shipping less is often the correct response when review coverage drops from two people to one. The failure is pretending that a reduced control set gives the company the same level of safety.

A release needs independent evidence before it is safe

A remaining engineer can deploy code alone in many tools. That does not make a solo release safe. A safe release has a known change set, a working verification path, an explicit rollback method, and a decision record that another responsible person can inspect.

The mistake I see most often is treating code review as a ceremony rather than a control. In a two-person team, review has two jobs: it catches defects, and it spreads operational understanding. If one engineer authored a change and the other is unavailable, forcing a fake second review from a founder who cannot assess the code adds delay without creating safety. Waiving review without adding any compensating control creates a blind spot.

Use a release classification instead. The team should decide in advance which changes one engineer may ship during a continuity event and which changes wait.

The word "sometimes" should make founders uncomfortable. It should. You cannot reduce release risk to a universal approval count. You need a written rule that matches the blast radius of the change, then evidence that the rule was followed.

GitHub's protected branch documentation makes an operational point that small teams often overlook: required reviews, stale-approval dismissal, and code-owner review rules have meaning only if the branch policy prevents people from bypassing them. GitLab's documentation makes the same point more bluntly. Direct push permissions can skip merge request controls, so protected branches need explicit push restrictions rather than assumptions about who will behave carefully.

During the drill, require the available engineer to produce this release record before merging or deploying:

Change: API timeout handling for invoice export
Risk class: bounded production fix
Customer effect if wrong: exports may fail or repeat
Evidence before deploy:
- automated test run: passed
- manual test: export from test account completed
- metric to watch: export failure count and request latency
Rollback: deploy previous release through pipeline job rollback-production
Decision owner: CTO/founder, based on written risk record
Observation window: 30 minutes after deployment

The record can live in the pull request, ticket, or release channel. Its location matters less than its completeness. The person approving the decision does not need to review code line by line. They must understand the customer effect, the recovery route, and the condition that means "stop."

Score the release at the end, not when it ships. Check whether the engineer could find the previous release artifact, execute the rollback without editing files by hand, identify the dashboards that show success or failure, and explain any alert. If rollback exists only as an untested sentence in a wiki, mark it unproven.

An incident drill should test decisions, not alert theater

An incident exercise should force the available engineer to make a customer-impact decision with incomplete information. A dashboard screenshot and a canned alert do not do that.

Use a contained scenario. For example, arrange for a noncritical background worker to reject a known test job, create a controlled delay in a staging-connected integration path, or simulate a provider outage in a test tenant. If your production architecture supports safe failure injection, choose a path that affects a small, reversible slice of traffic and requires no data repair. If it does not, use real production telemetry with a simulated report and require a mitigation plan rather than injecting a destructive fault.

NIST Special Publication 800-61 Revision 3 treats incident response as part of broader cybersecurity risk management rather than a separate emergency binder. That framing is useful for a startup. Preparation includes ownership, asset knowledge, communications, and recovery decisions made before the alert arrives. A clever incident channel cannot compensate for an account nobody owns or a deployment nobody can undo.

The facilitator should create a timeline as the scenario unfolds. Capture actual times, but do not turn the drill into a contest for the shortest number. The quality of each decision matters more.

Make the customer communication part real. Ask the available engineer to draft a reply for an affected customer and a short internal update for the founder. Do not reward technical detail that the recipient cannot use. A strong customer message says what is failing, who is affected, what the company is doing, when the next update will arrive, and what the customer should do meanwhile. It does not promise a root cause before anyone has found one.

A common failure looks like this. A customer reports that exports have stopped. The engineer finds elevated job retries but cannot tell whether the issue began after a deployment, a queue configuration change, or a provider problem. They message the absent engineer because only that person knows the worker topology. The incident may be mitigated eventually, but the drill has revealed three distinct failures: the system map is private, the on-call path does not state who owns the worker, and customer support cannot offer a reliable update.

Record all three. Do not collapse them into "documentation needs improvement." That phrase tends to produce a large, ignored cleanup ticket.

Customer support fails when technical facts live in one head

Customer support continuity means the company can provide accurate answers while investigation continues. It does not mean every support person becomes an engineer.

In small companies, the founder often routes hard support questions straight to the engineer who built the relevant feature. It works until that engineer is on a flight, asleep during an outage, leaves the company, or simply has five urgent tasks open. Then support sends vague updates, or worse, it relays an engineer's speculative diagnosis as fact.

During the drill, send two or three realistic requests through the actual support route. One should be a straightforward operational request such as "Can you confirm whether our import ran?" Another should require a decision boundary, such as "Can you restore this deleted record?" A third can be an incident-status request if it matches the scenario.

The available engineer should use a support packet, not memory. A good packet has four compact pieces:

• a service map that says where to check a customer action or job
• approved customer language for known failure modes and maintenance events
• a decision table for refunds, restores, data changes, and security-related requests
• an escalation rule that names the business owner when the answer has legal, financial, or contractual consequences

The decision table matters because access is not permission to act. An engineer may be able to edit a database record, issue a credit, or disable an account. That does not mean they should decide alone whether to do it. The drill should expose both missing access and excessive authority.

Score support using evidence from the ticket thread. Did the response state an answer the company could verify? Did it give a specific next update time? Did the engineer know whether a request required founder approval? Did the support person know where the investigation stood without repeatedly interrupting the engineer?

If the team only answers because the available engineer searches old chat messages, count that as partial credit at best. Searchable chat is useful. It is not an operating manual, because it rarely states whether an old answer still applies, who authorized it, or what changed after the message was posted.

Access ownership is broader than production credentials

Access ownership means the company, rather than an individual, controls the accounts needed to build, deploy, observe, support, bill, secure, and recover the product. A password manager entry alone does not prove that.

Start with an inventory that names systems by function. Do not begin with a list of tools and assume the list is complete. Ask which systems the remaining engineer would need to perform each action in the drill: merge a release, deploy it, inspect an error, change an environment value, answer a customer, receive an alert, revoke a compromised credential, and restore a backup.

Use this inventory format:

Function: production deployment
Account: deployment platform organization
Primary operational owner: engineer A
Backup operational owner: engineer B
Business owner: founder
Login method: individual SSO account
Recovery mailbox: company-controlled mailbox
Billing owner: finance@company domain account
Break-glass procedure: documented in operations runbook
Last verified: [date and initials]

Function: error monitoring
Account: monitoring organization
Primary operational owner: engineer B
Backup operational owner: engineer A
Business owner: founder
Login method: individual account with MFA
Recovery method: company-controlled administrator account
Break-glass procedure: documented in operations runbook
Last verified: [date and initials]

Test the recovery route, not merely the normal login. The unavailable engineer may own the authenticator, recovery email, domain registrar login, cloud billing profile, signing certificate, app store account, or the personal card that keeps a provider account paid. Any one of those can make a technically capable team unable to operate.

Treat four conditions as automatic failures:

1. A production or customer account has only one human administrator.
2. Recovery depends on an employee's personal email address, personal phone, or personal payment method.
3. The company cannot identify who can change billing, security, or identity settings.
4. The drill requires a shared root credential because individual access does not exist.

Do not solve this by granting every engineer unrestricted administrator rights everywhere. That merely changes an ownership failure into a security failure. Give people the access their operating role requires, keep emergency elevation controlled and logged, and make the recovery procedure executable by someone other than the person who set it up.

Score evidence with a hard failure rule

A useful scorecard separates routine friction from conditions that make safe operation impossible. If you use only a five-point average, a team can offset an inaccessible production account with a quick support response and claim the week went well. That is nonsense.

Score each control from zero to four:

Give each of the four areas its own score. Then mark hard failures separately. A hard failure blocks any claim that the company has continuity, regardless of the average score.

Hard failures include an unapproved high-risk release, no rollback route for the release attempted, inability to access or recover a production-critical account, an incident with no accountable decision maker, and a customer promise that the company cannot support with evidence.

Use a written scorecard with rows that describe observable controls rather than vague categories.

Area: release safety
Control: Available engineer can identify deploy artifact and execute rollback.
Evidence: deployment job record, rollback test result, release note.
Score: 0-4
Owner for gap: [name]
Fix due: [date]

Area: access ownership
Control: A backup administrator can recover monitoring access without the unavailable engineer.
Evidence: recovery login performed or documented recovery exercise witnessed.
Score: 0-4
Owner for gap: [name]
Fix due: [date]

The score is not a performance review of the engineer who remained available. Most low scores reveal leadership decisions made earlier: undocumented architecture, rushed vendor setup, no release policy, ownership that followed convenience, or a founder who approved exceptions without recording them. Treat the results as a map of operating debt.

Fix the smallest dependency that removes the risk

After the drill, teams often create a giant "improve documentation" project and then return to feature work. That project fails because it has no boundary and no evidence of completion.

Convert each failed control into a small operational change with a test. If the remaining engineer could not find the queue dashboard, create a service page that links the dashboard, names the alert owner, lists the normal range, and explains the first two diagnostic checks. Mark it done only when the other engineer uses it successfully without coaching.

If a release lacked an independent reviewer, do not write "add more review." Set a rule for which changes may ship solo, identify the decision owner for exceptions, and add a release record template to the workflow. Then run a bounded change through it.

If a vendor account had a sole administrator, assign a backup administrator, move recovery to a company-controlled address, verify billing ownership, and perform recovery in a controlled session. Do not wait for the next drill to find out whether the recovery mail reaches the right place.

Prioritize work in this order:

1. Remove hard failures that could stop production operation or cause irreversible customer harm.
2. Reduce dependencies that force one engineer to make a high-risk decision alone.
3. Turn repeated search and chat archaeology into short, tested runbooks.
4. Improve convenience after safety and ownership work is complete.

Keep a before-and-after record. The next drill should repeat the failed task first. A policy change without a second observed attempt is a promise, not proof.

AI can reduce lookup work, but it cannot own accountability

AI tools can make a two-person team faster at finding runbooks, summarizing incident timelines, drafting tests, and tracing a change through an unfamiliar code path. They do not make a solo release safe if nobody can approve the risk, verify production behavior, or recover the account that runs the service.

Use AI during the drill only under the same rules as normal work. The available engineer may ask it to explain a repository or create a draft. They still need to validate the answer against the code, logs, and operating records. If the team cannot tell where an answer came from or how to check it, the tool has added speed without control.

This is where a Team & AI Audit earns its keep: it can separate work that an AI-augmented engineer can safely absorb from work trapped in one person's access, judgement, or undocumented history. The continuity drill gives that conversation evidence instead of optimism.

Run the next drill after you fix the hard failures, not after you write a retrospective. A one-week absence should change your delivery pace. It should not make the company guess who owns production, whether a release can be reversed, or what a customer deserves to hear.