From Engineer to Leader…

Five lessons from LeadDev London that every engineering team should hear

Every year, LeadDev gathers some of the sharpest engineering leaders in the world to share what they’re actually seeing in the field; not blog-post theory, but hard-won lessons from shipping real products at scale. This year at LDX3 London, one theme ran like a current through almost every talk: the role of the engineer is fundamentally changing.

“With the advent of AI agents, coding isn’t the bottleneck anymore. Manual reviews become the bottleneck. Security becomes a bigger challenge.”; Observed across multiple talks at LDX3

That’s a striking statement. But the more I listened, the more it rang true; and the more I realised it has implications far beyond tooling. It changes how we hire, how we onboard, how we measure success, and how we build teams that can thrive under that new reality.

Here’s what I took away from the conference, organised into five themes; each of which I think deserves attention.

LDX3 London 2026 – At a Glance

Five interconnected themes from LeadDev’s flagship European conference

01 – AI-Native Engineering

The shift from writing code to engineering context, evaluations, and AI-augmented hiring – including how Meta now runs interviews with AI allowed.

02 – Resilient Systems

Design for disasters, not just demos. Offline-first architecture, async workflows, vendor neutrality, and AI model fallbacks that kick in when your primary goes down.

03 – Safe Shipping with AI Agents

Guardrails beat gates. AI code review in CI, canary analysis, sandboxes for junior engineers, and decision records that give agents the context they need.

04 – Inclusive Teams & Culture

Giving everyone airtime is not the same as inclusion. Async-first communication, written discussion, and psychological safety are the real levers of team performance.

05 – Delivering Business Value

Shift from output metrics (story points, velocity) to outcome metrics (user problems solved, adoption, ROI). DevEx frictions become the platform team’s backlog.

Let me unpack each of these in detail.

AI-Native Engineering

The most provocative idea I heard at LDX3 wasn’t about a new tool or framework. It was about what it means to be a good engineer in 2026. The bottleneck has moved. Writing code is no longer the hard part – shaping the right context for AI to write it well is.

AI in the Interview Room

Meta runs interviews where candidates are allowed – expected, even – to use AI. The evaluation criteria haven’t vanished. Interviewers still look at problem navigation, solution options, code cleanliness, test coverage, and performance reasoning. What’s changed is how candidates work through those things: previously they’d soundboard with the human interviewer, now they do it with an AI assistant while the interviewer observes their thinking.

One team took it further – they seeded a project with intentional runtime bugs and asked candidates to diagnose and fix them, with or without AI. That’s a clever design: you learn a lot about an engineer from how they interrogate a system and use AI to form and test hypotheses.

What this means for hiring
Banning AI in technical interviews is starting to feel like banning Google. The question isn’t whether candidates can use AI – it’s whether they can use it well. We should be thinking about what that looks like in our own hiring processes.

Onboarding as a Real-World Problem

One conference speaker proposed a deceptively simple idea: instead of walking new engineers through docs and sandbox exercises, give them a real task – build a microservice and deploy it to QA – on day one or two, using the team’s actual stack and AI assistants. No hand-holding, no toy problems.

The goal is acceleration through genuine immersion. New joiners learn more in two days of doing real work than in a week of reading README files. And they discover the quirks, frictions, and unwritten rules of your environment in a way no documentation can capture.

Context Engineering: The New Core Skill

Multiple talks converged on this point: the skill that matters now isn’t just writing code, it’s crafting the prompts, context, and evaluations that make AI code generation reliable. One team shared that they started with entirely manual evaluations – testing AI outputs by hand – and successfully deferred building automated eval pipelines. That’s a refreshingly practical approach in a space full of “you need to automate everything immediately” pressure.

Resilient Systems

One of the most grounding talks at LDX3 pulled the audience out of the day-to-day optimisation mindset and asked a harder question: what happens when something you depend on just… disappears?

Not “what if our servers are slow” – but what if a major cloud vendor is banned in your region overnight? What if a key SaaS product is acquired and shut down? What if there’s a power outage that takes out your primary data centre? These aren’t theoretical. They’ve all happened.

• ! Offline-first design – critical paths and core workflows that function without connectivity. Think disaster-relief tools: they need to work when infrastructure fails.
• ↔ Async workflows by default – decoupling services so a single failure doesn’t cascade into total downtime. Synchronous chains are fragile; async queues absorb shocks.
• ⊘ Vendor-neutral architecture – abstraction layers that let you swap providers without a rewrite. Avoid deep lock-in to any single vendor, especially for AI services.
• ↓ AI model fallbacks – one team had backup LLMs in place that automatically activated when their primary model experienced an outage. The product kept working.

The disaster manager mental model
Design for the scenario where a randomly crashing server, a vendor ban, or a forced M&A integration happens on a Tuesday afternoon. Not as a paranoid exercise – but as a design constraint that makes your systems genuinely robust.

Safe Shipping with AI Agents

If coding is no longer the bottleneck, what is? Two things stood out in multiple talks: code review and deployment confidence. AI agents can generate a lot of code quickly – but that code still needs to be right, and shipping it still needs to feel safe.

The framing that resonated most with me was: deploy guardrails, not gates. Gates slow everything down and create anxiety. Guardrails let you move fast with confidence – because there’s a net below you.

What Guardrails Look Like in Practice

• Automated test coverage that catches regressions before any human reviews. Green tests are the first signal it’s safe to proceed.
• Quick rollback mechanisms – if something breaks in production, recovery should take minutes, not hours. This single capability changes engineers’ psychological relationship with shipping.
• AI code review in CI – one team integrated AI-powered review into their CI pipeline. There are other paid solutions available e.g. CodeRabbit and Cursor Bugbot. AI catches categories of bugs that humans consistently miss.
• Canary analysis – automated maturity checks and gradual rollouts so changes are validated on real traffic before full release.
• Isolated execution environments – sandboxes that give junior engineers full autonomy to experiment without any production risk.

Documentation and decision records
This theme also surfaced something easy to overlook: AI agents need context. They can’t read your team’s institutional memory. Architecture Decision Records (ADRs) and good documentation aren’t just nice-to-haves anymore – they’re the interface between your codebase and the AI systems that will increasingly work in it.

There’s also an exciting implication here for junior engineers. With the right guardrails in place, a junior engineer equipped with AI can ship production-ready code far earlier in their career than was previously possible. That changes what hiring for potential looks like.

Inclusive Teams & Culture

“The game is 80% mental, 20% physical.” ~ Michael Jordan (applied here to engineering team performance)

One speaker drew on this quote to make a point that landed hard: technical skill is about 20% of what makes an engineering team perform. The other 80% is psychological. Confidence. Trust. The freedom to raise concerns without fear. The sense that your ideas will be heard.

The Inclusion Myth

Here’s something many managers get wrong, including – if I’m honest – me at times: giving everyone airtime in a meeting is not the same as inclusion. Introverts don’t speak up under time pressure in front of a group. If your primary channel for ideas is the live discussion, you are systematically underweighting the thinking of a significant portion of your team.

The fix isn’t forcing introverts to speak – it’s changing the default medium. Written, asynchronous communication gives everyone equal footing. Discussion threads, written RFCs, async Loom updates. Not instead of meetings – but as the default, with meetings reserved for decisions and genuine creative collaboration.

AI as a Manager’s Thought Partner

Several speakers touched on personal AI agents – not as a replacement for human judgment, but as a way to reduce the operational noise that prevents managers from focusing on what actually matters: their people and their strategy.

Streamlining meeting prep. Staying on top of context across multiple teams. Reducing the manual toil of operational data analysis. Using AI as a strategic coach – a thought partner for balancing short-term fires against long-term goals. These are genuinely useful applications of the technology for engineering leaders, and I want to spend more time exploring them.

Delivering Business Value

The final theme is the one I’d argue has the most long-term leverage – and the most resistance. Engineering teams are still largely measured on output. Story points, velocity, features shipped, PRs merged. These are legible, easy to track, and almost entirely miss the point.

What actually matters to the business – what non-technical stakeholders actually care about – is outcomes. User problems solved. Adoption rates. Business impact. Customer satisfaction. The shift from tracking the former to measuring the latter is hard, but it’s the shift that earns engineering a seat at the strategy table rather than the execution queue.

The eBay DevEx insight
A VP of Platform Engineering at eBay shared something elegant: the biggest developer experience frictions felt by product teams become the backlog of the platform engineering team. Not as a nice aspiration – as a structural commitment. DevEx engineers embedded themselves with product teams to observe friction firsthand. You can’t optimise what you can’t see.

From Order-Taker to Advisor

Building trust with non-technical departments – operations, commercial, finance – is how engineering moves from executing tickets to shaping direction. That trust is earned through consistent delivery and, crucially, through communicating in their language. Business impact. Risk reduction. User value. Not sprint points and deployment frequency.

Once that trust is established, something shifts. You’re no longer being handed requirements – you’re being consulted. That’s a fundamentally different (and more interesting) relationship with the rest of the business.

Five Things I Think We Should Do Next

These aren’t abstract ideas – they’re concrete proposals.

01 – Pilot AI-native onboarding

Design one real-world onboarding task per team – build and deploy something using our actual stack and AI tooling. New joiners should be meaningfully contributing within two days, not two weeks.

02 – Introduce guardrails, not gates

Invest in test automation, fast rollback scripts, and AI-assisted code review in CI. Explore BugBot or an equivalent. The goal: any engineer should be able to ship to production with confidence.

03 – Go async-first

Audit our meeting culture. Written discussion channels should be the default. Synchronous meetings should be reserved for decisions and genuine creative collaboration – not status updates.

04 – Measure outcomes, not output

Work with Product and Commercial to define what outcomes we’re trying to move – and report on those alongside delivery metrics. Story points alone tell an incomplete story.

05 – Start writing Architecture Decision Records

As we adopt more AI agents and tooling, the historical context encoded in ADRs becomes critical infrastructure. This is low-cost to start and high-value over time.

Closing Thoughts

LeadDev consistently delivers one of the most grounded, practitioner-led conferences in the engineering leadership space. LDX3 London 2026 felt especially relevant – perhaps because the pace of change right now is fast enough that even a few months of observed practice at scale reveals genuinely new patterns.

The throughline across all five themes, if I had to name one: the engineer’s leverage is increasing, and so is the engineering leader’s responsibility to create the right conditions for that leverage to be used well. Guardrails. Psychological safety. Clear outcomes. Context for AI systems. These aren’t soft concerns – they’re the new infrastructure.