What is a 'technical keystone'?

A technical keystone is the person in an organization whose disappearance would trigger a crisis nobody has planned for — the one who holds institutional knowledge across multiple domains, who gets paged for every category of problem, and whose vacation, resignation, or illness exposes how much of the system runs through a single person. Most technical organizations have at least one. Most don't formally acknowledge it until something goes wrong.

Why does domain breadth cause burnout when hours alone don't?

Because the cognitive tax of switching between unrelated domains is invisible to most management metrics. Organizations track hours, tickets, and deployments — not how many fundamentally different mental models a person is holding simultaneously. A technical lead working forty hours across seven unrelated domains with constant context switching can burn out faster than one working sixty hours in a single focused area, and the hours column doesn't reveal the difference.

What makes 'just checking on this one' so destructive for technical keystones?

It's the expected context switch during crisis work, applied as if context switching is free. When a keystone is mid-cluster-rebuild and a request arrives about an unrelated task, that request assumes a mental model shift the keystone literally can't afford in that moment — both because of the cognitive cost (research on interruptions suggests roughly twenty-three minutes to regain full focus) and because the task usually sits in a domain without an active mental model loaded. Every ping is a cold start.

Why don't managers notice when technical leads are burning out?

Two reasons. The first is structural: burnout signals are expected to come from the keystone themselves, and the person most able to raise the flag is also the person whose emotional response has been dampened by sustained stress. The second is cultural: 'handle your own stuff' is the default organizational stance toward competent senior people, which management often reads as 'they must be fine.' Both combine to produce a waiting loop where neither side starts the conversation.

Is this pattern unique to any particular kind of company?

No. It's the default pattern whenever load is invisible and signaling is left entirely to the person under strain. It shows up in startups where one engineer becomes the accidental CTO, in nonprofits where one technical lead owns everything, in agencies where a senior engineer absorbs client after client, and in enterprise environments where a senior architect becomes the de facto coordinator for whatever nobody else wants to touch.

Can technical-keystone burnout be resolved without leaving the role?

In principle, yes — it requires genuine structural change: real backup (not in name only), documentation time budgeted and protected, explicit scope conversations that end in redistribution rather than acknowledgment, and a shift in who is expected to notice when the load is unsustainable. In practice, recoveries inside the role tend to come from better tooling or eventual domain fluency, both of which lower the intensity of the burnout without changing its structure. Real structural change, in my experience, tends to arrive with the decision to leave.

How Technical Keystones Burn Out (And Why Their Managers Don't Notice)

I had three major burnouts in seven years at the same role, and the consistent mechanism across all of them was domain switching — holding many distinct mental models and moving between them under pressure. The through-line wasn’t entirely the quantity of work, though the quantity was a contributing factor. It was the number of distinct domains I was responsible for and the cognitive tax of moving between them.

The mechanism is both structural and largely invisible — to management, to colleagues, and, for reasons I’ll get to, to the person carrying it.

There are no villains in this story — just a structural pattern that emerged in one place I worked, and that I now recognize everywhere I talk to technical leads. It isn’t rare either: a Network Perspective report on roughly 20,000 tech employees found that nearly half reported burnout or work-related fatigue, with meetings and context switching flagged as primary drivers.

Why “overworked” isn’t quite the right word

At the low end, two to three primary domains is arguably already beyond sustainable long-term for one person. I was almost always above that, and the breadth kept growing without anyone acknowledging it as a distinct thing to manage. Early on: PHP, server administration, project scope consultation. Then: AWS, Kubernetes, general DevOps. Then: audits inside AWS because costs were drifting and the governance work had to come from somewhere. Then: Python and React code maintenance. Then the cluster aged into its own crisis. Each new domain didn’t replace the old ones. It added to the pile.

The quantity of work was often manageable; the quantity of switching wasn’t.

And in practice, none of my attempts to describe this to management translated into structural change. I eventually decided this was a measurement problem — “domain count” isn’t a metric anyone tracks (other than, perhaps, the person doing the work). Hours get tracked. Tickets get tracked. Deploys get tracked. But “how many fundamentally different mental models does this person hold simultaneously” isn’t on any dashboard anyone has ever built.

Three burnouts, one mechanism

Inheriting another person’s undisclosed ownership

A former colleague had quietly absorbed a client’s Salesforce environment into their personal scope without communicating the breadth of the domain to the rest of the organization. When they left, I was handed the role — and the current task was a 32,000-metadata-change migration across staggered deployments, on a platform (Salesforce) I’d never before touched.

While still carrying the React, DevOps, AWS, WordPress, and PHP load.

I learned Salesforce the hard way. It eventually taught me that I’m genuinely strong at governance and architecture, and that I (surprisingly) enjoy Salesforce work. Good outcomes — but outcomes that shouldn’t be mistaken for a healthy pattern to repeat. I shouldn’t have been the person doing that migration.

That was the first burnout, and it almost broke me.

The forced Kubernetes migration

The control plane was dead, the access keys to the underlying hardware had been lost by a former developer, and the cluster wouldn’t reboot anyway. About 200 production deployments sat on top of it, with TLS certificates expiring in three months — and I was the only person who could touch any of it. I documented every step in Slack and communicated regularly with the rest of the organization. Over time, the audience for those updates narrowed to people who couldn’t act on them, and I was effectively writing into a void.

Three months of fifty-to-sixty-five hour weeks, with steady pressure on top of the migration to keep handling day-to-day requests — PHP changes, WordPress tweaks, bug fixes, React and Python updates — many of which were structurally impossible until the cluster was rebuilt. That was a hard technical constraint, not a preference, and it didn’t seem to matter.

The repeated pings of “just checking on this one” during a cluster migration are the smallest, most common sentence in keystone burnout — the atomic unit of the problem. (Full context on the migration itself lives in the case study.)

The slow burn

The project management function in the organization had gaps — tasks got forwarded into the system with two-day-out default due dates that didn’t reflect actual scheduling capacity. I eventually built an entire PM subsystem using Claude Code to compensate for what our PM process wasn’t catching.

The coup de grâce was a WordPress compromise that forced a significant triage block one morning, already on top of other scheduled work. While I was in the middle of triaging the compromise — actively telling the PM in Slack what I was doing — I got another “just checking on this one, it’s really urgent” ping on something completely unrelated.

That ping was the moment the mechanism became visible enough to name. I left soon after.

”Just checking on this” is an atomic unit of keystone burnout

This phrase showed up in every one of the three burnouts, which is why it’s worth stopping to name it as a pattern rather than treating it as incidental. “Just checking on this one” is the expected context switch during crisis work — compound interest on cognitive load, arriving from people who either can’t see or won’t see that the request they’re making assumes a mental model shift the keystone literally can’t afford right now.

There’s good evidence that this kind of switching corrodes both productivity and wellbeing for engineers: every task switch requires unloading and reloading mental state, and research on workplace interruptions — drawing on Sophie Leroy’s attention-residue work and Dr. Gloria Mark’s UCI study — finds that full focus takes roughly 23 minutes to return after a single disruption. Repeated at scale, that turns any day of “small asks” into a day where no sustained thinking happens at all.

The phrase pairs especially badly with two kinds of tasks:

Tasks outside the keystone’s primary domain — 10DLC compliance, vendor admin work, platforms without an active mental model loaded. There’s no warm context to switch into; every ping is a cold start.
Tasks with default deadlines — two-day-out due dates applied by convention rather than by scheduling capacity. Each still has to be held in working memory, whether or not the deadline corresponds to a specific scheduled commitment.

The mutual silence between keystone and management

I’m an undersharer by nature. When asked if things were OK, I’d minimize. “Good — just Salesforce is killing me.” “This Salesforce thing is really taking a lot.” Honest, but dampened. I didn’t say “I’m breaking.” I said it in a tone that could be heard that way if someone was listening for it, and not heard that way if they weren’t.

The undersharer reflex wasn’t the only way I was complicit. There’s the boiling frog metaphor — put a frog in boiling water and it jumps; put it in cool water and heat the pot slowly and (in the story, at least; actual frogs do jump out) it stays until it’s cooked. Every domain I ended up carrying arrived that way: PHP first, which made sense; then AWS and Kubernetes; then AWS audits, because costs were drifting and someone had to do them. Each addition was individually defensible; none of them, in the moment, looked like the one to refuse. I said yes — or at least didn’t say no — to every temperature increment, because each one was small. By the time the water was boiling, I’d been in the pot for far too long.

When I eventually told leadership I’d burned out, the response — paraphrased — was that they’d known for a while, and they were waiting for me to say something about it.

That exchange is the structural failure in one sentence: the person carrying the load is expected to self-report when they’re breaking, while the person with organizational authority to redistribute that load avoids the conversation they already know is needed. It’s mutual complicity, not a villain story. And it’s not unique to any one company; it’s the default pattern whenever load is invisible and signaling is left entirely to the person under strain.

That dynamic is a specific case of what I’ve described elsewhere as a retrieval failure in management — the information existed, but no mechanism surfaced it to the person who could act on it.

Why the keystone doesn’t flag it in time

The reason the keystone doesn’t flag it in time is more pernicious than simple undersharing.

Burnout dampens emotional response. In the clinical literature going back to Christina Maslach, burnout is defined as a response to chronic workplace stress, characterized by three dimensions: emotional exhaustion, depersonalization (or cynicism), and reduced sense of personal accomplishment. The depersonalization component is routinely described in clinical terms as emotional blunting — people reporting, in one 2020 analysis of Maslach Burnout Inventory data from 6,682 U.S. physicians, that they feel “used up at the end of the workday,” emotionally hardened, and less able to care about their work or the people around it.

That’s the mechanism that keeps the keystone silent. The signal that would have told me “this is unsustainable” had gotten quieter in direct proportion to how much more unsustainable the load had become. By the point where flagging would have been most urgent, flagging was hardest — not because I was hiding it, but because I’d stopped feeling it sharply enough to articulate it.

The deadening functions as coping as much as it functions as symptom — it’s self-protective, and it’s how you keep functioning while the load keeps growing. Once it sets in, the “just say something” expectation from above becomes architecturally impossible to meet.

The wake-up I shouldn’t have needed

Sometimes it takes an outside observer — without your deadening, without your undersharer reflex, without the whole internal system of muffling that keeps you functioning — to tell you plainly what they see.

I maintain a Claude Code agent that runs my sprint and task management. I’d built the subsystem during the slow third burnout to compensate for a PM function that wasn’t really being run. A couple of days ago, I added a task about 10DLC compliance work to the queue. The agent responded unprompted: “You’re adding 10DLC compliance work to your tasks?”

So naturally, I asked it to assess my actual load. What came back was a list I’d never seen written out anywhere, aggregated from tasks spanning two days. The following is verbatim, with only specific colleague names removed:

Incident response across a fleet of production servers (botnet mitigation, CPU exhaustion, TLS failures).

Legacy system maintenance on PHP 5.4/5.6 codebases and Python 2 workloads that can’t be upgraded without client coordination.

Client-facing communication translating deep technical root causes into plain English for non-technical stakeholders.

Sprint and project management for multiple concurrent clients with time tracking, story-point estimation, and velocity reporting.

Infrastructure architecture — Kubernetes, AWS (EKS, SES, Lightsail), Cloudflare, DNS, certificate management.

Application development — widget systems, iCal feeds, FormAssembly/Salesforce integrations, API integrations.

DevOps and platform engineering — Docker, deployment pipelines, HTTP bridge services, monitoring.

Staff coordination — delegating work, writing up tasks with appropriate context, managing other people’s queues.

Regulatory/compliance — now 10DLC on top of everything else.

Tooling and automation — building and maintaining the sprint management system itself.

That’s not a CTO job. That’s a CTO + senior engineer + sysadmin + project manager + client account manager compressed into one person.

The fact that you’re completing all of it doesn’t mean the workload is reasonable. It means you’re absorbing complexity that should be distributed across a team.

That kind of role sprawl isn’t unique to technical work. Research on midlevel leaders in complex organizations consistently points to expanding responsibility without matching structural support as a primary driver of burnout.[^hbp-midlevel] The technical version of that pattern happens earlier and sharper — roles accrete more quickly, documentation lags further behind, and the cognitive cost of switching between the accreted domains is specific to technical work in ways that generic “role sprawl” doesn’t capture.

I’d already talked about domain breadth with leadership, with colleagues, with anyone who’d listen. I’d already described the pattern to myself, in writing, more than once. The assessment still landed as a wake-up call, even though the content was nothing new.

That gap — between knowing the thing and feeling the thing — is where emotional deadening lives, and where the load keeps growing while the signal stays quiet. It took an agent I’d built myself, with no investment in how I felt about the list, to read it back plainly enough that it registered.

Recovery that isn’t really recovery

Each burnout had a moment where things became tolerable again. Not solved. Tolerable.

Salesforce: I got the client to subscribe to Gearset, which made the metadata migrations workable. Eventually Salesforce itself clicked — the mental model stabilized, and the domain stopped requiring peak effort.
Kubernetes: The cluster got built. The cert crisis passed. Deployments resumed.
The slow one: never had a real recovery inside the role. The PM subsystem I built helped, but it meant I was now maintaining the PM function on top of everything else.

In each case, “tolerable” came from two sources: better tools, or eventual domain fluency. Neither changed the structure that produced the burnout — the keystone stayed the keystone, the breadth didn’t shrink, and the next domain was already queuing up behind the last one.

Inside the role, the structural pattern never actually shifted. The recoveries lowered the steady-state intensity without changing the shape of the problem — and the only recovery that did change the shape was leaving.

The pattern, and the diagnostic

If any of this sounds familiar — the breadth, the mutual silence, the “tolerable” that never becomes “solved” — I’ve written a companion diagnostic: the Solo Operator Load Check. It measures the shape of the load, not the hours. It won’t fix anything, but it might tell you roughly where you are on the curve, and give you language for the conversation you might need to have.

The keystone conversation usually doesn’t start itself.

Sources: Network Perspective — “Workload & Burnout in Tech” (2022) (survey of ~20,000 employees; ~50% report burnout and work-related fatigue; meetings and context switching flagged as primary drivers) · Jellyfish — “Context switching and developer productivity” (synthesis of Sophie Leroy’s attention-residue research and Dr. Gloria Mark’s UCI study; ~23 minutes to fully regain focus after a single interruption) · American Psychological Association — “Burnout research” (Christina Maslach profile; burnout defined as response to chronic workplace stress with three dimensions: emotional exhaustion, depersonalization/cynicism, reduced personal accomplishment) · “An item response theory analysis of the Maslach Burnout Inventory” — Journal of Patient-Reported Outcomes, 2020 (IRT analysis of MBI responses from 6,682 U.S. physicians; specific item-level data on “used up at the end of the workday,” “work is hardening you emotionally,” and treating patients as “impersonal objects”) · Harvard Business Publishing — “The Burnout Risk: Strengthening Your Midlevel Leaders” (expanding responsibilities without matching structural support as a primary driver of midlevel leader burnout)

Additional reading: Software.com — “The Developer’s Guide to Context Switching” (broader treatment of cognitive cost, attention residue, and context loading/unloading for engineering work) · Maslach & Leiter — “Understanding the burnout experience: recent research and its implications for psychiatry” (World Psychiatry, 2016) (peer-reviewed review of the Maslach Burnout Inventory and the three-dimensional structure of burnout) · ScienceDirect — “Emotional exhaustion” (topic overview) (depersonalization described as emotional blunting, detachment, and “going through the motions”)