Staff engineering
Staff iOS engineer is not senior plus
The staff role means owning scope and decision quality across teams, and making other engineers more effective.
By Mike Salari. Staff mobile engineer · 500+ technical interviews from the hiring side.
6 min read
Audio is currently recording.
A senior engineer is responsible for their own work. A staff engineer is responsible for everyone's. It sounds like a small change in wording, and most people treat it that way when they get the title. Then the first quarter goes badly and they can't explain why.
The usual story goes like this. A company promotes its best senior iOS engineer, the one who fixes the strange crash at six in the evening and merges clean code all week. Someone tells them to keep doing what they do, just more of it. So they take more tickets, answer more Slack threads, review more pull requests. Six months later they are the most tired person on the team, the backlog is no shorter, and the promotion feels more like a fine than a reward.
Nothing is wrong with the engineer. They're using the habits that made them a strong senior in a job that needs different ones. There are thirty developers now, not one, and no amount of extra evenings makes one person's output cover thirty.
The part nobody puts in the offer letter
A staff engineer has no one reporting to them. When the networking layer needs to change, they can't assign it and walk away. They have to convince the engineering manager it matters this quarter, convince product it's worth the delay, and convince the developer doing the work that the approach makes sense. Every decision goes through people who can say no.
So the job has two halves that rarely appear together in a job post. One is technical judgement: knowing which change saves the team a year and which one only looks clever. The other is the conversation around it: knowing when to push, when to give ground, and how to get a yes from someone who owes you nothing.
What the work looks like across a week
Take an ordinary week.
On Monday you check two take-home assessments. One is tidy code that misses what the task was testing. The other is rough but gets it right, including the case where the network drops halfway through. You'd hire the second person, and now you have to write feedback that explains why to an interviewer who liked the first one.
On Tuesday you meet the engineering manager. They own the people, you own the technical direction, and the meeting is about where those two overlap: who is stuck, what is likely to slip, what the team should stop doing. Afterwards you hand out work. One developer takes the networking layer, another takes the migration, and each of them hears why the piece is theirs and how it fits the rest.
On Wednesday you sit with the other staff engineers and decide whether the networking layer moves to Swift Concurrency this quarter or next. Everyone in the room is capable and everyone has an opinion. What carries the decision is a clear account of the trade-offs, because thirty people will work inside whatever you choose for the next two years.
On Thursday something breaks for the business. It might be a crash spike after a release or a partner integration that stopped responding. You're expected to be first on the line, the way an officer is at the front, whoever wrote the code. Someone has to understand the whole system and keep the room calm while the fix is found.
On Friday you may be at a client's office, speaking for the mobile team and sometimes for the company.
Between all of that sit the conversations that don't fit on a calendar: telling product a launch date won't hold, telling a strong senior their design won't survive fifty modules, choosing between two reasonable approaches knowing half the room would have picked the other one. Very little of the week is spent writing Swift.
What the job posts ask for
Real staff mobile job descriptions keep repeating the same list. Set technical standards across several teams. Own the roadmap and the architecture decisions. Review designs and code. Mentor engineers. Run technical interviews and decide on candidates. Take production issues and find the root cause. Make the whole team faster.
None of them asks for the person who ships the most features. That's the clearest sign the role measures something else.
Where the senior plus habit shows
The difference is easiest to see in situations every iOS team has.
When the team argues about SwiftUI and UIKit, the senior plus habit is a long Slack message explaining which one is better. It collects reactions and changes nothing. The staff habit is a one-page set of rules for mixing the two, so people can ship on Monday and move screens over gradually.
When product asks for a new analytics SDK, the senior plus habit is to add the package, see it build and merge. The staff habit is to check what the SDK pulls in, how much it adds to app size and launch time, and to go back to product with those numbers and a cheaper option.
When a crash appears that nobody understands, the senior plus habit is to stay until two in the morning and fix it alone. It feels heroic and leaves the team exactly as dependent as before. The staff habit is to fix it once, write down why it happened, add a check so it can't come back the same way, and make sure someone else could handle the next one.
When requirements change for the third time in a sprint, the senior plus habit is frustration in standup. The staff habit is to explain the cost in terms the business already tracks: release dates, crash-free sessions, users who leave.
In each case the senior solves the problem in front of them. The staff engineer also removes the reason it keeps coming back.
Getting there from senior
People rarely receive the title first and grow into it afterwards. More often they start doing the work, and the title follows once enough people have seen it.
Start by looking past your own team. Find a problem that hurts several teams and that nobody owns, such as slow builds, flaky UI tests or a module everyone avoids. Write a short plan, get agreement, and fix it with others rather than alone.
Keep a record of what changed because of you, with numbers where you have them. Promotion discussions happen months after the work, and nobody remembers March unless it's written down.
Build relationships with managers, product and other staff engineers before you need their support. That kind of trust takes a year or two to build, and it can't be borrowed on the day of a hard argument.
Stop being the person who unblocks everyone by doing the work. It looks generous, but it turns you into a bottleneck. Teach people until they no longer need you for daily problems.
Ask to write assessments and join interviews. Deciding who joins the team shows you, faster than anything else, what the company values.
A simple test
Imagine a month away with your laptop switched off. If the team keeps shipping, keeps the decisions you helped make and works from the documents you wrote, you're already doing staff work. If everything waits for you to come back, the title has changed and the job hasn't.
The same argument for the other platform, with Gradle, ANRs and device fragmentation in place of SwiftUI and Swift Concurrency, is in Staff Android engineer is not senior plus.
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.
