Notes from LDX3 London: Five talks, one thread
I came away from LeadDev London with a set of talks that, on the surface, covered very different things: resilient architecture, technical debt, LLM features, AI coding agents, and team psychology.
The thread across all of it wasn't a framework. It was a set of ideas that named things I've seen happen in real engineering organisations — complexity added in the name of safety, debt hidden inside delivery pressure, AI features that are hard to judge because "good" is contextual, agents that have access without understanding, teams where the human system matters as much as the technical one.
Complexity Can Create the Failure It Is Trying to Prevent
Sam Newman's keynote, "Things fall apart – Architecture to avoid progressive collapse", looked at how small failures can cascade through software systems.
The useful warning: increasing a system's complexity to handle more failure scenarios can itself introduce more failures. It's easy to assume that more resilience mechanisms automatically make a system safer. Multi-region setups, failover paths, replication, backup strategies, and recovery processes all sound reassuring in isolation. But each one adds operational complexity. Each one needs to be understood, tested, maintained, and trusted under pressure.
The talk framed mitigation around three ideas:
- reduce hazards
- strengthen components
- reduce interconnectivity
Resilience isn't just about adding more machinery. Sometimes the safer move is to reduce coupling, remove unnecessary dependencies, or make the blast radius smaller. A system can become more fragile if the safety mechanisms are too complex for the organisation to operate confidently.
Don't confuse more architecture with more resilience.
Technical Debt Needs to Be Planned, Not Smuggled In
Ejber Ozkan's session, "Quantifying technical debt to modernise critical systems", was one of the most practical talks of the day for me.
Three points felt especially useful:
- If you try to sneak technical debt into feature tickets, it usually fails.
- Product and engineering need to prioritise debt together.
- Once technical debt becomes painfully visible, the cost of remediation may already be too high.
That framing felt very true. Technical debt is often treated as something engineering should somehow fix in the gaps between feature work. But if the work isn't visible, planned, and connected to business outcomes, it becomes easy to defer indefinitely.
The strongest message was that unmanaged debt creates a spiral: pressure increases, quality drops, delivery slows, confidence decreases, and then the system becomes even harder to improve.
That spiral is familiar. Teams become slower, but because they're slower, there's even less appetite to invest in the work that would help them speed up again. The system becomes scary to change. Deployments feel risky. Engineers lose confidence. Product loses trust. Everyone can feel the drag, but it's hard to make the case for remediation unless the debt has been made visible in a way the whole organisation can understand.
The takeaway wasn't just "fix tech debt". It was: make debt discussable before it becomes a crisis.
Good Enough Depends on Context
Thordis Thorsteins' talk, "Finding the 80/20: Lessons from delivering our first LLM feature", focused on what it actually takes to ship a first LLM feature.
The tradeoff was framed neatly:
perfect feature < feature that is good enough for our context and easy to iterate over
That line captures a lot of the tension around AI product work. The hard question often isn't "can we build it?" but "how good does it need to be for this product, this customer, and this risk profile?" — and that varies enormously depending on who's affected if it goes wrong.
That changes what production readiness means. It's not only tests, monitoring, and rollout plans. It's also evaluation, observability, context quality, documentation, cost, pricing, customer communication, and knowing which failures are unacceptable.
The "good enough for our context" framing avoids two traps. One is trying to perfect the feature before learning from real use. The other is shipping something vague and hoping iteration will fix the trust problem later.
The other useful takeaway was to figure out what isn't acceptable to fail. That's a much sharper framing than trying to cover every possible edge case equally. Some failures are annoying. Some are confusing. Some break trust. Some create unacceptable customer or business risk. Production readiness means knowing the difference.
So when building something, ask yourself: what must be true from day one, and what can safely improve over time?
Access Is Not Understanding
Dennis Pilarinos' session, "Your agents lack context: Here's how to fix 'You're absolutely right!'", was about AI coding agents and the context they need to produce useful work.
One idea captured the ambition clearly: AI-generated code should feel like it was written by one of the strongest engineers on your team — someone who's been around for years and understands the history, tradeoffs, and taste of the codebase.
But most agent sessions are nowhere near that. Every new agent session is like a new engineer on day one. It may have access to the repository. It may have access to docs, tickets, Slack, or MCP servers. But access isn't understanding.
A human engineer doesn't only read files. They learn which docs are out of date, which systems are fragile, which decisions were intentional, which teams own what, and where the risky edges are. That context is often implicit, social, and historical.
As agents become more autonomous, missing context becomes more expensive. Bad suggestions are annoying when the human is in tight control. They become more dangerous when agents are making larger changes, running in parallel, or operating with less supervision.
The takeaway for me was that better AI tooling isn't only about bigger context windows or more connected data sources. The harder problem is relevance: giving the agent the right context for the task, with the right permissions, at the right level of detail.
Leaders Need to Read the Game
Cathy Pank's talk, "Reading the game: Mental skills for high-performing engineering teams", used a sports coaching metaphor to explore engineering team dynamics.
After a serious knee injury stopped Cathy from playing sports, she started coaching from the sidelines. That shift changed what she could see. On the pitch, she had naturally led by example. From the sidelines, she could see the whole system: who went quiet after a mistake, who became visibly frustrated, who needed encouragement before attempting something difficult, who responded well to direct instruction, and who needed space to be creative.
That maps onto engineering teams. An incident postmortem tells you what broke. It rarely tells you who went quiet during the outage, who was reluctant to escalate, or who had been carrying anxiety about the deployment for weeks beforehand. We often talk about balancing teams by technical skills, experience, seniority, and temperament. But we don't always consciously look at the psychology of the team: how people respond to stress, how they recover from mistakes, how they ask for help, and how much they understand about each other's working styles.
The phrase "read the game" is useful because it suggests a different leadership posture. You aren't only managing tickets, ceremonies, and delivery plans. You're observing the team as a system while also noticing the individual people inside it.
That means paying attention to the signals around the work, not just the work itself. Who is withdrawing? Who is taking on too much? Who needs clarity? Who needs space? Where is psychological safety strong, and where are people quietly protecting themselves?
The shift she described — from leading by example on the pitch to reading the system from the sidelines — is the same shift engineering leaders often have to make. It's not always a comfortable or an easy one.
The Thread Across the Talks
The talks I found most interesting were all about judgement.
When is resilience actually resilience, and when is it unmanaged complexity? When does technical debt need to become product work, not just engineering pain? What does good enough mean for an AI feature? What context does an agent need before it can act usefully? What's happening in the team that isn't visible in the delivery plan?
None of those questions have a universal answer. They depend on context, risk, trust, and the ability to see the system clearly enough to act.
That was my main takeaway from the talks I attended: engineering leadership is not only about making decisions. It's about noticing what those decisions depend on.
What's the most useful reframe you took away from a talk this year?
Comics by MonkeyUser — worth a browse if you haven't already.