LDX3 London 2025 (Day 1)
This June, for the fourth time, I was lucky enough to be able to head into London for the annual LeadDev conference, this time updated and renamed to LDX3. LeadDev is increasingly popular, and had outgrown the space at the Barbican, so this year was held at the Intercontinental at the O2. Previous years had separated the LeadDev, Staff+ and Leading Eng tracks, so if you had tickets to one, you couldn’t go and see talks on a different track. This year, it was one big conference, so apart from a separate Director+ area, anyone could see any of the talks.
As a space, the Intercontinental worked ok. The Barbican is a unique venue with a lot of character, so it’s difficult to replace that vibe. The Intercontinental was essentially a giant square hotel ballroom, surrounded by scrub land (although with a pretty cool view of Canary Wharf). The LeadDev team had done a good job jazzing up the space with lights and screens but the stages, even for the main Organisational Leadership track, were small compared to the Barbican, and I definitely missed the lovely comfortable Barbican raked seating, with perfect sightlines from wherever you chose to sit.
I’ve previously complained about the toilets at the Barbican, and those facilities were much better at the Intercontinental. Clean, functional and didn’t have to queue for long. However, food was a bit of a step back. With the different tracks breaking at slightly different times if your track finished later thanothers in the morning and afternoon breaks, you were likely to find all the food already gone. On the first day, there was no food left in the morning, and in the afternoon break I only found a sad-looking pot of chilli nuts. On day two, I happened to choose an early breaking track, so I managed to grab a tasty cake.
Lunch was better in that there was generally plenty of food, although I did spend about 10 minutes queuing near a pile of food because there were no plates available. Seating during lunch is always going to be difficult, and at the Barbican I usually ate while sitting on the stairs. The Intercontinental was no different. The desserts at lunch were similar to the breaks, and if you arrived late, you could well miss out.
The conference was split into three main stages: The largest Organisation Leadership stage, the medium-sized Technical Strategy stage, and the small Ways of Working stage. The LeadDev team underestimated the popularity of the Ways of Working stage, and on the first day quite a few people failed to get into the room as it was full. Credit to LeadDev though, by day two they had magiced up a hundred or so headphones and chairs so you could watch a live stream.
I appreciated the opportunity to pick and choose the talks that suited me best, so I did move around the stages over the two days. I planned my days to stay at the same stage until a break, and only then move. Unfortunately, a lot of people switched stages after every talk, which was very disruptive and occasionally disrespectful to the speakers who were on next. With the single-track conference at the Barbican, you didn’t have a choice but to sit there and watch whoever was on stage. If I were running the conference, next year I would advertise which talks were in each block, but not give specific timings for them to encourage people to not pick and choose quite so much.
As usual, there was a lot on apart from the main stages, including table talks, workshops, expert coaching and a networking event. I took part in a workshop, which I’ll write about in my round-up of day 2, and the networking mixer, but didn’t take advantage of the rest of the sessions. Away from the talks, the space was extremely busy and a bit overcrowded. It was not easy to move around. The sponsor hall, in particular, was always packed so I tried to avoid it unless I had no choice.
I think that’s enough rambling about the conference, the reason I went was the talks, so below is my summary of the talks I saw on day 1 of LDX3 London 2025…
The videos of the talks are available here if you sign up with a free LeadDev account.
Escaping The Rewrite Trap
Opening the conference is a tricky task as you have to set the tone for the rest of the talks. Camille is a LeadDev regular, and here was covering one of the topics that came up repeatedly over the two days - dealing with technical debt. Camille’s approach was that rewrites almost always fail, but reachitectures succeed.
The problem is that with any long-lived code base, it’s really hard to know what it actually does, so how can be you be sure you have reimplemented all the required features and logic? Hyrum’s law states that for a sufficiently large number of users, any observable behaviour will be depended on by someone - so if your rewrite changes anything, it will break for someone.
Camille made the point that if you have a large successful system, then the team supporting it is unlikely to be staffed for novelty. When you’re first building a system you have “pioneers”, who thrive on the hard work of building something from scratch, then “settlers” who start scaling it one. Once it’s successful, they are replaced by “town planners”, who are adept at maintaining and gradually growing the system. Asking your “town planners” to start from scratch is unlikely to be successful.
To be successful in rearchitecting you need to have, and clearly communicate a vision for the end goal. You need to have long-term goals, for example “features”, “efficiency”, “reliability” and “security”. Factor in the scale of the company, your rate of growth and migration costs - can you really afford this? What major things can you achieve in 12 months?
Once you have the plan, sell it to your team and sell it to your stakeholders. Take advantage of external deadlines, such as key technology going out of support soon.
Finally, Camille covered how to execute the plan. She first warned against bringing in a new hire to run the project. Although they may “have done this migration before”, they won’t know the team, the context or the system and will immediately be on the back foot. You should minimise disruption for your users, and work out how to ensure correctness. Can you test without breaking the rest of the company?
I felt this talk was a great conference opener. It had just the right balance of inspiration, a broad topic and actionable suggestions you can apply to your own role.
Rethinking Collaboration
As with everywhere else, LLMs were a common topic at LDX3. In this talk Sara covered how to use LLMs to help in a variety of work contexts. She started with covering how LLMs can better structure your CV, and can help tailor a cover letter to the company you’re applying for.
Once you have joined a company she talked about how you can talk to an LLM instead of a rubber duck to help with getting unstuck while learning the new systems and technologies.
She also warned about where LLMs can make things harder - such as “skills atrophy” while vibe coding, making up facts in your CV and subverting the narrative if you ask it to rewrite a longer piece of text.
I’m pretty sceptical of AI, and this talk did little to change that.
How Monzo Tolerates Full Cloud Outages
Andrew Lawson and Daniel Chatfield (Video)
In this talk, Andrew and Daniel covered how Monzo avoids downtime, even when their primary system is completely unavailable. They began by talking about some recent large-scale outages. In the last two years nine UK banks have had a combined total of 803 hours of downtime due to IT outages. They also covered the UK National Air Traffic Control System (NATS) outage where a bad flight plan took down both their primary system, and because it was running the same code, so had the same bug, the secondary system too.
To avoid this problem, Monzo has what they call a “stand-in”. This is not a subset of their core system, but a completely independently implemented and hosted system that they can switch over to for anywhere between one and all of their users. It consists of 18 services (compared to 3000+ for their primary), and offers only the core features bank users rely on - checking balances, paying with a card, etc. It costs just 1% of their cloud spend to run.
They stay in sync by not modifying data in the secondary, but by keeping a list of changes that are then replayed on the primary when it is available. This avoids issues with the two systems becoming out of sync.
They convinced their executives to allow them to test on real customers, as this is the only way to be sure it works, outside of a major incident.
This was a really great talk. I thought they could have talked about how similar ideas have been used in aeroplanes and space flight, to give a bit of context, but regardless, this was a really interesting peek behind the curtain of a nationally critical piece of infrastructure.
Monolith-ifying Perfectly Good Microservices
This talk followed a thread that was common to quite a few talks at LeadDev - that microservices are not a “clearly better, why would you do anything else?” solution, and instead, you have to weigh the tradeoffs with a monolith. In this talk, Brian described the journey Intercom went on with their Ruby On Rails monolith.
As is often the way they started with a monolith and scaled rapidly both in terms of team size and infrastructure. They started to suffer from stability issues, and flaky tests. They suspected that these issues were caused by the inability of Rails to scale, so they began to build new features in standalone applications and extracted billing from the monolith.
Even with this change in architecture they were still struggling with the monolith and team coordination was becoming a bigger issue. They focused on getting good at managing the monolith. They built tools to help with stability and worked on…
- linting
- dependency upgrades
- test reliability and speed
- code ownership
- deployment
- scaling MySQL
- caching
After all that, the monolith was working much better, and coordination with the microservices was still a big problem, so they copied code from the services into their monolith.
Metrics, KPIs and Developer Experience: Rethinking Measurement For High Performing Teams
This was a great talk, and closely aligned to the challenges I am facing. They began by talking about how metrics are not strategy. Metrics are easy to measure, but hard to turn into actionable insights. They miss questions such as:
- are we working on the right things?
- are we reworking or getting blocked?
- do developers feel trusted and supported?
- is our current delivery pace sustainable?
They finished with a challenge. Audit one metric you rely on. What is it really telling you? And who is it serving? Is it helping your team improve? Is it aligned to your business goals? Is it reinforcing the culture you want to build?
Beyond “Try Harder”: Effective Strategies To Tackle Bugs
Bugs kill trust, confidence and momentum. If you can build systems that make doing the right thing easier then the time you spend firefighting will go down, and the business will start trusting you.
This talk didn’t have much depth, and the suggestions are pretty obvious.
Human-first Leadership, AI-Powered
This was quite an interesting AI-based talk as it was a set of tools Sterling uses to make him a more efficient manager, and to allow him to be more present with his team, more present with his family and reduce people’s dependency on him.
He started the talk with a confession that he talked for five minutes into his phone and used AI to turn it into an outline for the talk. Before adopting AI he would wake up with 100s of unread emails and slack messages, which took 1-2 hours per day to deal with. His family felt the pressure because Sunday evening was Monday morning for his India-based team.
He felt that he was never present in meetings because there no break in between, and not enough time to context switch. The mental load caused by knowing what he was dropping was huge.
Sterling advocates for starting simple - make use of AI transcription and AI meeting summaries. If you had an executive assistant what would you delegate? An AI should be able to do that.
Use AI to free you up to ask real questions and make real connections rather than tracking sprint goals or other info.
Rather than your team asking you what was decided and waiting for a response, they can ask an AI trained on the meeting summaries.
Fast, Informed, Impactful: How To Master Decision-Making
In this talk Katrin started by describing a scenario where a team built some software, but used the “wrong” technology. Once an architect found out they had to rebuild it using the approved technology, which caused a big hit to morale. Katrin then described a fairly standard RFC (request for comments) process and talked about how you need clarity over who is involved in a discussion, and how you should use a template to drive the discussion forward to avoid repeatedly discussing the same topics.
Tracking Repository Health at Scale
This talk was extremely relevant to things I am thinking about in my day job, so I was predisposed to loving it. Simon started with a discussion about what does healthy mean, and how do you know what constitutes your estate?
He talked about some “health principles”:
- Secure customer data.
- Easy to release, up to date and self-service.
- Consistent across the estate.
- Conformant - does it follow your rules?
Code health is about your code at rest, so it is not about DORA metrics or your KPIs. You can run static checks to determine the state of the code. For example, is the version of Node used an LTS version? Are the versions of the dependencies within two versions of the newest? Does it use any packages we’ve decided not to use?
Lastly, he talked about how to communicate the code health, and demonstrated a dashboard, and how they use that to show teams and stakeholders, and influence future plans.
Code Your Future
This was a short talk from the conference’s charity partner about how they give migrants software development training, access to support and recruitment help.
How To Delete Everything: The Clean-Slate Approach to Technical Strategy
Even if you were to going to get nothing from the content of this talk it would be worth watching for the classic Apple Mac slides on their own. Luckily, Plum is a LeadDev regular, and it shows. In this talk, she takes you through the decision process that many of us face - to debug broken code, or rewrite it?
Plum suggested taking an hour to consider your situation from a new perspective. Your current system has the advantage that it exists, but the new system doesn’t. Take on part of your architecture and discuss what would it mean to remove it? What inputs or outputs does it have? What processing does it do?
She then talks about how to approach a situation where your host is deprecating the version of Python you are using, and you have no choice but to act with a fixed deadline.
Rebuilding at Scale: A CTO’s Journey in a High-Growth Fintech
While I didn’t follow this talk or understand the point it was trying to make, Lee did introduce one concept that I like. Technical debt is well understood, but often it is caused by commercial debt. Commercial debt is caused by the hustle needed to get a business off the ground - such as bespoke deals that you didn’t originally anticipate.
Levelling Up: Transitioning Successfully into a Manager of Managers Role
This talk pretty much does what it says in the title. It’s a step by step guide on how to prepare for, and start being, a manager of managers.
Gisela talks about two changes that happen when you move up - there are visible changes, such as the HR system updates and having more meetings and more access to confidential information. There are also silent shifts, such as the time horizon you need to work in expands, and there are changes in the bridges you need to build and maintain.
Perception
No-one is coming to brief you. You need to see the dots and connect them. You see enough of the detail, and see enough of the systems, to notice what others can’t. You need to use these to help your execs make good decisions.
Patience
Wins take longer at this level. 6-12 months is normal. The nature of the problems becomes harder - complexity, dependencies, messiness and urgency. You will end up with outcomes that no one is happy with, but that everyone can tolerate.
Presence
You are an ambassador for your teams. You have to learn to negotiate and advocate for them. Be a translator to help people outside your teams understand. Sometimes you won’t be in the room, but your thinking will be.
Frictionless Movement: How Internal Mobility Transforms Engineering Culture
Small disclaimer with this talk - I was the technical adviser for LeadDev so it was great to see Tom had taken some of my suggestions on board.
In this talk Tom talked about how companies often make it easier to leave than to move internally. This creates unnecessary turmoil as people think they have to leave to grow.
Tom introduced a policy called “Transfer Windows” to help facilitate the moves. Some moves happened, but there was no mass exodus. The key thing was that people started to have conversations, and moving teams internally became an option.
Lost and Alone over the Pacific
Nick is the traditional speaker for the end of day one at LeadDev, and here he delivered one of his trademarked story talks. The topic for this year was a pilot who was lost over the Pacific, trying to find a tiny island in the dark, and how boats and other planes eventually helped him land safely. The moral at the end of the talk was that navigating the current AI landscape can feel like you’re lost and alone, but you’re not.
Comments