Building a tech organization that lasts — A conversation with Robin Leboeuf, Head of Engineering at leboncoin

When Robin tells his story, what strikes you first isn't the linearity. It's the consistency that emerges in hindsight.

Self-taught, entrepreneur, developer, architect, manager, then Head of Engineering — he has worked across different scales of organization and technical maturity. After more than ten years at leboncoin, he looks at his profession with rare clarity: tech is no longer just a question of stack or architecture. It's a question of legibility, structure, and collective calm.

"Leboncoin is the culmination of my career. Here I've found a place where I can work both on technical complexity and on the human organization around that complexity."

A career built through trial, error, and autonomy

Robin doesn't come from a traditional academic software engineering background.

He starts with a two-year technical degree, follows up with a specialization, and quickly discovers the limits of overly rigid environments. His first experience in a consultancy goes badly: a poorly scoped engagement, broken promises, low impact.

He quickly understands that he'll have to learn for himself.

He then joins a small company where he does a bit of everything: hardware, customer relationships, development. The experience is formative, but the values mismatch pushes him to leave.

That's when he tries the entrepreneurial path.

He starts a web agency, then a second one. For several years, he runs projects, clients, and technical production. Until a partnership goes sour and forces him back into employment.

In hindsight, he sees this period as foundational.

"When you work alone, you have to understand the entire value chain. You don't have the luxury of specializing."

He defines himself at the time as a self-taught full-stack developer, trained by necessity as much as by curiosity.

Joining leboncoin: understanding complexity at scale

Robin joins leboncoin in 2015, on a CRM team.

At the time, the company has about 300 people. The stack is heterogeneous, the organization still segmented by specialty.

He starts as a developer, then evolves into a tech lead role.

His first project isn't technological, but methodological.

Putting common standards in place radically changes a team's overall quality.

In parallel, the company is undertaking several major transformations:

• Migration to Go
• Move to microservices
• Organization into feature teams

But the CRM remains a system apart, aging, yet central.

This paradox will become a turning point in his career.

Salesforce migration: a structuring turning point

The decision to migrate the CRM to Salesforce goes far beyond a tool change.

It's about redefining how systems communicate with each other in an already complex environment.

Robin takes on a hybrid developer–architect role to design the entire interface between Salesforce and the rest of the IT system.

"Today, this interface represents dozens of microservices. It wasn't just a technical topic — it was a topic of alignment between business and architecture."

This project leads him to shift his stance:

• less execution
• more systemic thinking
• more anticipation of edge cases

It's his first experience with cross-cutting architecture at scale.

Cross-cutting architect: the challenge of influence without authority

By becoming a cross-cutting architect, Robin discovers a challenge that's often underestimated.

Decision-making power doesn't guarantee adoption.

"You can propose the best possible solution. If it's not understood or owned by the teams, it won't be followed."

This realization leads him to shift his focus. The heart of the work no longer lies solely in designing solutions, but in how to make them intelligible, debatable, and shareable.

Framing then becomes central: not limiting yourself to the stated needs, but questioning what remains implicit, exploring blind spots, challenging assumptions, and anticipating invisible dependencies.

This upstream work, often quiet and rarely celebrated, is decisive. It's what helps avoid technical and organizational dead ends in the long run, and what builds decisions truly owned by the teams.

The pride of a product anchored in everyday life

Robin talks about leboncoin with attachment, but also with responsibility.

Working on a product used by millions of people demands particular rigor.

"Every change directly impacts people's habits. You can't brutally change the user experience."

This reality deeply shapes technical choices. Performance, robustness, and reliability aren't abstract goals but daily requirements, dictated by the product's scale and the diversity of its uses.

Every decision is weighed, every change designed to last, without weakening what already exists.

The traffic level imposes a level of technical maturity that's rarely negotiable.

Hiring in Go, then returning to fundamentals

Faced with the tight market for Go developers, the company takes a pragmatic approach.

Rather than restricting hiring to narrow Go expertise, the team prioritizes more durable fundamentals: the ability to reason about backend problems, to learn quickly, and to fit into a demanding engineering culture.

Mastery of Go then becomes a consequence rather than a prerequisite. An internal program supports new hires in their skills ramp-up, leveraging strong fundamentals and an environment conducive to learning.

The ability to learn becomes more decisive than initial expertise.

Moving from tech to management

The transition to management doesn't happen as a break, but as a continuity.

Robin describes a deep interest in human dynamics.

When his team finds itself without a manager, he offers to step into the role while keeping a strong technical anchor. This hybrid positioning lets him explore the role gradually, develop his management skills without immediately breaking from daily code practice.

Over time, the balance evolves. Organizational responsibilities take up more space, and the scope expands. This gradual shift lets him build a manager's posture in continuity with his identity as an engineer, without renouncing what gives him legitimacy with the teams.

Developer Experience: a strategic lever

Today, Robin's role is above all about creating the conditions in which engineering teams can work effectively and durably. It's less about marginal optimization than about structuring a legible environment, where tools, processes, and systems form a coherent whole.

Documentation, tooling, observability, deployment pipelines, incident management, or even a global understanding of architectures: efficiency in service of calm.

"Good Developer Experience is when teams know where to look, what to do, and don't get surprises."

Before any improvement, clarification work is necessary:

• Ownership
• Tool rationalization
• Practice harmonization

At the scale of dozens of teams and hundreds of services, this work demands method and patience.

Measuring developer experience

To grasp Developer Experience, Robin distinguishes two complementary dimensions, which he sees as inseparable.

On one hand, objective metrics let you measure how teams operate over time: deployment frequency, incident resolution time, error rates in production. These metrics offer a factual reading of how systems and processes perform.

On the other, more perceptual data complements this analysis. They translate developers' day-to-day experience: the sense of friction, accessibility of documentation, the ability to understand and navigate sometimes complex systems.

The challenge is to align these two realities to build a reliable picture.

AI: pragmatism above all

On AI, Robin takes a nuanced stance.

Experimentation is encouraged, without giving in to simplistic promises.

Code generation, often touted, is only part of the story. Maintenance, system understanding, debugging, or knowledge transfer remain central, and don't disappear with automation.

In that light, AI imposes itself less as a miracle solution than as one more tool, to be integrated thoughtfully into existing practices.

Juniors and AI: an optimistic view

Contrary to some concerns, Robin thinks junior developers may benefit from AI.

This early exposure fosters new reflexes: a sharper ability to reason in abstraction, to supervise rather than execute, and to think about systems as a whole. These are skills that already point to a form of architectural maturity.

The real challenge lies more on the side of mid-level profiles, for whom adapting often means questioning deeply ingrained habits and proven ways of working.

2026: clarify, stabilize, move forward

The Developer Experience crew is still in a structuring phase.

Its scope is sometimes misunderstood, but Robin remains confident.

Once the foundations are stabilized:

• Responsibilities will be clearer
• Teams will move faster
• Frictions will decrease

And contrary to many organizations, the answer doesn't lie in growing headcount.

"I don't need more people. I need alignment and stability."