Staff is a change of scope, not a change of seniority

The most common way engineers stall on the way to staff is by trying harder at being senior.

More features, cleaner code, faster delivery, a reputation as the person who can be trusted with the difficult work. All of it real, all of it valued, and none of it a path to the next level, because staff is not senior with more experience. It is a different job with a different unit of output.

Senior output is decisions. You take an ambiguous problem, choose an approach, defend the trade-off, and ship it. The unit is the thing you built.

Staff output is mechanisms. You change how a class of decisions gets made, so that problem stops arriving, including on teams you are not on. The unit is what happens after you leave the room.

That is why the promotion feels arbitrary from inside. You are producing more of one thing while being measured on the presence of another.

What it looks like concretely.

Senior: I found the retain cycle in the media player and fixed it.

Staff: I found it, fixed it, then added a lint rule flagging escaping closures that strongly capture self, plus a test asserting view models deinit after navigation. Now the next one gets caught before review.

Same incident. The second version means one engineer fixing one leak does not have to scale, because it does not have to happen again.

The uncomfortable part. Mechanisms are less visible than features in the short term and more visible in the long term. Nobody thanks you for the incident that did not happen. The calibration committee, however, is specifically looking for evidence that outlived your involvement, and it is one of the few things that reliably distinguishes the two levels on paper.

If you want the promotion, stop asking what should I build next and start asking what keeps arriving that should not.