LDX3 London 2025 - Day 1

Les colliers: blue collars VS white collars…

  • ⭐⭐⭐: top session
  • ⭐⭐: very interesting session
  • ⭐: ok session
  • nothing: kind of a waste of time for me

Shaped by demand: The power of fluid teams ⭐⭐⭐

Discover how Demand-Led Planning enables teams of up to 200 people to reorganise quarterly and succeed without stable, long-lived teams.

Daniel Terhorst-North

Business agility. Desing the best team (best structure, best work) for now.

Best work:

  • discretiony
    • delivery (features)
    • discovery (learn, reduce risk)
    • kaizen / continuous improvement
  • mandatory
    • BAU business as usual
    • failure demand (indicent, follow up)

Best structure?

  • small demand + small team = sucess
  • lot of demand + lots of (identical) teams = challenges

We shape demand tofit stable long live fearture teams

  • stable: it is expensive, we think it takes time to create a team (storming, forming, norming)
    • it’s not
    • storming, forming, norming can happen simultaneusly
  • long lived suggest work is homogeunous alnog time for long lived work
  • feature teams: not everything is a feature

We shape teams to fit demand

–> demand lead planning

  • step 1: identify the demand
    • start with all the demand
  • step 2: allocate spend
    • quarterly: decide between different work (feature, discovery). NO zero allowed!
  • step 3: pitch the demand
    • scales up to 200 people
  • step 4: introduce the constraints: - 3-10 people - full autonomous (skills, knowledge, experience, authority/permission, resources), no external delays - no work unstaffed - bumble bees (people floating around tseveral teams) - no more 3 teams / bumble bee - no more than 3 bumble bee in a team - min/man movers between teams (at least 2 people stay in a team to keep knowloedge) - min/max durations (how long you stay in a team)
  • step 5: run around
    • no one wants to do the reporting :)
  • step 6: test and iterate
  • step 7: declaure e Big Hairy Audacious Goal
    • very high energy
  • step 8: break bread
    • has to be in person, physical

Considerations: before, during, after

  • faciliation / logistics
  • survey: string agree, feel energized

–> https://goalwards.co

Training innovation: The key to long-term success ⭐⭐

Innovation doesn’t just happen – it’s a skill that must be trained. Learn practical techniques for fostering innovation in engineering teams, from mindset shifts to structured frameworks.

Mykola Kondratiuk, Program Manager Playtika

Repeatable and structure innovation. Innovation is a muscle, it requires training.

Myths:

  • need to be a genius: everyone can
  • randomly happens: structure creates outcome
  • lone heroes: team drive real progress

What he learned:

  • assigned topics failed
    • stop micro management
    • people are just executing
  • passion-based self-selection succeeded
  • ownership drove real engagement

Framework

  • P: protected time
    • leadership commitment
    • block calendar time
    • measure outcome
  • R: regular sessions
    • share ideas early
      • so we don’t invest time on useless topics
    • gather feedback
    • iterate
  • M: Marketspace hackathon
    • 2 day event
      • management make it happen( food, space, time)
    • self organized teams
    • rapid prototyping
    • businness alignment
  • I: integrated with OKR
    • align to business
    • make outcomes measurable
    • avoid innovation theater
  • E: external inspiration
    • conferences
    • workshops
    • meetups

the best way to predict the future is to create it

How to keep everyone happy (on a shoestring)? ⭐

As engineering managers, we’re often caught between cost cuts, tight deadlines, and team well-being. This talk shares real strategies for making tough trade-offs, prioritizing what matters, and keeping everyone engaged.

Neslihan Şirin Saygılı, Co-Founder Prisync

Key takeaways

  • Strategies for navigating limited resources, tight timelines, and an ever-changing landscape without sacrificing team morale or customer satisfaction.
  • A framework for making decisions that feel impossible, and knowing when to adjust your course.
  • Insights on managing the emotional side of leadership – how to invest in your “emotional bank account” with your team, manager, and customers so you don’t hit zero.

Limitations: budget, headcount, time, life

Sometimes, we expenrience crisis (everything appening at the same time)

Happiness sparse matrix : people (lead, board, team, customer) / limitations (niko niko like) Interpret results (customer happy, company not happy). Where are the problems?

Heuristic 1: pizza trade-off

  • rotating priorities (each team has a different teams priority)
  • time is currency

Constraint satisfaction problem:

  • NP problem
  • no clear/clean solution

Heuristic 2: good enough plans

  • better to fix 70% today than 100% too late
  • keep stakeholder informed regularly

Heuristic 3: prioritize the impact

  • not al problems are equal weight
  • sometime smaller issues can have a big impact on team

avoid the avalance;

  • don’t just fix the bug
  • root cause culture, not blame
  • fix 1 thing fully, not 10 badly
  • keep the bigger picture in mind

Emotional bank accounts

  • every day, account leaks small amount
  • big projects are large expense
  • avoid to hit zero: deposit money from time to time
    • casual coffee: we are together
    • share credit
    • listen
    • be accessible
    • invest in devs: books, hobby projects, youtube channels…

–> Managing tech crisis is not about being a hero, it is about being a human.

Accessibility of codebases: Leader’s perspective ⭐

We explore making codebases approachable, onboarding efficiently, and learning stress-free. Discover tools, metrics, and techniques to build a codebase your team enjoys working on and feels confident contributing to.

Osada Paranaliyanage, Software Engineering Team Lead BBC

Each of team member may be able to approach code base and modify it.

Hidden cost of inaccessible code:

  • bugs
  • effort
    • stress / fear: unrealistic expectations
  • onboarding becomes difficult, new hires take months finding their way

Accessibilityu

  • cpde health
  • correct platform
  • knowledge base: why
  • learning curve

Measure code health to reduce complexity

  • cyclomatic
  • coupling
  • haslstead measures
  • maintanbility index
  • but also
    • enclose diagrams
    • hotspot analysis

Correct platform:

  • do you have the correct asbtractions?
    • balance cost VS value
  • avoid privet jargon
    • use industry stabdard terms
  • apply patterns consistently
    • have a default tool

Forms of knowledge sharing:

  • written / static: very costly
    • ADR / RFC
    • API Specs
    • Wiki
  • interactive: high level reviews
    • presentations
    • conferences
    • lunch & learn
  • embedded: in-context reviews
    • PIR
    • code review
    • design review
    • office hours

Making it better! pragmatic, not dogmatic:

  • dialogs, not distats
  • document and flaunt
  • automated enforcement
  • measurements, not targets

Learning matters! Leadership matters!

  • make learning visible
  • make learning easy
  • make learning normal
    • say “I don’t know, but I’m gonna find out”

Metrics, KPIs, and developer experience: Rethinking measurement for high-performing teams ⭐⭐⭐

This talk challenges traditional engineering metrics, exploring how to balance KPIs with developer experience using frameworks like SPACE, ensuring teams achieve great results without burnout.

Oge Opara-Nadi, VP of Engineering Hey Savi

Metrics vs strategy

  • what we do, what we should be doing
  • track what’s easy to measure, define the problem we trying to solve
  • build dashboard to show progress, tie metrics to decision points at each leadership level
  • report metrics upward (no context)

When metrics fall short

when metrics don’t relfeclt reality, teams drfit, delivery derails & leadership loses line of sight

What traditional metrics miss

–> Metrics should bring insights, not noise. What we collect shows output, not if we are working on the proper topics. It doesn’t tell how the team is doing. Measure to inform decisions, not just to report. Writting the code is the easy part, working with human being is the difficult part. Let’s make it sustainable.

Data driven engineering excellence

–> metrics should drive strategy clarity

  • derive ROI from eng investment
  • dapat ways of working with teams
  • identify & scale best practices
  • remediate sub optimal patterbs
  • enable transparency & agility

Smarter framework

DORA / SPACE Outcome metrics VS experience drivers

  • DORA = Deplioy freq, Lead time for change, change failure rate, tome to restore
  • SPACE = Satisfaction Performance Activity COmmunication Effichence

–> the right metric balance output and experience, helping you steer delivery and culture without over measuring

from insight to action

Metrics become powerul when they trigger action (better decision, stronger outcomes)

Your next step

Audit 1 metric you rely on: what is it telling you? ANd is it serving?

  • is it helping your team improve?
  • is it aligned with your business goals?
  • is it reinforcing the culture you want to build?

Make it collective.

Beyond “try harder”: Effective strategies to tackle bugs ⭐

“Just try harder” isn’t a strategy. Learn three proven approaches – monitoring bugs, managing legacy systems, and optimizing feedback loops – that empower teams to deliver better software.

Andy Weir, Technical Consultant Headforwards.com

Let’s stop blaming people and start fixiing the system.

  • minimize “bag size”
  • avoid overhead (more checks, more approvals etc…) drains the flow
  • fast feedback
    • in the time it takes to make a cup of tea
  • smaller and saver changes
  • controlled delivery: find bugs before you customers do
    • feature flags
    • monitoring and observability
    • build safety nets to build a low-risk env. Fasr delivery is not enough

–> build systems that make the tight thing easy

Human-first leadership, AI-powered ⭐⭐

Discover how AI can free engineering leaders to focus on people, not process – driving innovation without losing the human core.

Sterling Chin, Senior Developer Advocate Postman

Objective: More time spend on 1o1s, on human, with the power of AI. “Time to First Human”

Information was spread everywhere in many tools (slack, emails, jira, confluence, google docs…)

Journey:

  • start simple (copy.paste slack into AI: what did I miss?)
  • have a tool to sumup meetings

–> they are no silver bullets when it comes to AI tools

If I had an executive assistant, what would I delegate?

Be transparent abot using these tools. If there is something private, stop the tool. Build trust within your team.

Tools:

  • Bloks (AI note taker)
  • MacWhisper (AI transcription service - understands tech stuff)
  • Google Recorder (voice memo -> accurante transcription)
  • Claude Projects
  • MCP servers (Model Context Protocol)

MCP

https://modelcontextprotocol.io/introduction

Where AI meets your context.

(shows 2 examples of MCP interacting with Google Calendar)

Fast, informed, impactful: How to master decision-making ⭐⭐

Master the art of efficient decision-making and turn slow, ineffective engineering decisions into a powerful competitive advantage.

Katrin Freihofner, Co-founder Straion

Ineffcient decisions means missed opportunities, frustrated teams, and lost momentum.

(We do not only build software, we also have to maintain it.)

Usually, companies use a RFC like process:

  • research and document
  • gather feedback
  • make a decision: how to build?

It shoul be used not only for bug decisions, but for all decisions.

Benefits:

  • transparency
  • building confidance in the organisation in decision making
  • avoid redondent conversations
  • cross team/functional collaboration

Drawbacks:

  • unclear ownership & roles
  • bureaucratic bottlenecks
  • poor tooling
  • endless reviews, repeated debates

Teams work around the process to progress.

5 steps to make Fast, informed, impactful decisions

  1. get a template
    • motivation
    • goals
    • non goals / out of scope (very important!)
    • design proposal
    • risks
  2. automate creation
    • use AI tools to summarize discussions
  3. define clear roles:
    • DACI model
      • Driver: keeps the process moving
      • Approver: final decision authority
      • Contributor: provides input
      • Informed: kept in the loop
    • accountability, clear responsabilities, faster decisions
  4. scope: always clarifiy the scope, prevent the conversation from moving out of track
    • have a friendly “out of scope message” ready. Thank you for your suggestion etc..
  5. automatic updates
    • explicit timelines (avoid endless conversations)
    • automation for notifications (slack, email…), track status, notify stakeholders
    • communicate outcomes

The five stages of workplace culture ⭐⭐

Discover the five key stages that built Softwire’s award-winning culture and motivated top engineering talent.

Zoe Cunningham, Director Softwire

  1. perks
    • unlimited chocolate, food table, company holiday etc…
    • this is not as important as you thik it is, it is not going to cement the culture
  2. trust
    • sharing key information across the company to allow people to trsut us
    • keep working on it as we keep growing
  3. work
    • 3 days of morale (picnics)
    • not opposed to work
  4. career
    • everyone is looking for some form of career dev (not only title, pay raise, but also learning skils…) and is ready to move it does not mean the same for everyone
  5. purpose
    • what is it for?
    • why are we having fun?
    • individual VS organisational purposes

Creating the next generation of senior engineers ⭐

An introduction to the science of teaching – pedagogy – how it applies to leadership and techniques to grow our teams in the era of doing more with less.

Alasdair Smith, Staff Product Engineer Natcap

Pedagogy: the science of teaching

  1. understand your learners
    • understand mental models: expert VS non-expert
    • get your coaching hat on: ask questions, be patient, reframe or ask more questions
    • pitfall: expertise reverse effect. Technicques thats techniques that work for experts do not work for non experts
      • get practical
      • encourage experementation
      • practice empathy
  2. structure your learning plans
    • backward design: from outcomes to learning objectives
  3. teach
    • working memory (short term) VS long term memory
    • teaching does not put anything in long temp memomry, only working memeory
    • requires cognitive load on the learner to put it into long term memory

How to succeed in teaching?

  • stay focussed on 1 or 2 objectives
  • use preductions to check progress
  • write off-topic subjects aside (to go to it later on)

Book: Teaching tech together

Don’t drop the baton, or how a team that communicates well collaborates well

Effective team communication shapes company culture at all levels. In this talk, we’ll explore habits, principles, and frameworks to foster healthy communication patterns.

  • Mathias Meyer, Founding Partner & Executive Coach The Intentional Organization
  • Sara Hicks, Founding Partner & Coach The Intentional Organization

(talk about their book for a long time)

(lenghty metaphore about passing the baton / handoff in team running sprint – passage du relai de course)

Communication deserves practice, time, repetition.

examples:

  • it is not clear where the organization is going
    • focussed on 3 clear priorities for the company
    • some priorities were conflicting led to slow progress

RAD framework

  • Reflect
  • Assess
  • Do

(I left before the end)

Documentation and AI: How to write right now ⭐⭐

Think AI can handle your documentation? Sometimes. This talk breaks down where it helps, where it doesn’t, and what still needs the human touch.

Heidi Waterhouse, Coach Alchemist Accelerator

Technical writting is not about typing.

Things I learned as a technical writter:

  • most people reading docs are already frustrated
  • most people writting docs are also frustrated
  • tech writting is boring on purpose
    • you should just get the information that you need
    • you should not know who wrote it

Content is central, but context is just as crucial.

Book: Docs for developers.

What would an ideal docs AI provide?

  • reduce toil
  • understand code
  • capture business logic
  • organize itself
  • perfect synchronicity
  • accessible
  • cheap
  • accurate

AI and LLM have their limits (can be seen as strength). It is better to use smaller robots that can do 1 thing well

  • extract
    • discovery
    • content collection
    • ex: glean, algolia, unblocked, swimm, mintlify, documatic
    • keyword: entrerpise search software
  • refine
    • grammar and spelling checks
    • linters
    • formatters
    • ex: acrolinkx, docrock, sikich
    • keyword: knowledge mgmt, writting refinement
  • presentation
    • context
    • acceisble
    • i18n
    • ex: github, clickhelp, docusaurus, confluence
    • keyword: information archi, content mgmt, knowledge hub
      • confluence paired with another search engine moght yield much better results
  • iterate
    • required understanding human feelings
    • ask humans if this doc was usefull to them
    • room for lots of improvements

Tool must-have:

  • export test, meta-text, context
    • every vendor prevents this, want to keep your inside their silo
  • audit
  • integrate

Where does AI help?

  • raw power
    • eg, crawl 80 Go of doc
  • rote tasks
  • predictable contexts

Where is AI an impediment?

  • new things
  • weird contexts and crossovers
  • business decisions
  • feelings

AI cannot understand but is good machine at what it does

Reward technical writting (implies you will have to read it)

New book: Progressive delivery (how to add human to the devops life cycle)

Rebuilding at scale: A CTO’s Journey in a high-growth fintech ⭐

How a high-growth fintech dealt with a major platform rewrite with 10 years of technical and commercial debt. And, more importantly, my own personal growth journey from tech leader to exec-level CTO.

Lee Provoost, CTO Flagstone

How to succeed when you are “average”?

  • understand your superpower. (Lee is an eternal optimistic and a big risk taker.)

Technical debt is easy.

  • commercial debt = sum(technical, product, business, decisions) < now() * hustle

Where is the money?

  1. focus on growth opportunities
  2. don’t pursue all or nothing
    • learn from bad decisions
    • incremental plan (where revert/stop is on a small scale)
  3. trust from peers and board

Trust is key

  • your own senior technology leadership team is NOT your first team, the ExCo is
  • that’s where you have to build trust
  • that’s where you can ask for help and support
    • this is a show a strength, not a weakness

We are all in this together

  • not just a complex technical project
  • it is a business wide transformation
  • not everything is a tech problem

The project was not an agile project, it was a clear waterfall project.

  • just accept that and name it
  • do not perform agile artificialy with ceremonies (all of them were not necessary in that context)
  • stayed agile with the decision process

Hire the best you can afford. People that persevere, do not quit, keep on digging. Hand select your team.

Look after yourself. Send the right example to your team.

Recap:

  1. undersqtand your superpower
  2. leverage your first team
  3. technical -> commercial debt
  4. hire the best you can afford
  5. look after yourself

Levelling up: Transitioning successfully into a manager of managers role ⭐⭐

The talk I wish I’d found when I became a manager of managers. Tips and insights to prepare you for the road ahead.

Gisela Rossi, Engineering Director Trustpilot

Skills to master when you’re an EM and that will help you in growing to a manager of managers:

  • supporting people to grow
  • creating conditions for people to thrive
  • adapting to organisational changes
    • when leadership is needed the most
  • efficient execution

When you are manager of managers; 2 types changes are ahaed:

  • there will be visible things that change straight away
  • there will be subtle silent shifts
    1. informational shift
    2. temporal shift
    3. relational shift

New skills to aquire: The 3 Ps:

  1. Perception (for the informational shift)
    • listen to smaller signals
    • dive to get information (it won’t always come to you)
    • no one is going to brief you
      • –> you see enough of the detail and see enough of the systems to notice what others can’t
    • decision will happen all the time around you
    • in concrete:
      • ⬆️ upwards: summarize info for VP/C level so they can make the better desision
      • ⬇️ downwards: scan for pain points and opportunities, spot patterns, jump to action
  2. Patience (for the temporal shift)
    • time horizons change: wins take longer to show
    • nature of problems change: more complex, more dependencies, more messiness, more urgency (it takes time to come to you)
    • resolution looks different: no one is happy, but everyone can tolerate
    • in concrete:
      • what can I fix for next year? (instead of this week)
        • trust the work
      • prioritize and adapt (it can be constantly changing)
      • resolutions: grow your tolerance to impectfect compromises, accept you can’t fix everything
  3. Presence (for the elational shift)
    • how you show up on the organization is now more important than before
      • ambassador for your team(s), for the tech dpt, the whole engineering
    • be an ambassador
      • learn how to negociate. Progress is actually build on compromises
      • build cross-org relationships early (before you need them)
      • understand what drives people
      • advocate for your team
    • in concrete:
      • be a translator, help people understand, try to speak their language
    • sometimes you won’t be in the room, but your thinking will be

Growth and comfort never coexist.

Yes, it does gets messier, it does get slower

–> material to check: https://docs.google.com/document/d/1TKrg8Udz2C4Mslm4Pm42NtfwrYSeWay6QjQy40fqWCs/

Frictionless movement: How internal mobility transforms engineering culture ⭐

Creating an environment that not only makes it easy for people to move teams and roles but encourages that openness.

Tom Murton, Product & Engineering Leader MrQ

We have a movement problem. 50% of people find it easier to find a new job than to move inside their comapny.

Why it matters?

  • retention
    • employees stay 41% longer at company with a high mobility
    • 61% city upskilling as a motivation to do so
    • 57% want to upgrade their skills
  • productivity
    • 13% more productive
    • 31% currently feel engaged at work
  • finance
    • 0.5 - 2x cost to replace someone. It is bigger in engineering
    • +18% of new employees a likely to live in their 1st year

The journey:

  • individual moves
    • create development plan
    • open up roles internally
  • lightweight programs
    • exploration with DX
  • whole of tech rollout

3 starter ideas:

  • team swap (permanent or not)
  • vacancies
  • conversation

Keep supporting it:

  • psychological safety
  • leadership support
    • celebrate & promote
  • transparency
  • context & adaptation
    • every company, team is different

Common concerns/myths:

  • mass movement myth
  • project delay myth
  • promotion only myth

–> WHat would your teams unlock if they could move freely?

Lost and alone over the Pacific ⭐⭐⭐

On December 22, 1978, veteran US Navy pilot Jay Prochnow found himself lost over the Pacific after a navigation failure during a solo ferry flight. With no land in sight and nightfall approaching, he had to find a way to survive. This is the story of how he navigated out of the crisis – and what we can learn from his experience.

Nick Means, VP of Engineering MedScout

(as usual, a great story diffcitul to transcribe here nicely)

The Pacific ocean is really massive.

Story of a 4 day travel between LA and Sidney in a Cesna with no auto pilot.

See https://en.wikipedia.org/wiki/Cessna_188_Pacific_rescue

Réactions