The Staff Engineer Role Doesn't Fail on Skill. It Fails on Authority Nobody Wrote Down.

I was fifteen, on a family camping trip at a state park in Vermont, when I learned something about authority that took me another two decades to name. My father had bought a new tent for the trip, still in its original bag, and four years of Boy Scouts had made tent assembly second nature to me. I could see exactly what needed to happen: the poles were mislabeled by the manufacturer, and you couldn't follow the printed instructions literally and end up with a tent. My father is logical and methodical, built from the same materials I am, and I knew exactly how he'd think through it, and I also knew, without being told, that the decision wasn't mine to make.

I offered to help once. He wasn't interested; he was too focused on working the problem himself. So I stopped offering and started watching, until about ninety minutes in, when I saw him converging on the right configuration and saw what came next before he did. I stopped asking and started handing him the next pole he'd need, no explanation, no suggestion, just the right piece at the right moment. He was too focused to notice where the poles were coming from, and that was the point: I'd found the contribution the structure would accept, rather than the one that would have been most direct.

The tent went up in two hours, and he moved on to the next thing immediately. He still doesn't know this happened; he has my first two books, and I've told him I'm working on a third, but he doesn't know this particular chapter exists. What I learned that day: structural position and knowledge competence are different things, and neither one automatically grants the other.

I think about that tent every time I hear the standard advice for a Staff Engineer whose role isn't working. The usual diagnosis is a skills gap, specifically "influence without authority": build more trust, communicate the technical vision more persuasively, find allies, be patient while buy-in accumulates. If that still doesn't work, the fallback diagnosis is that the person wasn't ready for the level, or the org promoted the wrong profile. Either way, the fix is aimed at the person.

Influence without authority sounds like a skill to build. What it actually is: an organization asking a Staff Engineer to manufacture, through personal relationship capital, something that should have been a structural grant, explicit decision rights and a defined escalation path for the exact category of problem they're best positioned to see. That works only as long as that particular person has enough tenure, charisma, or timing sense to make people listen without being told to. It's fragile for the same reason every personality-dependent fix is fragile: the social capital took years to build, and it evaporates the moment that person changes teams, the org reorganizes, or a new VP arrives who's never heard of their reputation.

This is what I callRead Access: knowing precisely what needs to happen without having the authority to act on it directly. What I did with the tent poles, finding the contribution the structure would accept, is a genuinely useful instinct. But it's an individual workaround, not a system, and it only works for the person gifted or patient enough to discover their own version of it.

Every organization that tells its Staff Engineers to develop influence without authority is quietly asking each one to reinvent that same trick alone: find your own way to hand the poles, on your own timeline, reading your own room. Some will. Most won't, not because they lack judgment, but because nobody should have to improvise their way into a voice on the exact category of problem they were hired to solve. The leaders who get this right aren't the ones with the most naturally persuasive Staff Engineers. They're the ones willing to write the authority down instead of waiting for it to be earned all over again by whoever holds the title next.

What has to change is a reliable operating system that converts Read Access into specific decision rights, named in writing, independent of who currently holds the role. That means naming the exact categories of decision a Staff Engineer has standing authority over, so a brand-new person in the seat has the same authority a ten-year veteran spent a decade earning through relationships. It means giving up the comfortable fiction that authority is earned purely through trust, and admitting that if the org actually needs that judgment applied consistently, it has to be granted by the role, not accumulated by the person.

Ask yourself this about your own Staff Engineer or senior IC: if they left tomorrow and were replaced by someone equally skilled but brand new, would the replacement have the same authority on day one, or would they have to spend a year rebuilding the same trust before anyone listened to the same class of call? If it's the second one, the authority was never actually granted to the role. It was on loan from one person's reputation the whole time.

I write about structural leadership for technical leaders in high-stakes operating environments. If you want this depth every month in print, the LeadershipOS™ Inner Circle ships the first of every month. http://LeadershipOSInnerCircle.com