Everyone's Senior. No One's Staff.

Keavy McMinn got her first principal engineer title by changing companies. In a March 2020 interview, she described leading and architecting difficult, high-impact projects that hadn’t led to promotion. Fastly hired her as a principal. As she put it, “The type of work I was doing didn’t dramatically change.”

From a hiring manager’s desk, senior can be the minimum qualification. From an engineer’s desk, it can also be the ceiling. Her account suggests an awkward possibility: you can recruit for technical leadership that another employer is already getting without recognizing it. An empty slot above senior tells you less about available talent than it appears to.

The reverse mistake is just as possible. Filling a team with senior titles doesn’t establish that someone owns the decisions that cut across its projects. That’s the senior mirage: reading the roster as proof that the hardest technical calls are covered.

In his 2020 account of staff engineering work, Will Larson describes a shift toward setting technical direction and bringing engineering context into organizational decisions. Coding becomes auxiliary to those responsibilities; some of the engineers he spoke with write none. The role adds broader technical leadership while remaining outside people management.

Consider an API change, a change to the interface one team’s software uses to talk to another’s. If the team providing it removes a field before the consuming team stops using it, the rollout can break callers even when both teams have finished their assigned code. Someone has to work out the compatibility period and decide when the old field can safely disappear. They also need to settle what happens if one side has to roll back. More completed tickets won’t settle those questions unless someone has made them part of the work.

Suppose the teams have moved every current caller off the old field. A consumer rollback can still bring an older version back into service. Removing the field at that point takes away that team’s escape route. Keeping it until the teams retire those rollback versions preserves the option. To justify removal, the plan needs evidence about both live callers and versions the teams still intend to restore, including a check that the supported versions work against the proposed provider release.

That plan gives you something better than a title to inspect. If an engineer can show the dependency, test the supported versions, and explain a workable release order, but the teams’ managers won’t move their conflicting commitments, the technical reasoning is available. The people making the commitments still have to decide whether to change them or accept the risk. If the team can’t yet produce the plan, ask what prevents it: unfamiliar failure modes call for different help than an engineer who knows what to check but has no time or access to the other team.

Experience matters here. Enough 2am pages can give an engineer real instincts about what “probably fine” actually means. The useful evidence is what they learned from those pages: which assumption failed, how they found it, and what they changed afterward. Years on a resume give you somewhere to start asking. They don’t answer for the person.

AI-assisted output deserves the same care. A controlled experiment published in 2023 asked developers to implement an HTTP server in JavaScript. Among participants who finished, those assigned GitHub Copilot completed the task faster on average. That result concerns implementation speed on a defined task. It leaves open whether someone can identify the missing coordination in the rollout above. Treating faster code production as evidence of broader technical judgment adds a conclusion the experiment never tested.

That distinction changes the hiring decision. If your screening process treats an advertised experience range as an upper limit, it can reject someone precisely because they’ve spent longer doing the work. Removing that ceiling really does widen the pool. The next step is to examine relevant decisions: ask a candidate to explain a rollout they owned, the alternatives they rejected, and what happened after launch. More years shouldn’t guarantee a pass, but they shouldn’t prevent that conversation either.

Inside the company, look for who already does the work you say is missing. Who gets asked to resolve disagreements between teams? Who notices that a proposed change breaks another team’s assumptions? If an engineer can show that responsibility and wants more of it, promotion can recognize an existing capability. It also needs to change their workload. Asking them to coordinate the migration while holding their individual delivery commitments fixed leaves the conflict in place under a better title.

McMinn described doing the research, presenting tradeoffs, and asking affected teams what she was missing before controversial decisions. She emphasized steering and influencing over telling people what to do. Applied to the migration, that means the technical lead needs access to the consumer team and a way to bring an unresolved conflict to the people who own the commitments. It doesn’t require becoming the approval desk for every release.

Where the experience genuinely is missing, the size of the gap matters. A consequential decision outside the team’s experience can justify a specialist review or fractional technical leader with relevant work behind them. Recurring responsibility for decisions across teams is a stronger reason for an embedded, full-time role. Apply the same scrutiny to outside help: for the API change, a reviewer needs to show which assumptions about consumers they checked and which remain open. Outside help has to learn the system and its constraints; somebody inside still has to own the result.

There may also be no staff role to fill. Larson describes senior as a career level people can remain at. A bounded migration may already have an effective owner in a senior engineer or team lead. If the team’s decisions are being made well at the scope it needs, an empty rung above senior can be an honest description of the organization. Adding staff titles merely to keep promotions moving would avoid the harder conversation about what wider responsibility actually exists.

McMinn described something concrete that came with her principal role: trust, time, and room to work beyond the cadence of scheduled projects. Before opening another requisition, take the next cross-team change and name the person who can assess its risks. Establish whether their findings can change the plan, and which delivery commitment moves so they can follow it through. You may find a missing hire. You may find someone you’ve kept too busy to do the job you need.