Engineering leadership lessons from LDX3 2026
2,800 engineering leaders gathered in London for two days of talks on AI, burnout, hiring, and leadership development. These are the themes worth taking back to your team.
👋 Hey, it’s Stephane. I help engineers become great engineering managers - whether you want to become one or are already leading a team.
Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive.
I’ve been to a lot of tech conferences. Most of them you leave with a bag of stickers and a mild sense of time wasted. LDX3 is different, and after two days at the O2 last week I remembered why – it’s one of the few events where the corridor conversations between talks are as good as the talks themselves.
This year had 2,800 attendees. I went to as many sessions as I could fit across both days, took notes throughout, and had conversations with a lot of people who are dealing with the same problems I am. What follows is the signal I’m taking back - not a session-by-session breakdown, but the themes that kept surfacing across different speakers from different companies. When something comes up five times in two days from people who don’t know each other, it’s worth paying attention to.
The engineering manager role is being squeezed
I have been already feeling what Scott Carey’s talk on day two was about to describe. Carey is editor in chief at LeadDev, and he opened with data that landed hard:
engineering management scope is increasing
direct report counts are going up
working hours are longer
one in three managers are actively considering going back to individual contributor work
The driver, he argued, isn’t only AI. Budget that previously funded headcount is now going to GPUs. The same manager is covering more with fewer people under them. He named the result: the rise of the “player-manager” - leaders expected to both manage and contribute technically.
When Carey said that line about one in three managers considering going back to IC work, I heard people around me exhale. That was not an audience reacting to a surprising statistic. That was an audience recognising their own situation described, probably for the first time in public.
Dominika Rogala, founder of Good Job Coffee (and Former VP of Engineering), gave a talk that added a layer to that. Mid-level managers report the highest burnout rates of any role in tech. And when managers burn out, they tend to pull their teams toward burnout with them. Her framing:
Burnout isn’t an individual failure. It’s a system problem. We shape the environment our teams work in, and the environment shapes the outcome.
I’ve written before about why being an EM today has never been harder. What LDX3 added wasn’t a new diagnosis - it was confirmation that this isn’t just my experience, or yours. It’s the condition of the role right now.
AI is amplifying existing friction
Nicole Forsgren, lead author of Accelerate & Sr. Engineering Director at Google, gave one of the best talk of the conference. I’ve read her work before, so I went in with high expectations.
Her central argument: before AI coding tools, your engineering systems had friction everywhere – slow builds, unclear ownership, knowledge that lived in one person’s head. But natural speed limits meant that friction wasn’t the bottleneck. Now that AI has dramatically accelerated how fast engineers can produce code, the friction that was always there has become the thing slowing everything down.
She mapped it into three types.
Velocity friction: slow builds, manual approval gates, deployment processes that take 15 minutes.
Cognitive friction: unclear criteria, constant context-switching, nobody quite sure what “done” means.
Knowledge friction: engineers who can’t find architectural intent, don’t understand adjacent systems, have to ask a senior every time they touch something outside their usual area.
That last one is the one I haven’t been able to stop thinking about since. AI can generate the code. It cannot generate the context. And in most teams, the context lives in someone’s head - which means it’s not really accessible at all.
Rick Clegg, Developer Experience Lead at Wise, showed what fixing this can look like in practice. His team built tightly scoped AI tools baked into their engineering workflows - a code flow visualiser that generates diagrams showing how code actually runs, and a PR review assistant that explains changes in plain language. His goal wasn’t to make engineers faster. It was to make the system legible to anyone who needs to work in it. The speed follows from that.
Hiring is changing
The most surprising conversation of the conference came from Danit Nativ Navon, a Senior Engineering Manager at Meta. I went into her talk not knowing what to expect and came out rearranging how I think about our own hiring process.
Her team’s problem: candidates are using AI tools during interviews, sometimes with hidden screen overlays that stay invisible even when screen-sharing. Going back to in-person wasn’t a realistic fix at Meta’s scale. So they went back to first principles and rebuilt the whole thing.
They built a tool that gives candidates a full codebase, an AI assistant they’re allowed to use freely, and the interviewers assess them on things that don’t change regardless of the tool:
how they explore a problem before diving in
the quality and maintainability of the code they produce
how they validate and question the AI’s output rather than just accepting it
two layers of communication explicitly
how candidates talk to their interviewer (verbal)
how they write prompts to the AI (written)
They ran 9,000 interviews using this format before going fully live in April 2026.
The criteria for what makes a good hire didn’t change at all. The way you gather evidence for those criteria changed completely though.
What to actually do with all of this
The three themes above describe what’s happening. This next part is about what to do about it.
On the EM squeeze: what to ask from your manager
On friction: how to audit your team’s specific type
On hiring: three things to check in your current process
