From junior to head of mobile in nine years — the things nobody tells you

I started writing native Android code in 2016. Today I run mobile platforms used by millions, including a multi-tenant Flutter stack across multiple European countries and the native iOS + Android apps for one of Romania's most-respected newsrooms. Along the way, I picked up a Romanian master's, ten certifications, three platforms (iOS, Android, Flutter), and an unhealthy amount of espresso.

People sometimes ask me how that path actually went. So here it is, with the LinkedIn glaze removed.

Year 1–2: pick a platform, drown in it

You will not become senior by reading blog posts about three platforms. You will become senior by shipping in one. I picked Android first. I built terrible apps in private and tolerable apps for clients. I stopped fighting the framework and learned to think like the framework — the activity lifecycle, the fragment manager, the view system. Boring, deep work.

The trap at this stage is wanting to start side-projects in five different stacks. Don't. The compounding interest of one platform mastered will do more for you in year 5 than the spread of five platforms half-known.

Year 2–4: the second platform, and the lesson it teaches

I picked iOS up about two years in. The first months were humbling — you don't realize how much of your "engineering skill" was actually "Android-shaped intuition" until you put it on top of a different system.

The lesson I will pass on for free: the second platform is what makes you an engineer. Not because you suddenly know more APIs, but because you start to see the shape of mobile problems independent of the framework. Lifecycle is lifecycle. Memory pressure is memory pressure. The state machine of a video player is the same shape on iOS as it is on Android. Once you see that, every framework decision starts looking like a vendor dialect of a deeper grammar.

This is also when Flutter starts making sense. If you only know one platform, Flutter feels like cheating. If you know two natively, Flutter feels like physics — you finally have a coherent way to share the parts of the app that genuinely should be shared, and a clean place to put the parts that should not.

Year 4–6: stop being a feature factory

Most engineers plateau here. They become very good at executing the next ticket. They are reliable, fast, and not promotable, because they never sit at the table where the problem is being framed.

What unblocked me at this stage was forcing myself to ask, before every feature, "why are we building this, who is the user, what does success look like, what are we choosing not to do?" — and writing the answers down in 6 lines at the top of the PR description. That habit alone changed how my managers treated me within a quarter.

A lot of seniority is just insisting on knowing why, kindly, in writing, every time.

Year 5–7: own a system end-to-end

I started leading components: the donations stack, the auth flow, the scanner abstraction, the migration off Braintree to Stripe. Each one was a slice of the product I now had to defend in front of stakeholders, monitor in production, and call at 2 a.m. when something broke.

This is where you find out whether you want to be a tech lead or an individual contributor for life. Both are fine answers. Neither is automatically more senior than the other. The forcing function is the same: own the system, including its failure modes.

The single best move I made at this stage was learning to write the postmortem before the outage. When you spec a feature, you write down: "If this fails in production, what is the failure mode? How do we detect it? How do we roll back? Who do we wake up?" If you can't answer those, the spec is not done.

Year 7–9: leadership is product, not org chart

The promotion to head-of-mobile did not feel like a step up the org chart. It felt like a switch in product domain. My product is no longer "the mobile app." My product is "the mobile platform that the mobile team builds the mobile app on."

The difference matters. A head of mobile who keeps shipping features is a senior engineer with a slightly bigger title. A head of mobile who is building a platform — a CI pipeline you can trust, a scanner abstraction every retailer plugs into, a release cadence the QA team can plan around, a hiring funnel that brings in engineers who can keep shipping after you leave — that's the job.

The other half of the job is selling the platform to the rest of the company. Because if the rest of the company doesn't know that the mobile team made it possible to onboard a new tier-1 retailer in six weeks instead of six months, you will not get the budget to make it possible to do it in two weeks next time.

What I wish someone had told me at year 0

• Specialize before you generalize. A T-shaped engineer is the goal, but the vertical of the T has to come first. People who try to start broad never get deep enough at anything to be paid well for it.
• Write more than you think you should. Every important decision lives twice — once in the chat where it was made, and once in the document where it was written down. The second one is what survives. Be the person who writes the second one.
• Pick managers, not companies. A great manager at a mediocre company will accelerate you faster than a mediocre manager at a great company. The first is hard to find; the second is everywhere.
• The compounding currency of this career is trust, not skill. Skill gets you the first job. Trust — earned by shipping reliably, communicating clearly, and being honest about what you don't know — gets you every subsequent one.
• Get real about money. Negotiate. Always. Quietly, politely, with data, and never with a threat. Compounding the salary curve over a decade is worth more than any single bonus you will ever get.

What I'd do differently

I'd have stopped saying yes earlier. The most career-limiting thing a junior does is take every project. The most career-limiting thing a senior does is keep taking every project.

Saying no — to features, to teams, to entire engagements that aren't a fit — is a senior skill. I learned it later than I should have. So this is me telling you to learn it earlier.

And the espressos?

Three a day. Sometimes four. The real number is between me and my barista.

If you're walking this same path and want to compare notes — contact@milannialsoftware.com is open. The best part of doing this work is meeting the people doing it alongside you.