Staff engineering
Staff Android engineer is not senior plus
Staff Android work means owning build speed, app health and device fragmentation, and making thirty engineers faster.
6 min read
Audio is currently recording.
A senior engineer is responsible for their own work. A staff engineer is responsible for everyone's. On Android that line carries extra weight, because everyone's work includes thirty engineers, a Gradle build that can outlast a lunch break, and thousands of phone models whose makers all have their own ideas about background tasks.
The usual story goes like this. A company promotes its best senior Android engineer, the one who knows where every old workaround lives and can fix a Compose bug at five on a Friday. Someone tells them to keep doing what they do, just more of it. Six months later they are answering Slack on Sunday, the build is still slow, the ANR rate is creeping up, and the promotion feels like extra work with a new title on top.
Nothing is wrong with the engineer. They're using the habits of a strong senior in a role that needs different ones.
The part nobody puts in the offer letter
A staff engineer has no one reporting to them. When the module structure needs to change, they can't order three teams to refactor. They have to convince the engineering manager, convince product it's worth a sprint, and convince the engineers doing the work that the plan is sound. Every decision passes through people who can say no.
That's why the role has two halves. One is technical judgment about builds, app health and architecture. The other is the conversation around it: when to push, when to wait, and how to get agreement from people who don't report to you.
What the work looks like across a week
On Monday you check two Android system design take-homes. One has a clean diagram and forgets the phone can go offline. The other is messier but starts from offline behaviour. You'd hire the second candidate, and you need feedback the rest of the panel can accept.
On Tuesday you meet the engineering manager. You go through who is stuck and what is at risk, then map module boundaries so three teams can build in parallel without breaking each other. After that you hand out the work, and each engineer hears why their piece matters.
On Wednesday you meet the backend and iOS staff engineers to agree one API contract. The aim is that both apps read the same data the same way, so the same business rule isn't written twice, slightly differently, by two teams that rarely talk.
On Thursday ANRs spike on budget phones after a change to app startup, and store reviews start mentioning freezes. You're first on the line. You may have written none of the change. You go through the profiler traces because you know the whole startup path, and someone needs to stay calm while the dashboard turns red.
On Friday you may be at a client's office, speaking for the mobile team and sometimes for the company.
In between are the harder conversations: explaining why a six-month rewrite to Jetpack Compose would stall the roadmap, showing a senior why their ViewModel setup leaks memory on every screen rotation, and owning a decision when it goes wrong as well as when it goes right. Very little of that week is spent typing Kotlin.
What the job really demands
Four areas come up again and again.
Builds and modules. You own how the app is split and how Gradle builds it: remote build cache, clean feature modules, and rules that stop people coupling parts that should stay apart. When thirty engineers wait twenty-two minutes for every build, that's a cost the business pays in salaries.
App health. You watch Android vitals in Google Play Console. Google Play's bad behaviour threshold for ANRs, the freeze that ends in the app not responding dialog, is 0.47%. Above it, Google can show the app to fewer people and add a warning to its store listing, so the number stops being an engineering metric and becomes a business one.
Fragmentation. Android runs on thousands of devices, and makers such as Samsung and Xiaomi stop background work aggressively to save battery. You build background work on WorkManager and test it on those phones, because WorkManager follows the system's power rules and each maker sets its own restrictions on top.
Force multiplication. You build tools and lint rules, write and check technical assessments, run interviews, and mentor seniors before they hit problems you've already seen.
None of the staff Android job posts asks for the person who closes the most tickets.
Where the senior plus habit shows
During a Compose migration, the senior plus habit is to push for a full rewrite and resent product for saying no. The staff habit is to move one low-risk screen at a time, put Compose inside existing screens with clear boundaries, and teach the team as it goes.
With a new SDK, the senior plus habit is to add the dependency, test on one Pixel and merge. The staff habit is to check app size, cold start time and behaviour on a Xiaomi with battery saver on, then bring product the numbers and a safer option.
With an ANR that nobody can explain, the senior plus habit is to move a suspicious block to a background thread and hope Crashlytics goes quiet. The staff habit is to go through the whole startup path, take disk work off the main thread, and add checks so the rate stays well under the threshold.
When requirements keep changing, the senior plus habit is to complain in the retro. The staff habit is to show what each change costs in slower releases, more crashes and users lost.
The senior solves the problem in front of them. The staff engineer also removes the reason it keeps returning.
Getting there from senior
The title usually follows the work rather than the other way round.
Fix a problem every Android engineer feels, such as long builds, flaky tests or a Dagger graph nobody wants to touch. Write a short plan and fix it with other people.
Keep a record of what changed because of you, with real numbers: build times, ANR rates, teams unblocked. By the time a promotion discussion happens, the details are easy to forget.
Build relationships with backend, product and your iOS counterparts early. Influence takes months to build and can't be borrowed when the big argument starts.
If you're the only person who can fix background work or the release pipeline, you've become a bottleneck. Teach others until they don't need you for everyday problems.
Help design assessments and run interviews. Choosing who joins the team is one of the most consequential things a staff engineer does.
A simple test
Imagine a month away with your laptop off. If the Android team keeps shipping, keeps the architecture you agreed and handles problems without you, you're doing staff work. If every decision waits for your return, the title has changed and the job hasn't.
The same argument for the other platform, with SwiftUI, Swift Concurrency and App Store releases in place of Gradle and ANRs, is in Staff iOS engineer is not senior plus.
