From mobile developer to engineering manager: what changes

The first thing I noticed when I became a team lead was not the meetings. It was a pull request. I had opened it on a Friday, a small fix to how our iOS app restored its navigation state, and on the following Thursday it was still sitting there with my name on it and two unanswered review comments. Nobody was blocking it. I simply hadn't had a free hour in five working days.

That was years ago, at a software company in Flanders where I led a mobile team of five: two iOS developers, two Android developers and a tester. I did the job for a little over two years, then went back to writing code full time, and later went freelance. So this is not advice from someone who climbed the ladder. It's a field report from someone who walked up it, looked around, and came back down on purpose.

Your calendar becomes the work

As a developer, a meeting is an interruption to the job. As a manager, the meetings are a large part of the job, and that flip takes months to feel normal. Paul Graham described the split in his 2009 essay "Maker's Schedule, Manager's Schedule": makers need half days in one piece, managers live in hour slots. When you become a manager you are suddenly both, and the hour slots win every fight unless you defend the other kind.

What helped me was boring. I put all recurring meetings on Tuesday and Thursday, left Monday afternoon and Wednesday morning blank, and declined anything that landed there without an agenda. That gave me two real blocks a week for thinking, writing and the occasional bit of code. I also stopped attending meetings where one of my developers was already present and could report back. They knew the details better than I did, and being trusted to speak for the team was good for them.

One more thing about the calendar: other people read it. If yours is full from nine to six, your team will stop asking for time, because it looks like there isn't any. Leave visible gaps.

One-to-ones are the meeting you don't cancel

If you take one habit from this piece, take this one. A thirty-minute one-to-one with each person, every week or every two weeks, on a fixed day, that you move when you must but never drop. The first few feel awkward. Keep going anyway.

The meeting belongs to the other person. I kept a shared document per person with a running list: their topics at the top, mine below, and a line for anything we agreed. Status updates don't belong there; you can read those from the board. The useful questions were plainer than any management book suggests:

• What's slowing you down that I could remove?
• What are you working on that you'd rather not be?
• Is there something you've heard about that you'd like to work on?
• What should I stop doing?

The last one only gets an honest answer after months of trust, and only if you react calmly the first time someone says something uncomfortable. Mobile developers in particular carry quiet frustrations: the release process, being the only person who understands the code signing setup, the Android app always shipping a week after iOS. A one-to-one is where those surface before they turn into a resignation letter.

It's also where growth conversations happen. When one of my developers wanted to go to a conference, we used her one-to-one to agree on what she'd bring back to the team, which made the budget conversation with my own manager short. There's a good guide to getting real value from a tech conference if you're on either side of that request.

Hiring takes more hours than you plan for

Nobody warned me how much time hiring eats. For one iOS position we went through dozens of applications, ran a first call with about a dozen people, and held a longer technical conversation with five. Every step needed preparation, notes and a decision written down while it was fresh. For two months I spent close to a day a week on it.

A few things I would do again. Write the job description from the actual work, not from a template: "you'll own our push notification setup and help us move screens from UIKit to SwiftUI" tells a candidate more than a list of frameworks. Replace long take-home assignments with a short pairing session on a real but harmless piece of code. Tell candidates honestly what the codebase is like, including the old parts. The good ones appreciate it, and the ones who would leave after three months over legacy code leave before they start instead.

If you're hiring for a role you have never done yourself, such as a designer or a backend developer for the API your app depends on, borrow interview questions from someone who has. An overview of the specialist roles an app project needs is a decent place to start when you're not sure what a role should cover.

Saying no, early and with reasons

As a developer you say no to code. As a manager you say no to people: product owners, sales, other team leads, sometimes your own boss. The trick I learned too late is to say it early. A no in the planning meeting costs a few awkward minutes. A no two days before a release, after the build is in review and a marketing email has been scheduled, costs everyone a weekend.

A good no comes with the reason and with what would change your mind. "We can't add offline mode this sprint, because the sync layer needs a rewrite first. If we drop the settings redesign, we can start that rewrite in March." That gives the other person a choice instead of a wall. It also forces you to understand the trade-off well enough to explain it, which is half the job anyway.

Mobile adds its own reasons to be careful. A web team can ship a fix in an hour. Your fix waits for store review and then for users to update. Explain that asymmetry to non-technical colleagues once, clearly, and you won't have to defend every refusal from scratch.

Measuring yourself when nothing ships under your name

This was the hardest part for me. As a developer I could point at merged pull requests and features in the store. As a manager, my output was the team's output, and on a bad week I couldn't tell whether I had contributed anything at all.

I ended up writing a short note every Friday that answered three questions. Did anyone wait on me this week? Did anything reach me late that should have reached me early? Did someone on the team do something they couldn't have done six months ago? Over a quarter, the answers showed patterns. If problems reached me late, people didn't feel safe raising them. If people waited on me, I was holding decisions I should have handed out.

Team numbers helped too, as long as I treated them as signals and not scores: how long a pull request waited for its first review, how often a release slipped, how the crash-free rate moved after each version. None of those measure a manager directly. Together they told me whether the team was getting easier or harder to work in.

Keeping a hand in the code

You should keep some technical work, but pick it carefully. My mistake in the first months was taking a feature on the critical path. Then a hiring week or a reorganization arrived, the feature stalled, and the whole release waited on the person with the least time.

Better choices matter but don't block anyone: the CI pipeline, build times, flaky tests, a small internal tool, the script that bumps version numbers. Code review is the other big one. Reviewing carefully keeps you close to the codebase and shows you how people think without hovering over them. Your bigger technical contribution is steering decisions rather than typing them. The largest one my team faced, whether to keep two native apps or move part of the product to a shared codebase, was never mine to code, but it was mine to frame, and the questions in this guide to choosing a cross-platform framework are close to the ones we argued through.

I also kept one hour a week for release notes from Apple and Google. A manager who doesn't know a deprecation is coming can't plan for it.

Going back is a normal road

After two years I asked to return to a developer role. My manager took it well, partly because I had been honest in my own one-to-ones for months. I didn't leave because I was failing. I left because I missed the specific satisfaction of a hard bug finally making sense, and because I noticed I was more patient with code than with calendars.

Moving between management and hands-on work is common in software, and good companies treat it as a normal step in either direction. The two years made me a better developer: I write clearer pull request descriptions, I estimate more honestly, and as a freelancer I understand what the manager on the client's side is dealing with. None of it was wasted.

A short FAQ

Should I take the job if I'm the strongest developer on the team?

Not for that reason alone. Being the strongest developer means you know the code. It doesn't mean you'll enjoy unblocking others. Ask yourself whether you liked mentoring and reviewing more than building features. If you did, try it.

How much code will I still write?

Plan for very little in the first six months. With a team of four to six, an afternoon or two a week on non-critical work is realistic once the routines settle. With a larger team, expect reviews and design discussions to be most of your technical contact.

Do I need management training first?

It helps, but it doesn't replace practice. A book like Camille Fournier's "The Manager's Path" gives you words for what you're seeing. A manager of your own who holds regular one-to-ones with you is worth more than either.

Can I try it and go back?

Usually, yes, if you say so up front. Agree on a review point with your own manager, after six or nine months for example, and treat it as a real decision rather than a test you might fail.

If you're about to start, do one thing in your first week: book every one-to-one for the next three months before your calendar fills up with other people's plans.