Staff engineering
Staff engineers change the decisions a team can make
The platform changes. The staff transition does not: your work must improve decisions beyond the feature and beyond your own presence.
By Mike Salari. Staff mobile engineer · 500+ technical interviews from the hiring side.
3 min read
A staff engineer is not the person who receives the most difficult ticket on iOS, Android, React Native or Flutter.
That can still be excellent senior work. The staff transition begins when your contribution changes which decisions other engineers can make, how safely they can make them and how much coordination the organisation needs afterward.
The unit of ownership gets larger
A feature can be a complete senior responsibility. Staff scope often appears across a boundary: a migration used by several teams, a release system, an architecture decision path, a reliability standard or a platform capability.
Larger does not mean vague. The work still needs a defined constraint, owner, adoption path and evidence that the system improved.
Good judgement must travel
If the decision remains in your head, the team gained an expert and kept a dependency. Staff work converts judgement into an RFC, standard, tool, review model or operating rule that another engineer can apply.
The artefact is how the decision keeps producing value when you are absent.
Influence is constrained adoption
A technically correct proposal can fail because migration cost, product timing, team incentives or release risk make it unusable.
Staff judgement includes those constraints. The goal is a direction that the organisation can adopt without hiding the cost, and that matters more than winning the architecture argument.
Measure what stops happening
Look for repeated escalations, duplicated implementations, late release surprises, decisions reopened in every meeting and work that needs one particular engineer to unblock it.
Staff impact appears when some of those events become rarer because the system changed. That evidence travels across platforms because it measures effect, not syntax.
A worked case: one SDK, two platforms
The same SDK request reaches iOS and Android. Each team asks the vendor different questions and accepts a different startup cost, and the disagreement ends up with whoever remembers the last integration. That is a recurring decision with no path. A small review record gives it one:
| Question | Who answers, with what evidence |
|---|---|
| What product capability needs the SDK? | Product owner names the capability and the alternatives |
| What data can it reach or send? | Security or privacy owner reviews the data flow |
| What does it add to the release artefact? | Each platform owner supplies a comparable build inspection |
| When does it initialize? | Implementing team shows the startup path and how it was measured |
| How is it disabled or removed? | Implementation owner names the control and the coupling that remains |
| Who accepts the remaining risk? | A named owner records the exception and when it is reviewed again |
Pilot it on one planned integration and have another engineer fill it in while you watch where the instructions break. If they need you to interpret every question, you have kept the dependency. Decide in advance whether a vendor update that changes initialization reopens the review. Without that, the record covers the first install and nothing after.
Use the next project as evidence
Choose one recurring decision outside your immediate feature. Name the constraint, write the decision path, make adoption cheap and measure whether another engineer can use it without you.
That is a stronger staff signal than asking for a larger title while the work remains contained inside your own delivery queue.
Altitude is my guide for the staff side of this: systems judgement and the written artefacts that carry it into rooms you are not in.
