A quieter diagnostic
Are you the keystone?
A 2-minute honest load check for anyone carrying a one-person technical stack — cloud, DevOps, incidents, legacy code, WordPress, a few hundred repos, and whatever else has ended up on your plate.
Anonymous. Nothing's sent anywhere unless you choose to at the end. Take it on your work laptop.
Where the load shows up
What this diagnostic measures
Breadth alone isn't burnout. Breadth plus primary responsibility plus constant context-switching plus no recovery window plus thin documentation — that's burnout. This check looks at six dimensions that, in combination, predict whether you're the structural single point of failure in your organization.
Breadth
How many distinct domains you're the primary responsible person for — cloud, DevOps, legacy code, WordPress, CRM, whatever.
Scope drift
How far your actual responsibilities have drifted beyond your job description — accumulated scope nobody pushed back on.
Load-bearing risk
What actually happens if you disappear for a week. Not what leadership would say — what the calendar would do.
Recovery debt
How long since you took real PTO — not "I took a day and answered Slack from the couch." 5+ days actually unplugged.
Context switching
How often you swap unrelated domains in a single day. The cognitive tax nobody accounts for when they hand you "just one more thing."
Documentation gap
How much doesn't exist for someone else to pick up. The honest answer, not the "there's a wiki somewhere" answer.
Who this is for
This is for the person carrying the load. The accidental infrastructure lead. The one-person IT department at a company that doesn't realize it's a one-person IT department. The senior engineer who became the unofficial CTO because nobody else could be. The DevOps person who's also the incident commander, the database admin, the Python 2-to-3 migrator, and the WordPress security officer, and still has their actual job to do.
I built this after realizing I was the keystone at a place I worked at for seven years — AWS, EKS, Kubernetes, incident response, legacy Python (2 and 3), React, WordPress, Salesforce, Lightsail via Gridpane, and several hundred CodeCommit repos. The context-switching alone was brutal. The diagnostic you're about to take is the one I wish someone had handed me three years earlier.
For the full argument behind this diagnostic — what domain-switching burnout actually looks like from the inside, what management misses, and why "tolerable" never becomes "solved" — read How Technical Keystones Burn Out (And Why Their Managers Don't Notice).
Built by Alex van Rossum, a fractional CTO who spent seven years as a technical keystone. Learn about working together.
Frequently asked questions
What does "the keystone" mean in a technical context? +
A keystone is the load-bearing person in a technical organization — the one who knows how everything fits together, holds the institutional knowledge, and keeps multiple systems running through sheer presence. If they disappear, the arch collapses. Most organizations have at least one, and most keystones don't realize that's what they've become until it's costing them personally.
Why is being the keystone a problem? Isn't it valuable? +
It's valuable to the organization in the short term and catastrophic to everyone in the long term. For the keystone: burnout is mechanical, not a character flaw — breadth plus primary responsibility plus constant context-switching plus no recovery window equals exhaustion. For the organization: the keystone is a single point of failure. When they leave (and they will), the org loses years of context that was never documented because there was no time to document it.
Isn't this just what senior engineers do? +
No. A senior engineer has deep expertise in a domain. A keystone has unavoidable responsibility across many domains — often because nobody else in the org can do any of them. The difference is replaceability. Senior engineers have peers. Keystones don't.
What does burnout from being the keystone actually look like? +
It doesn't usually look like dramatic collapse. It looks like constant low-grade exhaustion, missing your kid's soccer game because a cert is expiring, resentment at colleagues who get to "just do their job," inability to take real vacation, Sunday dread that starts Friday evening, and a creeping sense that you're more irritable at home than you used to be. The body keeps the score before the résumé does.
How is this different from just having a lot of responsibilities? +
Breadth alone isn't the problem. Breadth plus context-switching plus no backup plus no documentation plus no real PTO — that's the problem. Lots of senior people have broad responsibilities with proper structure around them. This diagnostic looks at the structure, not just the scope.
Can one person fix this? Or does it require organizational change? +
The keystone individually can start building off-ramps — documentation, cross-training, explicit scope negotiations — but the structural fix requires the organization to decide it's a priority. Most organizations let keystones emerge because it's cheaper than hiring properly; they don't address it until the keystone leaves. The strongest move is often to change that math — make the risk visible before it becomes a crisis.
Is this diagnostic anonymous? +
Yes. Nothing you select or answer is transmitted anywhere unless you choose to send a message at the end. No cookies, no analytics beyond the standard site-wide tracking, no form submissions unless you explicitly fill one out. Take it on your work laptop if you want.