From Junior Developer to Technical Lead

Chapter 1 · Learning what professional engineering means

I joined Amadeus on December 2016, just after completing my engineering degree.

At that point, my objective was practical: get my first job, earn my first salary, and start building my life in France.

My definition of a good software engineer was also quite simple:

Write good code and solve complex problems.

Working on systems used by airline companies quickly challenged that view.

A small change could have operational and financial consequences. My work alternated between maintaining existing systems, fixing production issues, and developing new features.

One incident made this particularly concrete. A production bug was causing a customer to lose money every day it remained unresolved. We had to fix it quickly, but without introducing regressions elsewhere.

That experience changed the way I thought about testing.

Test coverage and TDD stopped being engineering theory. They became tools for changing important systems with confidence.

I also learned through code reviews, documentation, collaboration, and working with more experienced engineers that software engineering was not an individual activity.

By 2020, I had built strong technical foundations, but I wanted more.

I wanted broader problems, more visible impact on people's lives, and a role that went beyond implementing relatively well-defined backend tasks.

So I left Amadeus.

Or, more accurately: COVID arrived, Amadeus cut about 75% of their consultants, and my carefully planned career pivot got a less glamorous origin story.

What happened in between

Leaving turned out to be an important part of the story.

At Neocustic, I worked in an early-stage health-tech startup where engineering was much closer to users, UX, product decisions, and business constraints.

At Kappa Engineering, I learned to think more globally about architecture while working through small, low-risk changes supported by strong automated testing.

Those experiences expanded the way I looked at software systems.

When I returned to Amadeus in 2024, I was bringing those lessons back with me.

Chapter 2 · Helping shape the system

I returned to work on Nevio, a new cloud-based product that represents an important part of Amadeus's future airline platform.

This time, I joined before the team was fully formed.

My responsibility was to help establish the first foundations of one part of the product.

The challenge was very different from my first period at Amadeus.

We had to define the domain model, global architecture, system boundaries, and APIs that would allow our domain to communicate with the rest of the platform.

My previous knowledge of Amadeus's legacy systems helped me understand the business context.

What I had learned outside Amadeus helped me look at the new system more broadly.

My role included:

• proposing designs
• challenging technical decisions
• identifying edge cases
• suggesting alternatives
• collaborating with other teams
• implementing parts of the solution myself

I was no longer simply receiving an architecture and translating it into code.

I was participating in shaping it.

From building the system to enabling the team

As junior engineers joined, my role changed again.

I had to help them understand two things at the same time:

the legacy concepts that explained where we came from, and the architectural vision that explained where we were going.

Mentoring became less about answering technical questions and more about helping engineers build a mental model of the system so they could make good decisions themselves.

At the same time, AI started becoming part of the development lifecycle.

That introduced another responsibility:

How do we use AI to move faster without reducing understanding, ownership, or quality?

AI could generate code quickly, but the team still needed to understand the system, challenge assumptions, validate behavior, and remain responsible for what we shipped.