The Slack message arrives at 4:47 PM on a Thursday: "Hey, do you have a few minutes to chat?" You already know what is coming. Twenty minutes later, your solo DevOps engineer tells you they have accepted another offer. Their last day is in two weeks.
Your stomach drops. Not because you begrudge them the opportunity. Not because you cannot eventually hire a replacement. The panic comes from a single, terrifying question: who else knows how any of this actually works?
You are not alone. This scenario plays out at growing companies every week. The bus factor problem in DevOps is not about buses at all. It is about the organizational fragility that emerges when critical infrastructure knowledge lives in a single person's head. And when that person walks out the door, they take something far more valuable than their technical skills.
The job posting will say you need someone with AWS experience, Kubernetes knowledge, and familiarity with your tech stack. But what you have actually lost is much harder to quantify and nearly impossible to hire for.
Undocumented runbooks. When the database connection pool starts timing out at 3 AM, your former engineer knew to check the RDS instance metrics first, then the security group rules, then that one Lambda function that was supposed to be temporary but has been running for eighteen months. That diagnostic flowchart exists nowhere except in their memory.
Mental models of failure modes. They knew that the autoscaling group sometimes fails to scale down on Sundays because of a weird interaction with the backup job. They knew that the staging environment shares a NAT gateway with production, so testing large data exports can degrade production performance. These patterns took years to learn through painful experience.
Relationships with cloud support. Your engineer had a rapport with the AWS account team. They knew which support tier to escalate to, which issues to file as bugs versus configuration problems, and which workarounds the support team would actually recommend off the record.
Institutional memory of why things were built a certain way. That unusual VPC configuration exists because three years ago, a security audit required network isolation that the default setup did not provide. The custom health check endpoint was added after an incident where containers kept receiving traffic during deployments. Every architectural oddity has a story, and those stories just walked out the door.
Research from the DevOps Research and Assessment (DORA) group suggests that high-performing teams practice knowledge sharing as a core competency. Yet in practice, most companies with a solo DevOps engineer have made that person a hero, a single point of success and, inevitably, a single point of failure.
It is tempting to blame the situation on inadequate documentation or a departing employee who should have written more things down. This framing misses the fundamental issue. The bus factor devops problem is not a documentation failure. It is an architectural one.
Consider the typical infrastructure evolution at a growing startup. The first engineer sets up a single EC2 instance with a bash script that deploys code from GitHub. As the company grows, they add more instances, a load balancer, a managed database. Each addition comes with its own configuration files, IAM policies, and operational procedures.
By the time you hire your first dedicated DevOps engineer, you have inherited a system that was never designed. It evolved. Your new hire spends their first months understanding the archaeology of decisions made under time pressure by people who are no longer at the company. Then they start adding their own layers.
The bash scripts multiply. The CloudFormation templates grow to thousands of lines. Someone writes a Python script to handle database migrations. Another script monitors certificate expiration. Yet another one rotates API keys. Each script works, but only if you know it exists and understand when to run it.
This pattern creates knowledge silos by design, not by negligence. When infrastructure is assembled from discrete components without a unifying abstraction, understanding requires holding the entire system in your head simultaneously. You cannot document your way out of complexity. You can only hide it temporarily behind a person willing to absorb it.
Infrastructure documentation often fails not because engineers are lazy, but because documenting
an ad-hoc system means documenting everything, every interaction, every edge case, every implicit assumption. The documentation becomes as complex as the system itself, and just as likely to drift out of sync with reality.
The alternative to tribal knowledge is infrastructure that explains itself. This concept has three core components: declarative configuration, self-documenting deployments, and platforms that encode best practices.
Declarative configuration means describing what you want your infrastructure to look like, not the steps to get there. Instead of a bash script that provisions a database, creates a user, sets up security groups, and configures backups, you have a file that says "I need a Postgres database with these characteristics." The platform figures out how to make it happen.
Here is what a complete application configuration looks like with Convox:
environment:
- DATABASE_URL
- REDIS_URL
- SECRET_KEY_BASE
resources:
database:
type: postgres
options:
storage: 100
cache:
type: redis
services:
web:
build: .
port: 3000
health: /health
scale:
count: 2-10
cpu: 256
memory: 512
resources:
- database
- cache
worker:
build: .
command: bundle exec sidekiq
scale:
count: 1-5
cpu: 256
memory: 1024
resources:
- database
- cacheThis single file, a convox.yml, replaces the mental model your departing engineer carried. A new team member can read this file and understand immediately what the application needs: a web service, a background worker, a Postgres database, and a Redis cache. The scaling parameters are explicit. The resource dependencies are clear. The health check endpoint is documented.
Self-documenting deployments mean that the act of deploying produces a clear record of what changed and why. When a developer runs convox deploy, they can see exactly what is happening. The build process, the container creation, the release promotion, and the health checks all produce visible output. There is no black box.
Platforms that encode best practices eliminate the need to make routine decisions. Convox automatically provisions SSL certificates, configures load balancers, sets up log aggregation, and implements rolling deployments. These are not features to be enabled but defaults to be relied upon. Your infrastructure knowledge transfer becomes dramatically simpler when there are fewer decisions to transfer.
To illustrate the contrast, consider what a typical developer needs to know to deploy an application in each environment:
| Concern | Ad-hoc AWS Setup | Convox |
|---|---|---|
| Deploy code | SSH to bastion, run deploy script, check logs on each instance, verify ELB health | convox deploy |
| View logs | Connect to CloudWatch, know the log group naming convention, filter by instance | convox logs |
| Run migrations | SSH to instance, set environment variables, run script, hope nothing times out | convox run web rake db:migrate |
| Scale service | Update ASG, modify launch config, wait for instances, verify registration | convox scale web --count 4 |
| Rollback | Find previous AMI, update ASG, terminate instances, pray | convox releases rollback RABCD1234 |
| Knowledge required | AWS console, CLI, networking, security groups, IAM, instance types, deployment scripts | convox.yml syntax, basic CLI commands |
The left column represents tribal knowledge. The right column represents transferable process. When your DevOps
engineer leaves, the ad-hoc setup requires finding someone who can absorb all that context. The Convox setup requires showing a new developer where the convox.yml file lives.
Transitioning from hero-dependent infrastructure to self-service does not happen overnight. Here is a practical framework with specific milestones for reducing your bus factor over 90 days.
Week 1-2: Audit and inventory. Before changing anything, document what exists. This is not about writing comprehensive runbooks. It is about creating a simple inventory: what services run where, what databases exist, what scheduled jobs execute, what monitoring is in place. Your departing engineer should be able to create this inventory in a few hours if prompted.
Week 3-4: Identify the critical path. Not all infrastructure is equally important. Focus on the deployment pipeline first. If developers cannot deploy code independently, everything else is secondary. Map out exactly what happens when code moves from a pull request to production.
Week 5-8: Implement declarative infrastructure. This is where Convox transforms your situation. Install a Convox Rack in your AWS account and begin migrating applications. Start with a non-critical service to build confidence. The convox.yml format forces you to make implicit configuration explicit.
Week 9-10: Enable developer self-service. Once applications run on Convox, train your development team on the basics: deploying, viewing logs, running one-off commands, and scaling. The CLI reference covers the commands they will use daily. Each developer who can deploy independently reduces your bus factor.
Week 11-12: Document exceptions, not rules. With a platform handling the standard cases, your documentation can focus on what is genuinely unique about your system. The unusual VPC configuration, the compliance requirements, the vendor integrations. This documentation is manageable because it is scoped to actual exceptions.
By the end of this process, your infrastructure knowledge is encoded in version-controlled configuration files, not in anyone's head. A new engineer can read the convox.yml files, understand the architecture, and start contributing on day one.
CTOs and VPs of Engineering often hesitate to invest in infrastructure platforms because the ROI feels intangible. Let me make it concrete.
Hiring a DevOps engineer in 2024 costs $150,000 or more in total compensation, plus three to six months of ramp time before they are productive. If that engineer leaves after two years, you lose most of their accumulated knowledge and start the cycle again. This is not a personnel cost. It is a structural inefficiency.
A platform like Convox costs a fraction of a single engineer's salary. More importantly, it converts infrastructure from a knowledge problem into a configuration problem. Configuration can be version controlled, reviewed, tested, and transferred. Knowledge cannot.
Consider what happens when you need to hire your next infrastructure-focused engineer. With an ad-hoc setup, you need someone who can reverse-engineer your existing architecture, understand your specific tooling choices, and absorb years of operational history. Your candidate pool is small and expensive.
With Convox, you need someone who understands containers, can read a YAML file, and is willing to learn a straightforward CLI. Your candidate pool is enormous. You might not even need a dedicated DevOps hire at all. A senior developer with some infrastructure interest can manage Convox deployments as part of their broader role.
Here is a more complete example of what production infrastructure looks like when it explains itself:
environment:
- DATABASE_URL
- REDIS_URL
- SECRET_KEY_BASE
- SENTRY_DSN
resources:
database:
type: postgres
options:
storage: 200
durable: true
cache:
type: redis
options:
durable: true
services:
web:
build: .
port: 3000
domain: ${WEB_HOST}
health: /health
scale:
count: 2-10
cpu: 512
memory: 1024
targets:
cpu: 70
resources:
- database
- cache
deployment:
minimum: 50
maximum: 200
termination:
grace: 30
worker:
build: .
command: bundle exec sidekiq
scale:
count: 1-5
cpu: 256
memory: 2048
resources:
- database
- cache
timers:
cleanup:
schedule: "0 3 * * *"
command: bin/cleanup
service: workerEvery aspect of this configuration is readable by anyone who joins your team. The scaling parameters are explicit. The health checks are defined. The scheduled jobs are visible. The deployment strategy is documented in the deployment block.
This is what infrastructure knowledge transfer looks like when it is built into the system rather than bolted on afterward.
The bus factor problem will not solve itself. Every day you operate with critical infrastructure knowledge in one person's head is a day you accept existential risk to your engineering organization. The question is not whether your solo DevOps engineer will eventually leave. The question is whether you will be ready when they do.
The path forward starts with acknowledging that documentation is not the answer. Simpler infrastructure is. A platform that encodes best practices and exposes configuration instead of requiring expertise transforms your risk profile overnight.
Your developers are capable of deploying code. They are capable of reading logs and scaling services and running migrations. They just need infrastructure that lets them do it without becoming infrastructure experts themselves.
If you are facing this situation right now, Convox can help. The platform deploys into your own AWS account, so you maintain full infrastructure ownership while eliminating the operational complexity that creates knowledge silos.
Create a free account and deploy your first application. The Getting Started Guide walks through installation and your first deployment in about 30 minutes.
For teams with compliance requirements or complex migration needs, reach out to our team to discuss how Convox fits your specific situation.
