My Favorite Ideas from LDX3 🎟️

My personal highlighs from the conference.

Last month I spent two days in London for the LDX3 conference.

To me this was kind of a big deal because, to be honest, I don’t go to conferences that often. Most of the time, the opportunity cost of traveling + losing several days of work feels just too much, and my general laziness does the rest.

Instead, I am so glad that I did.

I had a blast meeting many internet friends (most of whom for the first time) and putting faces behind names. It was also a chance to connect with the latest industry trends: the talks were excellent and I took a ton of notes.

Me finally meeting in person many internet friends!

So, I am back in my cave now, going through such notes.

What do my notes look like? As a writer, I love individual ideas. I write down things that feel atomic — things that work well in isolation and I can later mix and match into larger articles.

In fact, the book that had the largest impact on my writing work is probably How to Take Smart Notes (which we are currently reading in our book club, btw!). It convinced me—about 5 years ago—to create and maintain a long-lasting repo of evergreen notes, to be used for writing and reflection.

Fast forward to today, I have 700+ of such notes, and I have written ~250 articles. The book was right!

So at the conference I did just that: wrote down the best ideas I heard, and stored them at first into a giant file, and then as individual notes on my Notion db 👇

I have a repo of evergreen notes on Notion that I use for my writing, with 700+ items.

Today, in the spirit of writing something different from usual, I will recap the ones that I liked the most. These will be 1) useful by themselves, and 2) all together will also give you a slice of the current engineering leadership zeitgeist.

Finally, I also write this as a nod to the great folks at LeadDev who organized the conference: they were really kind to invite me, and organized one of the best events I ever had the chance to attend.

So here is the agenda:

1. 🎯 Precision vs accuracy — by Pat Kua

2. 🔬 Quality confidence matrix — by Christine Pinto

3. ⚖️ Empowerment vs direction — by Lara Hogan

4. 🤖 Measuring AI impact — by Laura Tacho

5. ✨ Culture is what you leave out — by Charity Majors

6. 🪴 Growing engineers in the age of AI — by Meri Williams

Let’s dive in 👇

---

1) 🎯 Precision vs accuracy (slides)

Pat Kua opened the second conference day with a great talk about delivery management.

One of the ideas that I loved the most was the difference between precision and accuracy in software engineering.

At a high level, these are about:

• Accuracy — building the right thing (meets business needs).

• Precision — building it consistently (on time, good quality, etc).

This distinction matters because it leads to different failure modes for teams. You may have teams that are:

• Precisely inaccurate — extremely good at executing stuff, but it’s not stuff that brings a lot of value. E.g. they are overly focused on technical work and are somewhat detached from customers.

• Imprecisely accurate — they can identify where the value is, but they are inconsistent in the delivery. E.g. they make good plans but never ship things on time, or releases often lead to big fires.

Diagnosing how your team fails is the first step towards improving.

---

2) 🔬 The quality confidence matrix (slides)

Christine Pinto delivered a great talk about quality — this ever elusive concept in software.

A common approach to quality is that all changes are created equal, and should go through the same QA process. While this is hard-and-fast and has some merits, it also risks cornering teams into extremes:

• Too much — heavy quality control systems that make devex nightmarish and delay releases.

• Too little — move-fast-and-break-things cultures in which, after a while, you are only breaking things, and not moving fast anymore.

Christine proposes a more nuanced approach where confidence in what you ship should be proportional to two values: customer impact and technical risk 👇

The more the stuff is up and to the right in the quadrant, the more you should only ship it with high confidence and high quality.

She also argued that improving quality in teams is a journey, which usually goes through three steps:

1. 🦸 Crusader — some engineer acts as a hero that spearheads quality, largely on their own + influencing leadership.

2. 🪴 Coach — the hero teaches others, establishing quality principles and adoption.

3. 🌳 System — when critical mass is achieved, individual efforts turn into team processes.

---

3) ⚖️ Empowerment vs direction (slides)

Lara Hogan delivered an amazing talk — probably my favorite of the entire conf.

She went through what feels like different eras of engineering management over the last 20+ years, through the lens of a single, crucial tradeoff: empowerment vs direction.

As managers, we often tend to stick to the same playbook: the one we are the most comfortable with. Some of us like being more directive, while others (like myself) are more at ease when they can leave ample room for people to explore and develop.

Whatever strategy we like the most, there always come times where that strategy becomes ineffective. Sometimes it’s about the type of project, or the team, or a teammate we want to get the most out of.

Good managers should get comfortable with both ends of the spectrum, and the spots in between.

---

4) 🤖 Measuring AI impact (slides)

There is a lot of buzz around AI adoption in engineering teams, but most reports you can find focus on usage rather than actual impact.

Laura Tacho, as she often does, pulled signal out of the noise and provided a simple framework to measure AI that focuses on three areas: utilization, impact, and cost.

The AI Measurement Framework proposed by Laura Tacho

Laura argues that focusing on the % of code written by AI is like focusing on LOCs for engineering metrics: not totally useless, but surely inadequate to figure out how you are doing.

She also reported on how early we still are on the AI adoption curve, despite all the hype. As of today, top organizations (not average ones) still report only 60% of developers using AI on a weekly basis. Such devs, in turn, report around 4 hours of time savings per week.

We are talking elite organizations here — with their house in order and top notch developer experience: numbers get sensibly worse for the average team.

So, these numbers paint a wildly different picture from what you may get from social media, VCs, and entrepreneurs. AI may replace us all one day, but that day is not today.

---

5) ✨ Culture is what you leave out (slides)

One of the highlights of the conference for me was watching Charity Majors bring on stage the article she wrote for Refactoring a few months ago: In Praise of Normal Engineers.

She did an amazing job, and also added a few bits that were missing in the article.

One sentence particularly stuck with me:

“Great culture is when you can think of several great contributors that you esteem and would refer to other companies, but you wouldn’t hire yourself”.

I love this bit because company culture is extremely hard to capture, and a great way to do so is by thinking at the things you are intentionally leaving out. The things you are not.

You might be a company that hustles and moves fast, or one that is thoughtful and sweats the details. One that thrives through process, or one where people need to be comfortable with a little bit of chaos. One that looks like a family, or one that looks more like a professional sports team.

For each of these, there is largely no right or wrong: the particular combination of qualities that make up your culture will be a good fit for some people, and a bad one for others.

Being aware of where you stand is important to make sure you bring in the right ones.

---

6) 🪴 Growing engineers in the age of AI (slides)

Meri Williams delivered a fantastic talk about how the life of junior engineers changes with AI, and what we should do about it.

We often say that AI makes the job market harder for junior engineers, because it can do a lot of what they are capable of. The second-order effect is that juniors are expected to do a lot more than just a couple of years ago, like:

• Critical thinking — they need to constantly question the why and the how provided by AI.

• Code reviews — with AI writing a lot of code, they need to review that code all the time.

• Systems thinking — they are given bigger pieces of work from the start, which requires them to employ non-obvious design chops.

None of this is work that did not exist before — but people now encounter it way earlier in their careers than previous generations.

So how can they cross this chasm? Meri argues that teams will need to focus more intentionally on teaching and mentoring, because the speed at which learning happens through simple osmosis is not enough anymore.

---

📌 Bottom line

And that’s it for today! Here is a recap of the six ideas, in one sentence each:

1. 🎯 Build the right thing, then build it right — distinguish between accuracy (what) and precision (how) to diagnose and fix how your team delivers value.

2. ⚔️ Match your quality process to the risk — apply stricter QA to changes with high customer impact and technical risk, and be leaner with the rest.

3. ⚖️ Adapt your leadership style to the situation — the best managers fluidly switch between giving more direction and empowering their teams based on what's needed.

4. 🤖 Measure AI true impact, not just usage — to understand the value of AI, focus on hours saved and overall cost, not vanity metrics like lines of AI-generated code.

5. ✨ Define your culture by who you wouldn't hire — a strong culture is clear about the great people who, despite their skills, wouldn't be a good fit for your specific team.

6. 🪴 Mentor junior engineers more intentionally — AI requires junior engineers to develop systems thinking and critical skills earlier, making deliberate mentorship essential.

---

See you next week!

Sincerely 👋
Luca