I have been there myself multiple times. An app gets kicked off with a bunch of engineers. The code grows, the team grows more. Decisions need to be taken and suddenly one engineer bears the brunt.
An architecture call needs to be made? They spearhead the evaluation. A tricky thing needs to be built? They are the ones doing it. A new hire joins? They run the onboarding. The PM needs a sparring partner for critical roadmap calls? The call goes directly to them.
Nothing about their title or their comp band has changed. They are doing the job anyway and gravity does the rest.
This is the accidental iOS team lead, and it’s one way a bus factor of 1 forms. Not through some architectural sin. But through a quiet accumulation of responsibility that nobody ever decided to hand over. Which means the fix isn’t technical either. It’s a decision, and there are only two honest versions of it: ratify, or rotate.
Not doing either is a gamble that might cost you the engineer. It’s a gamble because they already know that they are doing the heavy lifting and are not getting the recognition and the pay. They are not formally in charge and thus have the classic “responsibility without authority” dilemma.
If they were formally in charge, they’d get an incentive to stay and the official backing to grow into the work they already do.
People in this position rarely decide to look for opportunities. They just get an email from a recruiter on a Tuesday, and for the first time the idea of leaving isn’t unthinkable anymore. The “open for opportunities” flag on LinkedIn might just follow out of curiosity.
It’s tempting for an org to let things slide here. After all, someone is doing more work for the same pay. Acknowledging it out loud would cost money, so it’s easier not to look.
Recognize the shape
If you have a smoothly running iOS team without an explicit lead, chances are good you might already have an accidental lead. It’s easy to miss because nothing on paper says “lead” and they are just quietly doing the work that needs doing.
If that gets you wondering, evaluate the following signals:
- When iOS needs to be in a room, they’re in it.
- When something breaks on release day, the message goes to them.
- When a new hire wants to know something, the message goes to them.
- When the PM needs technical consultation on the roadmap, the message goes to them.
- The vast majority of architecture & onboarding docs is written by them.
- The team watches their reaction. In planning, people glance at them before anyone commits to an estimate.
Do you see a pattern? If so, you should start planning a conversation now.
You have an accidental lead. Now what?
Congratulations. You might get to skip hiring an unknown engineer who needs onboarding. They already proved they are capable. But it doesn’t mean they want the responsibility.
It might mean they want it but don’t get the support they need to do that job as well as they could. In that case you need to make sure to give them the support they need: ratify.
It might also mean they do it because they really like their work but are slowly getting overworked. In that case you need to find someone to take that responsibility off their plate: rotate.
I have been in that situation. I’m not with that company anymore. What could have changed that outcome?
A guide
This is a loose script that might have made me stay. Adapt it to your needs, use it as inspiration, do your own thing. The important message is: you need to address the situation and give the choice to your engineer.
For example:
“I want to check something with you. As far as I can tell, you’ve been unofficially running iOS. The architecture calls, the PM scoping, stakeholder reporting, where the new hires go. Is that how it feels from where you sit?”
What’s the reaction? I would have said “I mean, someone had to”. If they deny, something is off.
Follow that up with:
“You’ve slid into that role over the last months, you just haven’t had the title or the band. I think we should fix that. And I want to know whether you actually want it, because the honest answer might be no.”
In my case, I would have agreed. I have colleagues, though, who really don’t want that job. Make room to have that choice. If your engineer is approaching overwork, you don’t want to push them into doing more.
It might also be that they want it but are not ready and feel overwhelmed with the prospect. This is also fine: you can now plan how to get the engineer there.
Choice one: ratify
If they want the job, ratify. That is not “give them the title.” It’s four steps, in this order:
- Name the role privately, first. The conversation above. It comes before any paperwork and any announcement.
- Move the comp band together with the title. A title without the band is a way to get more work for the same money, and the person doing the work is the first to notice.
- Put the decision rights in writing. The team needs to know the architecture call is theirs to make, not a thing they do until someone objects.
- Announce it as catching up to reality, not as a promotion. “We’re promoting them” invites the question why them. “They have been running iOS for six months, we’re catching the title up” invites nobody to question anything. Everyone already knew.
I’ve been on a team where the “we’re promoting them” framing triggered exactly that question. The other senior resigned over it.
And there is a fifth step most orgs skip: keep supporting them after the announcement. The accidental lead learned the job by improvising it. Nobody taught them how to delegate, how to say no, how to grow the engineer next to them. They might not know how to navigate politically difficult settings. Ratifying means investing in exactly that: coaching, a manager who makes time, and active help with handing their knowledge to the team. The accidental role made them a bus factor of 1. The formalized role has to include undoing that. Hand them the tools.
Would this have kept me back then? Yes. Not because of the title. Because the band and the backing would have told me the company saw what I was already carrying. And because I would have gotten to learn more.
Choice two: rotate
Sometimes the honest answer is no. That’s not a failure, it’s a valid path and it’s important not to see this as weakness in your engineer. They know their limits. This is good. Plenty of excellent senior engineers drift into lead-shaped work because the gravity pulls them in, not because they want the job.
You can usually see it in their calendar: standups, cross-team syncs, the PM relationship, the hiring loops. But nothing substantial shipped in months. The work they actually care about sits untouched, because they never get a clear week.
Rotating means handing the lead-shaped work to someone else: a new hire, an existing manager, a fractional. The trap is that it reads as a demotion if you frame it as taking something away. So frame it as giving something back:
“You’ve been holding the coordination together, and you’ve done it well. But it ate the work you actually came here to do. I want to take that load off you so you can get back to it. Does that sound like relief, or like a loss?”
The colleagues I mentioned, the ones who really don’t want that job, would take that offer on the spot. For them it isn’t a demotion. It’s getting their actual job back.
The rotate conversation only goes wrong when you decide the answer for them. Ask, and let the exhale (or the flinch) tell you which path you’re on.
What if you do neither?
There is a third option, and it’s the one that costs you the engineer: the maybe.
The accidental lead finally works up the nerve to ask.
“Am I the lead here, or what?”
and the answer comes back:
“Let’s see how the next quarter goes.”
It sounds reasonable. Who wouldn’t want another quarter of evidence? But to someone who is already doing the job, “let’s see if you can do the job” is a no. They hear it precisely. And the next recruiter email lands on fertile ground.
A clean no is survivable. “We’re not creating a lead role this year, and here’s why” is a disappointment the right person can plan around, because at least it’s a decision. A maybe is not a decision. It’s asking the person to keep doing the bigger job on the smaller band, indefinitely. Nobody who has options stays for that.
If you can’t ratify yet, say no. And say when you’ll revisit it, with a date. A no with a date is a plan. A maybe is a slow goodbye.
And if you’re the engineer in this
Everything above is written for the person who can hand you the title. But you might be the one reading this from the other side. The one who runs the team, without anyone having said so. What can you do yourself?
Name it. The mistake is waiting to be noticed. You’re in this situation because you’re not being noticed. That’s the whole problem. Raise it first, and raise it as an observation, in a 1:1. Not in front of the team. Not in the heat of a loaded moment. Not as a demand.
“I want to name something. Over the last few months I’ve slid into running iOS. The architecture calls, the PM scoping, stakeholder reporting, onboarding new hires. I don’t have the title or the band for it, and I think we should talk about whether that’s the direction or not.”
That sentence changes the dynamic. You’ve stopped doing the job on spec and started asking for a decision. Decide which answer is yours. Before the conversation, not during it.
Two honest questions for yourself. Don’t conflate them: “Do I actually want this role?” and “Do I want my craft back?”
Plenty of excellent engineers drift into lead-shaped work because the gravity pulls them in, not because they want it. If the honest answer is “I want to build, not coordinate,” that’s not a weakness to hide. It’s the most useful thing you can tell your manager. Ask them to rotate the load off you.
If you do want it, ask for the whole thing, not the title. A title without the band is more work for the same money, and you’ll be the first to notice. Ask for three things, in writing: the comp band that matches the title, decision rights the team actually knows about, and support to grow into the parts nobody taught you. Delegating, saying no, handing off what only you know. Wanting the role but feeling unready is normal. Name that too, and turn it into a plan.
Recognize the maybe, and refuse to live in it. “Let’s see how next quarter goes” is a no wearing a nicer jacket. Don’t accept it as an open loop. Ask for a date:
“OK, but as I’m already doing the work, I’d like a point where we actually decide. Can we put a date on it?”
And until that date arrives, make the work visible. Not to build a case against anyone, but to close the gap between what you do and what gets seen. When you make the architecture call, settle the release-day fire, or unblock the new hire, say so where your manager can see it: a line in the standup, a note in the 1:1 doc, a short message that names it as lead work rather than letting it disappear into “just helping out.”
Don’t start doing more than you’re already doing. But make it visible. And that record is yours to keep. Bring it to the next conversation wherever you have it.
A no with a date is something you can plan around. And a maybe isn’t a decision. You don’t have to be the one who stays for it.
The cheapest move in iOS leadership
Naming the accidental lead costs nothing. No headcount, no budget approval, no quarter-long initiative. Ten minutes of honesty and the willingness to make a decision instead of deferring one.
Yes, acting on it costs money. A band move if you ratify, call it €10–15k a year. Maybe a new hire if you rotate. Losing the engineer costs more: a recruiter alone takes 25–30% of first-year salary, so €25k+ for a senior iOS engineer in Europe, before the months of searching and the months of ramp. And the things only they knew leave on their last day, not gradually.
Ratify or rotate. Both are fine. The accidental lead doesn’t need you to pick the one they’re hoping for. But they need you to pick something. And picking starts with the conversation.