This week I had the chance to attend LDX3 (formerly known as LeadDev London), a buzzing two-day conference packed with bite-sized engineering leadership talks, practical insights, and a refreshing mix of inspiration and pragmatism.
Here are 10 takeaways that stood out for me…
1. Strong delivery doesn’t mean a healthy team
Metrics alone don’t tell the full story. Without context and action, they’re just noise. Consider asking your teams what metrics actually help them improve—not just what gets reported. (Oge Opara-Nadi, Hey Savi)
2. Weekly quality reviews can prevent a crisis
Quality is speed. Skipping it for short-term gains leads to breakdowns later. What lightweight rhythm could help you keep an eye on code health before problems appear? (Christine Pinto)
3. Repo health dashboards are back in style
Trainline built one to auto-lock repos under 40% health. It’s visual, objective, and promotes ownership. Could your team benefit from a visual dashboard to track repo or project health? (Simon McManus, Trainline)
4. Most devs still don’t get structured onboarding
First PR. First Jira ticket. First production impact. These onboarding quests create early wins and clarity plus the sense of satisfaction for the individuals. What would your team's "onboarding quest" look like? (Amtul Haq Ayesha)
5. Don’t assume, do challenge
When leading diverse or neurodiverse teams, challenge sweeping generalisations and co-create solutions. Your leadership style matters; is it permissive, authoritative, or something else? (Stacey Nutbrown, Capital One)
6. Confidence isn’t binary
Ask for a percentage. “How confident are you (%) that we’ll deliver this on time?” This opens up new conversations and surfaces hidden risk. Could this shift how you handle roadmap conversations? (Sean Bolton, Monzo)
7. Every output is an input
Every change feeds the next. Don’t wait for perfection; log it, learn from it, iterate. What small loop could you tighten in your team’s workflow today? (Matt Collier, Vercel)
8. Not all OKRs should stretch you
Some goals need ambition. Others need focus. Know which is which to avoid burnout. Take a moment to sanity-check your current OKRs; are they all pushing or balancing? (Neil Vass, Co-op)
9. Your job shifts as you grow
Presence, perception and patience are key when you lead other leaders. You’re not just managing people, you shape the system around them. Where do you need to show up more intentionally? (Gisela Rossi, Trustpilot)
10. Pair with AI, don’t rely on it blindly
Use tools like Claude and Copilot to reduce toil, but keep your critical eye sharp. What’s your team’s shared understanding of how to use AI responsibly? (Birgitta Böeckeler, Thoughtworks & Farhan Thawar, Shopify)
Some of the common themes across the 2 days…
Context beats metrics #
Great teams don’t just hit numbers; they understand what those numbers mean. Many talks reinforced the idea that data needs interpretation, intention, and follow-up to drive actual improvement. This strongly aligns with the PETALS approach: numbers should be conversation starters, not performance scores. When misused, metrics can create fear or false confidence; when used well, they unlock trust, reflection and action.
Quality is never a side project #
Rushed work, flaky tests, and poor documentation always cost more in the long run. Time invested in quality, whether through code reviews, retros, or weekly health checks, is time well spent. Tools like Trainline’s repo health dashboard show how automated checks and visual indicators can flag risks early, but they only work if they're reviewed and considered as part of your wider service health conversations.
AI is powerful, but not a shortcut #
AI tools are changing how we work, but human judgment, ethical thinking, and communication remain irreplaceable. Use AI to enhance your workflow, not replace your responsibility. Speed is great – but only when paired with scrutiny. There’s a wave of tooling that accelerates time-to-live, but with it comes risk. The idea of engineers simply reviewing AI-generated PRs sounds efficient, but without rigour, it can compromise code quality. It loops back to the quality thread: if you’re not checking thoroughly, you’re just moving faster towards tech debt.
Leadership is about enabling others #
You’re not the hero – you’re the enabler. Modern engineering leadership is about building psychological safety, amplifying others, and navigating ambiguity with clarity and care.
All in all, it was an interesting few days surrounded by amazingly talented and knowledgeable people, understanding how others work in tech and what we could explore next.
As an avid podcaster, I was also fascinated to be part of the Pragmatic Engineer podcast recording on the first evening when Farhan was interviewed by Gergely and opened up about some really interesting ideas around embracing AI in the workplace.
Which of these sparks something for you and your team?