A quick tour of delivery management (and why it matters) ⭐⭐⭐

What senior leaders mean by “delivery management,” why it matters, and how to improve it with practical tools and techniques.

Pat Kua, Seasoned Technology Leader & Coach

Trust

People struggle in delevering. It raises trust issues from stakeholders, and you need to build trust to be allowed to do good work.

There also are dependencies: Prduct success -> Marketing Campain -> Delivery.

What is delivery management ?

Delivery is tight to Time, Quality, Value.

It is a matter of ROI VS Tradeoff.

What do we need to measure?

• Time
  • lead time
  • deploy freq
• Quality
  • change failure rate
  • mean time to restore
• Value
  • € earned of saved
  • % of time spend on new capabilities

Books:

• Accelerate (2018)
• DX 4 (2024)

Who owns Delivery?

You all do: joint accountability. (in success and failure)

4-step Receipe / How?

1. Build a plan
   • 5 questions to answer
     • do we know the outcome?
     • do we know what we need to do?
     • do we know approx. how long?
     • are we aware of critical depepndencies?
       • gantt charts can be useful. No need to be super detailed here
     • how do we know we are done? what are the success criteria?
   • precision VS accuracy
     • we need to be accurate
     • we don’t need as much detail though if the project is big
2. Show constant visible progress
   • constant: show progress at least 1/week, 1/day if possible
     • have a good CD infrastructure
   • visible: user focus, beneficial to the business
     • books:
       • user story mapping
       • no estimates (good book, bad name)
     • use ChatGPT to help you split a user story into smaller chunks
     • what you see is not what others see
       • proactive communication
       • status report
       • steering meetings
       • raise in 1-1s
3. Anticipate the future
   • learn from the past: we can’t predict the future, but we can predict a few things
     • what has gone wrong in the past?
     • how can we reduce risk?
   • it won’t go perfectly
     • take contigency into account in your schedule
     • –> “under commit, over deliver”
   • there will be uncertainty
4. Drive decision making
   • book: High output management
   • establish a steering committee
   • present options and tradeoffs
   • decide and document the decision
   • communicate decisions

Engineering leadership playbook, 2025: Three lessons every engineering leader needs this year ⭐

Learn three key lessons to lead AI adoption, build remote teams, and strengthen engineering culture.

Lucas Mendes, Founder and CEO Revelo

From interviews with 50 Eng leaders, not a scientific study.

1. Pacing AI adption with an eye on ROI
   • different companies are at different points of the adption curve. There is no right answer
     • boilerplate code
     • documentation
     • test coverage
   • some use cases are low-hanging fruit
   • ROI is still a big question mark
2. building distributed teams with a strong dose of ownership
   • remote is default, but culture and connectionneed to be intentional
   • the shift to remote had changed how teams and team members are evaluated
   • “great distributed teams are not tracked, they are trusted”
   • standout devs are those who treat problems like thie own them
   • 3 dimensions of people: autonomy, mastery, puropose
3. staying closer to the work without micro mgmt
   • mgmt is 99% about discerning signal from noise
   • the most effective leaders are not burried in dashboards
   • the experiment with toosl, ship internal prototypes, stay hands-on with their teams

(the original presentation had 7 lessons to remembers, but it went back to 3 to stay in the 10min mark :)

Leader or engineer? Navigating our quiet technical identity crisis ⭐

Am I still technical enough? What does my team think?

Drawing from the hard-won lessons of a leadership initiative for 250 engineers, this talk uncovers unexpected truths in the conflict between technical depth and leadership.

Marcus Gardiner, Client Director: Energy & Utilities Softwire

4 different ways of being a technical leader:

• engineer
• architect
• team lead
• business partner

You can change, aquire new skills, to go from technical background to a more busniess partner profile.

You are not defined by your title; a title is a temporary badge.

There is no perfect choice. Choose, but choose lightly, then choose again.

How to maintain a codebase – when everyone can code

Learn how to maintain platform performance with machine-first observability, enabling AI agents to monitor and repair production systems.

Matt Collier, Technical Consultant Vercel

70% of PR for Claude code are created by Claude code.

All regular metrics / output are input for AI investigations. You need a very good CI/CD suite, with a very comprehensive test suite.

4 important things to remember

1. every output of the system is an input for AI
2. diagnostic tools should mirror input skill
3. capture every single log (no sampling)
4. decouple release from deployment (feature flags, blue green deploy…)

Things will happen gradually, then suddenly.

Effortless execution: Designing processes that don’t need babysitting ⭐

Discover five characteristics of team processes that can save your sanity, improve your relationships, and let your team take pride in being a well-oiled machine.

Antonia Scheidel, Engineering Director Duolingo

Five elements of self-sustaning processes:

1. Minimally invasive: find the smallest ask you can make of your team. What can you automate (or give up) to minimize cognitive load?
2. Transparent: develop automated systems that show their work, to help team members understand how their actions impact the process
3. Self-healing: borrow from coding tools like linters to flag process violations as soon as they happen and suggest remediation steps
4. Socially reinforcing: encourage people to take responsibility for a shared system with a touch of social pressure
5. Worth the investment: demonstrate the value you create with the time and energy you save

Which processes are worth investing in:

• save time (include hidden costs)
• ikea effect (people put more value un something they built themselves)

Theory to action: Architecting and implementing your team operating system ⭐⭐

Learn the theory behind the operating systems of high-performing engineering teams. Leave with a practical idea of how to design a flexible team operating system with rhythms, tools, and feedback loops for your team.

Meg Adams, Senior Director of Engineering The New York Times

Hom to improve cross-teams visibility?

If not intentionnaly build, you already are in an default Operating system. Did you design it or did it just evolved into this?

Start by documenting your existing OS (see bit.ly/os-template). Use your alien mind to see what is happening.

• people
  • who is it operating for?
  • what are their roles?
• structure: the set of rythms and rituals that shape our creativity
  • time: how we spend it is a direct refleion of what we value
    • meetings
    • events
    • business rhythms: yearly, quaterly etc…
  • informaion: how it flows through the organization (up, down, laterally, out)
• setting: the env in which teams operate and exist
  • physical?
    • space for focus, space for connection?
  • digital: what tools do we use?
    • also, who has access to what tool? Impact which voices are heard.
  • temporal: TZ and working hours
  • atmosferic: energic tone of our shared space
• norms: rules a group creates and abide-by
  • explicit: available in written form
  • implicit: need to be observed
    • who speaks, who is silent, in what conditions?
    • documenting norms can be tricky: use your alien brain
      • psychological safety
      • conflict ? decision meeting
    • –> do not share this right away, as naming can be perceived as judging

Quick wins:

• eliminate overlaping tools/meetings
• get rid of little used tools

Time to debug key problems. Can be small shanges or more lengthly topics to tackle. Analyse root cause and adapt.

THere is no definitive/perfect solution.

Share

• publish what’s working
• what is stable/healthy?
• be explicit and verbose
• use the OS as a tool of co-creation (as it will not work for everyone)
• –> make it a shared living artifact

The million dollar bug: Quality leadership lessons from costly failures ⭐⭐

CrowdStrike lost $5.4B, Sonos stumbled into a $500M crisis – and they’re not alone. Learn battle-tested leadership strategies to protect your organization from quality catastrophes that can shake your business to its core.

Christine Pinto, CTPO and Co-Founder Epic Test Quest, ambassador of Ministry of Testing

1. The mythology

Some mistake costs a lot of money. CrowdStrike lost $5.4B in choosing speed over quality. At Sonos, choosing speed over quality lead to layoffs and resignations, more than 500m$ loss, working on fixing mistakes instead of innovating.

In the age of AI, more questions raise. For example, at Klana, they started hiring humans back after migration to a full AI model. Quality broke without human.

Speed without quality is not efficiency.

The great lie is “Quality and speed are opposing forces”. It is not true. QUality is speed, competitive advantage.

2. The mathematics

Poor quality comes with unvisible costs (hidden impact stands for 95% of costs): customer churn, constant delay… Real cost of quality if 2.41 * Trilloni is US only.

Quality with sustainable growth engine:

• custimer trust
• code health
• dev speed

In complex systems, quality issues follow the domino effect.

(see tech debt death spiral picture)

It cost 6.5x times more to fix a bug now than when it appeared.

3. The mechanisms

Quality confidence matrix : customer impact X technical risk.

Technical decision to ship ususally are binary, but systems are getting more and more complex.

Pre-mortem audit quality audit:

• what couldl turn this into a Harvard Business Study ?
• which quality assomption could destroy us if we’re wrong?
• what’s the earliest signal this is going wrong?
• what if the AI looks right but is confidently wrong?

Translate like a strategist: from tech to strategic framing. Be relevant.

• slow CI pipeline -> bottleneck in dev delivery
• bug backlog is growin -> team is stuck firefighting, roadmap delivery at risk. (you cannont scale firefighting)

Build a Quality champions network, in every dpt. NOt a title, a signl that quality is everyone’s job. Start a system, not a crusade, so “everyone’s job” does not become “nobody’s job”. Move from gate keepers to functional team coaches.

4. The metamorphosis

Some companies made their quality system their competitive advantage.

Spotify:

• slow risky releases
• quality automation
• 1000+ daily deloys

Amazon:

• monolithic releases
• wuality ownsership
• 2-pizza teams (full autonomy and full ownsership of quality)

–> Use Quality Leadership Toolkit

One thing to do right away: Weekly 30min Quality Review.

10 things nobody tells you about OKRs

OKRs are a simple – and useful – sounding idea, but in practice, there are all kinds of troubles people get bogged down in. Here are ten, rarely mentioned, things that can help.

Neil Vass, Engineering manager Co-Op (very strong accent) neil-vass.com

It sounds all so simple, but you spend so much time implmenting it.

Book: John Doerr: Measure what matters. whatmatters.com

1. they’re so fast
   • original implementation of OKR at Motorola shifted the whole company in 2 weeks
2. sole focus
   • timeline.intel.com
3. boring
   • you won’t see people getting exited by it
4. nobody talks about what else whas going on
   • book: I’m feeling lucky, Douglas Edwards (goole story). WHat makes Google successful did not come from OKRs
5. aspirational vs committed
   • you can’t strech everything
   • fewer OKR = a lot more done
6. you can never pick the right measures
   • see John Cutler: cutlefish.substack.com for different kinds of OKRs and levels
7. you don’t need them at all
   • book: Good strategy, bad strategy, Richard Rumelt
   • listen to other teams priorities
   • emily webber: teamonion.works
8. dropping them might hurt
9. complements
   • book: 4 disciplines of execution, CHris McChesney et al
   • alernative method: Narratives, Commitments, Tasks (reforge.com)
   • alternative metdho: hypothesis drive development
   • alternative metdho: impact mapping (impactmapping.org) Gojko Adzic
10. how long change takes
    • book: toyoto kata, Mike Rother

Technical Steering Groups: Balancing autonomy, technical alignment, and speed through strategic collaboration ⭐⭐

Learn how technical steering groups drive technical alignment while fostering ownership – balancing autonomy and collaboration to fuel speed, innovation, and impactful decision-making across teams.

Elín Elísabet Torfadóttir, Engineering Manager Spotify

R&D at Spotify: 2700+ engineers, Stockholm, London, New York

Spotify engineering culture has been a key part of Spotify’s success.

TAG: Technical Architecture Group

Drive Spotify architecture decisions. Area specific advisory boards and 25 Technical Steering Groups

(see slide)

1 studio = 100 individuals, 10 teams, 70% senior engineers, staff eng & senior staff eng.

Very intensive production constraints, need for:

• developer experience
• contracts
• reliability (see spotify outage 16 apr 2025)

Engineers spend 20% of their time in Technical Steering Group, it is a lot.

How to manager autonomy VS alignment?

Bringing meaning helps a lot to motivation.

Technical Steering Group Runbook

Before you start:

• clear mission that makes sense (for the team)
• group composition: need for people to steer complex topics with broad understanding of the context
• ways of working: standard and clear (write things down)

How does it work:

• weekkly
  • standup meeting
  • deep dive on a topic
  • be transpaernt & celebrate: weekly slack-outs open-calls
• monthly
  • open dialogue: open tech forum, architecture reviews, workstream proposals
• quaterly
  • explore: risksvs opportunities, unknons

Workstreams

• short (lesz thant 2 months)
• clear outcome: decison making? ADR? …
• with the studio
  • junior get to work with senior people across the board

Build it / Ship it / Tweak it! (tweak=retros) Make people own their success.

Issues still to understand:

• tech / product interactions for infrastructure topics

If we are not failing on some things, we are not being brave enough.