From iOS Developer to Head of Engineering: 7 Lessons from 10 Years

I started as an iOS developer in 2016, building the first versions of the patient apps for two of Egypt's leading medical lab chains. Ten years later I head engineering at Spomotion and run Kryptun, the software company I founded. In between, I personally built and shipped more than 50 iOS apps for clients across the Gulf, then led the mobile team, then a 20-person engineering organization split into squads.

The job changed more than the title did. These are the lessons that made the difference, written for developers thinking about the move into leadership, and for founders deciding who should run their engineering team.

1. Your output becomes the team's output

As a developer, a good day is measured in what you shipped. As a lead, it is measured in what the team shipped, and that includes the work you unblocked, reviewed or taught. The first months are uncomfortable, because the work you are best at is no longer the work that matters most.

The answer is not to stop coding. It is to choose the coding that multiplies everyone else: the architecture decisions, the hard reviews, the prototype that settles a debate. When I led the mobile team, I kept full technical ownership of architecture, estimates, code reviews and App Store releases, and handed the feature work to the team.

2. Write the standards down

Heroics don't scale. A team of strong developers with different habits produces code that only its author can maintain. On the mobile team we wrote our standards down, built around MVVM and Clean Architecture, so any developer could open any project and know where everything lives.

Standards are not a matter of taste. They make reviews faster, onboarding shorter and estimates more honest, because the team stops solving the same structural problem in a new way on every project.

3. Give each squad something it owns

Once the organization grew to 20 engineers, one team working on everything stopped working. We split into squads, and each squad owned its own portfolio of client projects end to end, from requirements to support after launch.

Ownership changes behavior. A squad that will also answer the support tickets writes its code differently, asks better questions while gathering requirements, and cares about a release long after it ships.

4. Hiring is the decision with the longest tail

Every engineer you hire shapes the team for years: the code they write, the reviews they give, and the people they help hire next. I rebuilt our hiring process around one goal: raise the bar with every new engineer, rather than fill seats quickly.

In practice, that means a clear picture of the role before the first interview, the same structured questions for every candidate, and a technical exercise that looks like the real daily work. A slow yes is cheaper than a fast mistake.

5. Route problems instead of absorbing them

A lead who personally handles every client issue becomes the bottleneck, and the team never really learns the systems it owns. So we built a pipeline that routes client-reported issues straight to the team that owns the project.

The lead's job is to make sure that route exists and works, not to be the route.

6. Make time to talk, and to teach

Two habits did more for the team than any tool: regular one-on-ones, and a weekly engineering knowledge-sharing session. One-on-ones catch problems while they are still small. The weekly session spreads what one squad learned to everyone, so each lesson is paid for only once.

7. Head of Engineering means owning the whole path

At Spomotion the scope widened again: application architecture, team structure, delivery, and the product's path to its final release. The question is no longer whether the code is good. It is whether the product reaches people, and whether the team that builds it can keep doing that.

That is the real difference between the roles. A developer owns a feature. A team lead owns how the team builds. A head of engineering owns whether engineering as a whole moves the product forward.

If you are making the move

• Pick the work that multiplies the team, and let go of the rest.
• Write the standards down before you need them.
• Give people ownership, including everything after launch.
• Treat every hire as a long-term decision.
• Build clear routes for problems, and protect time for one-on-ones and teaching.

If you are going through a similar move, or building an engineering team for your product, I'm always happy to talk.