LDX3 London 2025 (Day 2)
This is the second part of my write up of the LeadDev London 2025 conference. To read my thoughts on the talks from day 1, and my overall impression of the conference please read my previous post. As with that post this is just the summary of my notes, so will give you a flavour of the talks.
I attended a training session with Suzan Bond in the morning. I’ve included my thoughts on that at the end of this post.
The videos of the talks are available here if you sign up with a free LeadDev account.
From dashboard soup to observability lasagna: Building better layers
Designing for reliability is made up of two parts - proactive and reactive. Proactive work is knowing that your system will be ok, while reactive is knowing that you will be alerted when it’s not. If you just start building dashboard, metrics, etc, then you’ll end up with soup. Instead you need to design them.
Start with a prediction - how should the system work?
Prove that prediction - show what it actually does.
Then measure - what can’t you answer with the data you have?
Predictions can’t be tested with tests. You need experience of what strain looks like, e.g. alert storms.
Typically, dashboards only answer specific, often now irrelevant, questions. They can be static and disconnected from the rest of your stack. You should consider dashboards as part of your product.
Connect layers of observability to enable you to dig into problems. Start with overview dashboards, link them to system dashboards, which link to logs, and finally link to traces. The overview should be a triage tool to show you the infrastructure health. Systems dashboard should show the complete health of the system.
Always think about user impact. Don’t think about how long does it take? Think about how long does it look to the user?
Growing pains: Scaling and re-architecting systems under fire
The first step when you are facing growing pains is to get buy-in on the pains, the solution and the process. The pains you are facing could be availability, scalability or reliability. Talk about the impact and the cost proposition.
For solutions it helps to get buy-in from stakeholders, even if it’s an engineering decision.
Level of effort + impact = return in investment
You can’t just disappear during the project, you need to get buy-in on the process so you can keep getting the buy-in to continue. As part of the process, think about your exit strategy - think about how and when to change tack.
Being secure by design: Engineer-led security
Security is a serious business, and the risks are high. The risk to your company’s reputation, operation and data. If you don’t take security seriously there is a risk to your teams, even without an incident - your company may hire external consultants and introduce process and red tape.
DevSecOps is the movement to include security in DevOps and make security everyone’s problem.
To introduce this to his company Dan ran workshops with all stakeholders to find out requirements. They shared information to show people the secure path, and gave them support. They taught devs how to think about risks.
They also collected data and reported to the Head of Department about vulnerabilities in third party libraries. They categorised the data based on a risk and provided a path for handling it.
Dan finished by saying that security threats will only increase, but engineers optimise themselves when you give them a mission.
Balancing direction and empowerment
Lara Hogan is a LeadDev regular, and in this talk she discusses how to balance telling people what needs to be done against giving people freedom to choose their own path. She starts by reminding us that none of the engineering management practices we spend so long talking about matter, if the business doesn’t succeed.
Consider what you are empowering people towards, if the business is faulty? Are you optimising to minimize layoffs? Efficiency? This is your “why”.
There are two ends to the management spectrum:
- Empowerment - Used when you need to gather buy-in, when you need creative ideas, and when you have lots of time.
- Direction - Used when people need clarity, when you have new people, when there are big risks to the company and when you have no time.
Pay attention to the context and be intentional about where you are on this spectrum.
Neurodiversity: From struggles to solutions, tips for leading a team
This is a nice simple talk organised around eight tips for leading neurodiverse people. The talk starts by discussing the difference between authoritarian, permissive and authoritative leadership styles. It then features several tips about how to approach difficult conversations, and how to work with your reports to come up with solutions to problems together.
What’s my job again? Developing self-management
This is a talk about how to work out what your job is, and to come up with a strategy for doing your best work, all through the metaphor of racoons.
It is important to remember that good strategy is only good in context. When the context changes, you need to change your strategy. Cate talks a bit about product strategy, a bit about technical strategy, and a bit about how you can use different leadership styles to get things done in different contexts.
So you want to hire engineering force multipliers?
If you want to hire force multipliers, you’re looking for unusual people. Hazel’s talk attempts to show you how to find them by experimenting with your interview process and assessing it for bias.
You should be looking for people who…
- Build a cumulative culture.
- Have intellectual humility - people need to like you to be a force multiplier.
- Ecological awe - they should not optimise for one thing, they look for a balanced ecosystem.
Use questions that can’t be answered to filter out people trying to fake it with AI. Test your questions extensively, including on your own team.
As an example Hazel considered the question “How would you approach splitting a monolith?” Instead they propose replacing it with “Let’s work together and examine the process of splitting a monolith. How would you approach this culturally and technically? Let’s focus on the human elements first.”
Getting excited about maintaining legacy systems
Maintaining software is a different skill to working on a greenfield project. Legacy code is part of every job, but it provides an opportunity for learning - there are many stories encoded in the code.
Tech debt is linked to developer productivity and happiness. As senior engineers we lead the way for others, and set the tone for dealing with legacy code.
Doing nothing to fix technical debt results in the “software event horizon”, where it can become impossible to fix bugs. In this talk Blanca discusses how to use systems thinking to create a map that will help you to understand what the code is supposed to do. Talk to people involved in the system. Look at the edges to see what it is connected to.
Document incident reviews, track where technical debt might be introduced into your system, and monitor the developer experience. Use these to develop practices to prevent the technical debt from growing.
A safe place to land: Practical (and hyper-scale tested) advice for technical decision-making while evolving systems in place
In this talk Inés discusses how to create a process for making technical decisions while working on an existing system. In it she talks about how Fastly evolved their systems dashboard, and the process made it more reliable, easier to use and easier to innovate with. She also discusses how they used AI to help make decisions, and speed up the implementation of their changes.
Mastering Managing, Mentoring, Coaching (Workshop)
As usual at LeadDev conferences they offer a series of microworkshops alongside the standard talks. I attended the session on mentoring and coaching with Suzan Bond. This was a good session, with a nice mix of presentation, discussion and pair work. It was definitely a nice change from sitting listening to talks all day.
In the session Suzan began by discussing the difference between mentoring and coaching. Mentoring is telling someone, while coaching is asking questions to help them find their own answers. Mentoring is easy, because you just tell people what you did and what your experiences were. Coaching is harder.
You should design the alliance between the two of you. How do you want to work together? Try to create a partnership. When discussing things “Why” can be accusatory. “What” asks people to explain.
Comments