Built to Fail
You took the job because it looked like the right next step. Six months in, you understand exactly why the last person left. The scope was never realistic — and the organization keeps restaffing the role rather than redesigning it, because restaffing feels like progress and redesigning feels like admitting a mistake.
Some roles are designed with a scope that no reasonable allocation of time, authority, or resources could support. The person in the seat changes. The outcome doesn't. Each one arrives confident they'll be the exception, and each one eventually raises the gap and gets the same answer: figure it out, said kindly, as if effort alone should be able to close a gap that was never about effort.
The person in the role now got that answer too. So, probably, did the person before them, and the person before that.
A Pattern the Org Chart Won't Show You
One person struggling in a role looks like a hiring or performance question. The honest test is whether the struggle is personal or structural, and there's a simple way to check it: look at who held this role before, and what happened to them.
If the answer is a string of capable people who each burned out, left, or got quietly moved aside within roughly the same window, the problem was never any one of them. It's the role. Built to Fail names the specific situation where a position has been defined with a scope that exceeds what any reasonable allocation of resources, authority, or time could support. The organization keeps restaffing it rather than redesigning it because restaffing is faster and feels like progress, while redesigning feels like admitting a mistake.
Why the Org Keeps Hiring Into It Anyway
Nobody sets out to build a role nobody can succeed in. It usually starts as a reasonable scope at a different size or moment in the company's life, and then grows by accretion. A responsibility added here because someone needed to own it, another absorbed there because a reorg left a gap... until the role is carrying three jobs' worth of expectation on one person's hours.
By the time it's clearly too much, the organization has a sunk-cost problem of its own. Acknowledging the scope is broken means admitting the last however-many departures weren't performance failures, which is a harder conversation than just hiring the next strong candidate and hoping this one is somehow different. Hope is cheaper than redesign. Less effective, though.
What Six Months In Actually Looks Like
The first few weeks usually feel like onboarding friction: normal confusion, normal ramp-up. Somewhere around month three or four, you begin to realize you cannot remember a week in which everything that was supposed to get done, got done. Not because of any skill gap. Because the math was never going to work.
What the hiring process promised, the authority, the resources, the support, and what actually happens each day are two lines that never intersected after the start date. By month six, the person in the role is choosing daily which fires to leave burning, while quietly absorbing the cost of decisions nobody above them seems to register as a structural problem. The exhaustion isn't from the work being hard. It's from the work being impossible at the pace and with the resources actually provided, while being evaluated as though it were merely difficult.
How to Read the Pattern
The role has high recent turnover, and each departure got an individual explanation. Not the right fit. Needed more support. Decided to pursue something else. Each story sounds plausible alone. Strung together, they're describing the same role, not a coincidence of unrelated people.
The scope was sold differently than it's actually structured. It just never came together the way it was described: less authority, fewer resources, more isolation than the interview suggested.
"Figure it out" is the default answer to structural complaints. When someone raises that the scope doesn't match the resourcing, and the response is encouragement rather than investigation, that's the organization treating a structural gap as a character test.
Why Hiring Better Doesn't Fix It
The instinct, after a departure, is to look for a stronger candidate next time: someone more resilient, more resourceful, better at managing up. Sometimes those competencies help mask the issue longer. They don't change the underlying math, and eventually the same outcome arrives with someone the organization can even less afford to lose.
The role doesn't need a better person. It needs a better design. Less scope, more resources, more information, better role clarity. Without at least looking at it honestly, new hires are at higher risk of repeating the same outcome, and the organization learns the hard way that recurring turnover here wasn't coincidence, wasn't bad hires, and wasn't exactly poor management. It was poor job design and scope creep.
What Has to Change
The fix requires the organization to do the thing it's been avoiding: look directly at what this role actually requires versus what it's actually been given, and close that gap through redesign rather than through the next round of hope. That might mean splitting the role, adding a layer, removing responsibilities that never should have landed in one seat, or genuinely increasing the resources behind it.
What it requires is someone willing to say, out loud, that the people who struggled here weren't the problem, and to treat the role itself as the thing that needs to change.