Only Dave knows how it works. Dave gave notice.
He built it, he named it, he is the only one who has ever restored it. The handover plan is four weeks of meetings and a document nobody will read at 3 AM. If only one person knows how a system works, it is not production-ready, whatever its uptime says.
What the notice period exposes
The resignation is not the problem. It is the audit. It reveals every decision that was never written down and every step that was never automated.
The engineer who built and operates your infrastructure is leaving, going on leave, or has become the single approval path for everything.
-
“Only Dave knows how the infrastructure works, and Dave just gave notice.”
The continuity of production now depends on one person's remaining calendar and their willingness to answer calls afterward.
-
“We can't recreate our production environment if we had to.”
There is no reproducible definition of the system, so knowledge transfer is a conversation rather than a handover.
-
The deployment runs from one workstation with one set of credentials.
Releases stop the moment that account is disabled, which offboarding will do on a fixed date.
-
Every architectural question ends with "ask him".
Decisions were never recorded with their trade-offs, so the next engineer will change things without knowing what they were solving.
-
The runbooks exist, but only for the parts he thought were hard.
The undocumented parts are the ones he found easy, which is exactly where a stranger will fail.
What the gap costs
Key-person risk is cheap right up to the day it is not, and then it costs whatever the business does per hour.
- A freeze you did not schedule
- Teams stop changing anything they do not understand, so delivery slows for months around a single departure.
- Recovery you cannot test
- A restore nobody has performed is an assumption. With the author gone, nobody can convert it into a fact.
- A premature, expensive hire
- Hiring under pressure produces a replacement chosen for availability, who then inherits an undocumented system and becomes the new single point of failure.
- Security exposure at exit
- Credentials, keys and accounts held by one person are hard to inventory and harder to revoke completely.
- Institutional memory
- Why the database lives where it does, why that subnet is different, what broke in 2024. None of it survives the last day.
What we do about it
We convert one person's knowledge into three durable things: code that defines the system, documentation written for a stranger, and a team that has performed the tasks.
-
Put the system into code, in your repositories
Infrastructure becomes a reviewed definition in your own GitHub organization rather than a state that exists because someone once clicked correctly.
-
Write the decisions down, with their reasons
Architecture decision records, runbooks and troubleshooting entries that assume the reader was not there when the decision was made.
-
Distribute ownership deliberately
Code owners on every sensitive path, a responsibility matrix that names roles rather than people, and production approval that requires a review rather than a person.
-
Cover the gap while you hire
Managed engineers can carry the load part-time or full-time during the notice period and the search, then hand over to whoever you hire.
The outcome: Production knowledge lives in code, documentation and a team instead of one person's memory. The departure becomes a normal staffing event, and the next engineer starts from a system they can read.
What that is, in the portfolio
-
BuiltForProd Baseline
A multi-account cloud foundation in OpenTofu and Terragrunt, customized for your organization, deployed into your accounts by our engineers, then handed over with the repositories and the documentation.
-
BuiltForProd Managed
Experienced engineers who operate, secure and evolve production as an extension of your team, working through your own access, pull requests and pipelines.
-
BuiltForProd Assessment
A fixed-fee assessment of what you run today against the eight properties of the BuiltForProd Standard, with a prioritized gap list at the end.
What you get
-
A reproducible definition of production
The environment defined entirely as infrastructure code, so it can be planned, reviewed, rebuilt and reasoned about without its original author.
-
Documentation written for the newcomer
Runbooks, decision records, troubleshooting entries and upgrade guides, with every example showing your own accounts, domains and regions.
-
A responsibility model
Named roles across teams, code owners on sensitive paths and an escalation path that does not resolve to one mobile number.
-
Proof the team can operate it
A hands-on handover where your engineers perform the real tasks themselves, including a change, a review, an apply, a promotion and a secret rotation.
-
Access that can be revoked cleanly
Single sign-on with defined permission sets, no long-lived cloud keys, and offboarding that removes access everywhere at once.
-
Optional cover during the transition
Embedded engineers for six or twelve months while you recruit, working through your own review process rather than becoming the next single point of knowledge.
Every repository and every cloud account stays yours. We keep no standing access after handover. See security and ownership for how that is enforced, and pricing for how an engagement is quoted.
What replaces the knowledge in one person's head
Documentation and ownership are deliverables, with numbers attached.
| What | Figure | Where it comes from |
|---|---|---|
| Documentation set | 794 pages | The documentation behind the platform and the Blueprints shipped today, personalized per customer. |
| Troubleshooting entries | ~160 symptoms | Each with cause, fix and prevention, in the same documentation set. |
| Handover tasks performed by your team | 11 tasks | Completed unaided in the handover session of every engagement, covering access, change, review, apply, promotion, drift and secrets. |
| Responsibility matrix | 12 roles, 6 teams | The operating model documented with the AWS Enterprise Baseline. |
| Drift detection | Daily and weekly | The AWS Enterprise Baseline checks critical accounts daily and all accounts weekly, opening an issue when reality and code disagree. |
The same evidence is documented page by page in the product documentation and measured against the BuiltForProd Standard.
How it works
Four steps from the first conversation to a platform your team owns.
-
Map what only one person knows
We work through the systems, the manual steps, the credentials and the decisions that exist nowhere but in their head, and write the list down.
-
Decide what to rebuild and what to document
Some of it should be captured as it stands. Some of it should be replaced with something a team can operate. We scope both and quote a fixed fee.
-
Deploy, document and distribute
The foundation is deployed into your accounts, decisions are recorded, ownership is spread across named roles and code owners.
-
Prove the transfer
Your remaining engineers perform the operational tasks themselves before we finish, so capability is demonstrated rather than assumed.
Yes, but…
The objections we hear on the first call, answered plainly.
He leaves in three weeks. Is it too late?
No, but the sequence changes. We prioritize capturing what cannot be reconstructed later — credentials, undocumented dependencies, the reasons behind decisions — and schedule the rebuild work after the departure.
Can we just have him write documentation before he goes?
Ask him to, by all means. The limit is that documentation describing a system nobody else can reproduce is a description, not a capability. The code and the practiced handover are what transfer the ability to act.
Is this not just an excuse to sell us a new platform?
Sometimes the honest answer is that your platform is fine and the documentation is the gap. We will tell you that. If the system genuinely cannot be operated by a second engineer, rebuilding the foundation is the fix, and we will explain why.
Will Managed engineers become the new single point of knowledge?
That is the failure mode we design against. Work arrives as reviewed pull requests in your repositories, documentation is updated as part of the change, and your team keeps final approval on production.
Questions
What is key-person risk in infrastructure?
Key-person risk is the state where one individual holds the knowledge, access or manual steps required to operate or recover production. It is a reliability problem, not a human resources problem: the system cannot be operated, changed or restored without a specific person.
How do we know whether we have it?
Ask three questions. Can a second engineer deploy to production today? Has anyone other than one person restored a backup in the last ninety days? If that person were unreachable for a week, what could not be changed? Any uncomfortable answer is the measurement.
Does this require replacing our infrastructure?
Not necessarily. It requires the system to be defined in code, documented for a stranger and operable by more than one person. Where the existing setup can meet that, we say so.
Can you cover the role while we recruit?
Yes. Embedded Managed engineers work part-time or full-time on a six or twelve month commitment and hand over to your new hire, rather than becoming a permanent dependency.
What happens to his access on the last day?
With single sign-on and no long-lived cloud keys, removing the identity removes the access everywhere at once, and the unused-access report shows anything that was missed.
More answers are in the FAQ and the support center.
Make production survivable.
Tell us what one person knows that nobody else does, and when they leave. We will tell you what can be captured, what should be rebuilt, and how quickly.