In which becoming essential turns out to be a kind of failure.
The Peripheral Chair
In most jobs, becoming essential is the goal. You build toward it, make yourself load-bearing, and then you leverage the fact that everything runs through you. This is so basic it barely qualifies as strategy. But: there is a kind of work where becoming essential means you've failed.
The titles vary, the room is the same. A design review, a roadmap check-in, a sync. People who built the thing sit on one side. The people who will live with the consequences sit on the other. And somewhere near the edge, a third kind of person: someone invited to have opinions, whose opinions only sometimes change things.
You can spot this person by posture. They take notes but rarely drive the agenda. Their questions arrive from slightly outside the frame, as if they're watching a different cut of the same movie. When they speak, the room listens politely, the way you listen to a thoughtful stranger at a dinner party. Their input is welcomed, but optional.
The work continues either way.
I should be more precise about the failure. The failure here is a contract so implicit that calling it a contract already overstates its solidity. There are no tasks to miss, no specs to fall short of. There is only a single, unspoken expectation: you are here to make the system lighter, to avoid becoming part of its weight.
The moment your presence starts to feel necessary, the moment a meeting stalls waiting for your sign-off or a decision idles on your opinion, something has shifted. Decision ownership has migrated, quietly, toward someone who was never supposed to hold it. And the people who should carry that weight will eventually resent you for it. They'll be professional about it. But you'll notice the calendar invites arriving later, the docs shared after the comments have already been resolved. The system will route around you. With about as much sentiment.
Here is a scene I keep returning to.
A senior engineer, I'll call him David, is presenting a migration plan. Six weeks of work behind it. The slides are clean, the dependencies mapped, the timeline aggressive but defensible. Fourteen people in the room, most of them checking the plan against their own constraints.
I can see the flaw. The architecture is sound. The problem sits three layers deep: a dependency on a service owned by a team that is about to reprioritize. I know this from months of adjacent conversations. David doesn't have the context. The reprioritization hasn't been announced yet.
I could raise it. The flaw is real.
But the room has already shifted into implementation mode. Questions are about sequencing, staffing, rollout. The plan has momentum. To surface the dependency now would mean reopening the foundation. Best case: a week of recalibration and a stronger outcome. Worst case: a spiral that drains energy, fractures trust, and derails something that was finally moving.
This is where the peripheral chair earns its keep.
Raise the flaw now and you might save this migration. You might also burn credibility that buys you access to the next fifty decisions, some of which will matter more.
You can be right about the dependency and wrong about the intervention. Both at once. There is no clean signal in the moment to tell you which cost is higher.
I stayed quiet.
Two months later, the dependency shifts exactly as expected. The migration stalls. In a one-on-one, someone says it would have helped to know earlier about the reprioritization risk.
I nodded, said the timing was uncertain. Which was true. Also incomplete.
Was I wrong?
I still don't have a clean answer. The role demands optimization across dimensions that refuse to collapse into one axis: precision, momentum, trust, access, long-term influence, short-term outcomes. You weigh them in real time, with partial information, and then live with the result. Sometimes the work is guessing which mistake will cost less.
People who intervene in every flaw eventually stop getting invited. The room does not announce this. The invites stop. Without the room, the peripheral chair ceases to exist. And without the chair, you influence nothing at all.
So the question is never just whether to speak. The question is what this intervention costs across the portfolio of rooms you will sit in next quarter, next year. You have a few seconds to decide.
Timing does most of the work, and I mean this almost literally. Ninety percent of whether advice lands is determined before you open your mouth.
Decisions in organizations have a lifecycle that nobody diagrams. There is a period when a problem is soft, still forming, still open to reframing. This is when constraints can be surfaced, when a question can genuinely redirect thinking. Then the problem begins to harden. Effort accumulates. People commit resources, and then identity. An engineer who has spent three weeks on an approach has stopped evaluating it. She is defending it, and this is simply how human investment works.
The person in the peripheral chair works in the gap between soft and hard. Name the tradeoff while it's still a tradeoff, and you're useful. Name it after effort has hardened into position, and you're a threat. The words can be identical. The reception will be entirely different.
Organizations tell themselves stories too. They call them roadmaps. Once the story has been committed to, challenging the narrative costs more than fixing the flaw. This is irrational, everyone knows it, and it happens every single time.
You learn to read the room for where a decision actually is in its lifecycle, which is often different from where the meeting agenda says it is. A "brainstorm" where the whiteboard is already half-full. A "review" where the real review happened in a Slack thread two weeks ago. A "sync" that is really an announcement wearing casual clothes. Your observations land on something already hardened. The meeting has turned ceremonial, and nobody told you.
The feedback loop in this work runs long. Months can pass before outcomes clarify. So you learn to read small tells because they're the only real-time data you have.
There’s a moment when advice lands wrong. The room stays polite. Attention shifts. You feel the conversation close without anyone naming it.
I've learned to watch for this closely. The accumulation tells you something nobody will say directly: whether your presence is adding signal or noise.
Trust here runs on a strange currency. They're tracking something harder to name: how it feels to think alongside you. Whether conversations end clearer or heavier. Whether your questions opened something up or just added weight. This is why consistency matters more than brilliance. One sharp insight, delivered at the wrong moment or with the wrong tone, can undo months of steady, invisible contribution. I've watched people learn this. They arrive with strong, well-reasoned opinions. They share those opinions freely. They're genuinely confused when the room cools.
Being right was supposed to count.
In technical organizations, being right is table stakes. What people protect is agency. When advice starts to feel like direction, resistance follows, because the contract has been violated. You were supposed to help them think, to think alongside them. The line between helping someone think and thinking for them is rarely clear, and the penalty for crossing it is rarely proportional, and none of that changes how the system works.
Months into a working relationship, if it's working, the texture changes.
Questions start arriving earlier. A Slack message before the doc is finished or a calendar invite for a working session instead of a review. Almost imperceptibly, the ask shifts from tell us what you think to help us think. This is the change. It means the system has decided you're safe to include in the messy middle, before ideas harden, before positions form, while the problem is still soft enough to reshape.
I noticed this once with a team I'd been orbiting for months. Tolerated but yet to be trusted. I knew the difference by then. I'd stayed quiet in meetings where I could have spoken. I'd asked questions instead of offering answers. From the outside, I'd done the thing that looks like very little.
One afternoon, an engineer I barely knew sent me a document. "This is rough," she wrote. "Please don't share it. I'd value your take before I send it around."
The document was rough. Gaps everywhere. Unfinished reasoning, hedged conclusions, the kind of thinking people hide until it's more defensible. Exactly the kind of thing you only show someone you trust to hold your uncertainty gently.
I spent an hour with it and sent back questions instead of answers. Flagged assumptions that seemed to be carrying more weight than they could support. Avoided the word should. Two weeks later, the polished version circulated. I could see my fingerprints in the framing of certain tradeoffs, the way a risk had been recast, a dependency surfaced earlier in the argument. Nobody mentioned my name.
Influence without residue. That's the phrase I keep coming back to, and it sounds noble when I write it down, but I want to be honest: it's also, sometimes, maddening. There is a version of this work that looks, to anyone on the outside, like nothing. The system moves. Decisions land a little faster. Tradeoffs get named earlier. Surprises thin out. Someone references a constraint you surfaced weeks ago without remembering where it came from.
And you sit with that. You sit with the fact that your best work is, by design, untraceable. The system runs a little cleaner. Decisions harden with fewer blind spots. The contribution disappears into the flow of things.
Some people find this intolerable. I understand the impulse. On certain days I feel it too, when the work starts to feel less like influence and more like subtraction.
The role exists because organizations need it, though the need looks different from the way they need engineers or managers. It will never appear on an org chart. It exists because decisions leak. Context fragments. Tradeoffs get optimized locally and show up as global problems no one owns.
That person has no authority. They borrow it, meeting by meeting, for as long as the system feels lighter with them in it. The moment it doesn't, the invites stop. The role was never guaranteed. It was only ever borrowed.
When I try to explain this work to people outside it, I reach for metaphors and they all fall short. It is something other than mentoring, something other than consulting. People sometimes call it "managing without authority," which has always struck me as a comforting fiction, a way to make the absence of power sound like a style of leadership.
It's sitting in a room where decisions are forming, and trying to make them slightly better, and knowing that slightly better is the ceiling, and that even slightly better will go unattributed, and doing it anyway.
The absence of friction never earns attribution. It becomes the baseline.
The room keeps meeting. The system keeps moving. Fewer things break.
Footnotes
The job isn’t to be technically correct in every room. It’s to increase the odds that the business succeeds across many rooms, over time. That sounds rational when I write it down, or tell it to myself.
It’s less clean when you’re sitting there watching a flaw pass unchallenged.
There’s always a temptation to treat each meeting as a referendum on your usefulness. To prove you saw the thing no one else saw, or be the sharpest mind in the room. Yet deployed too often sharpness narrows the set of rooms you’re invited back into.
So you start thinking in portfolios instead of moments. Not out of nobility, but because intervention has a cost, and the cost compounds. Portfolio thinking also makes silence easier to defend. Sometimes that restraint is wisdom. Sometimes it’s avoidance dressed up as strategy. The difference isn’t obvious in the moment, and you rarely get immediate feedback about which one it was.
This posture is unstable. It can look like wisdom or like self-preservation, depending on which outcome you’re measuring.
Quiet influence protects access. It also protects the person doing the influencing from being visibly wrong. The line between strategic restraint and avoidance is thinner than I’d like it to be.
In technical organizations this shows up most clearly in staff and boundary roles: technical program managers, product operations, senior product managers who don't directly own a roadmap but shape three of them, staff engineers whose influence runs laterally rather than vertically.
These roles rarely own the resources required to fix the problems they surface. But they see the dependency graph before anyone else because they're forced to live in it. They notice when two teams are optimizing toward different definitions of success. They understand that a migration plan depends on a service whose owner has quietly reprioritized.
But they can't command alignment, only broker it.
The org chart doesn't describe this work well. Reporting lines capture accountability, but they don't capture coordination load. As systems scale, coordination debt accumulates faster than formal authority expands. The result is a class of roles that exist to manage the overflow.
Their success looks like nothing happening: no incident, no missed dependency, no escalated conflict. That absence becomes the baseline. And because it's absence, it's difficult to reward. The cleaner the system runs, the less obvious their contribution becomes.
Some of the tension in these roles isn't technical at all. It's psychological. You are paid to prevent problems that would never be attributed to you if they occurred. You are measured in part by how little disruption exists. The more invisible the work becomes, the more fragile your claim to it feels.
| Published | 23 January 2026 (1 month ago) |
|---|---|
| Reading time | 12 min |
| Tags | philosophy, effectiveness |
| Views | – |
Reply
I’d welcome your thoughts on this essay. Send me a note →
