84: Why Your Definition of Done Is Limiting Engineering’s Business Impact

Feb 24, 2026

A CTO coaching story reveals why busy engineering teams can still fail to move the business forward. A basketball analogy shows that merged code is not the same as scoring in production. The conversation covers symptoms of vague 'done', how limiting work in progress restores flow, and practical steps leaders can use to tie completion to real outcomes.

Ask episode

AI Snips

Chapters

Transcript

Episode notes

ANECDOTE

Busy Teams That Never Finish

Adam Horner recounts coaching a CTO whose teams looked busy but had more work in progress than engineers and nearly everything was nearly done.
The backlog overflowed, features lingered half built or half integrated, and the business, product, and engineers grew frustrated because work never reached production.

INSIGHT

Scoreboard Not Shot Defines Impact

Horner uses a basketball analogy: the shot or merge isn't the win; the scoreboard moving is when impact happens.
Business impact requires production use, telemetry, and organisational absorption, not just merged code or completed tests.

INSIGHT

Too Much WIP Erodes Ownership

Excessive work in progress fragments focus, dilutes ownership, and extends time to production even when tasks aren't technically hard.
Engineers mentally move on at merge time, causing the final 10% of work to consume disproportionate time because no one owns it.

Get the Snipd Podcast app to discover more snips from this episode

Get the app

What if redefining one simple phrase could change how your entire organization delivers value?

Build your own CTO Playbook at www.theCTOplaybook.com — the leadership platform built for the full CTO journey. Coaching, podcast, and community to help you lead with clarity, confidence, and strategic impact.

Why does the definition of ‘done quietly’ determine whether engineering effort turns into real business impact? In this episode, I share a coaching story from a CTO leading a busy organization where motion looked like momentum, but nearly everything stalled just before completion. The teams were working hard, yet features lingered in limbo, ownership blurred, and frustration built across engineering and product.

There is a mental model that reframes software delivery using a familiar sports analogy, showing why writing code or merging branches doesn’t move the scoreboard. Impact only happens when work reaches production, is absorbed by the organization, and enables the next move. This lens exposes how excessive work in progress stretches timelines, fragments focus, and erodes fulfillment for senior engineers.

I talk about what changes when leaders stop tracking activity and start insisting on outcomes. For anyone responsible for CTO leadership, engineering productivity, or scaling teams without burning them out, this conversation challenges how you measure progress and where you apply pressure.

You’ll Learn:

[00:00] Introduction

[01:12] How teams stay busy yet fail to move the business forward when finishing is unclear

[02:08] What happens when too much work in progress creates motion without results

[03:07] Why writing code and merging branches do not equal business impact

[03:56] How the basketball scoreboard analogy reshapes what done really means

[05:14] The leadership question that exposes activity over outcomes

[06:41] What changes when nothing new starts until something is fully done

[08:27] How redefining done restores ownership, focus, and team satisfaction

Find more from Adam on LinkedIn and YouTube, and explore coaching, cohorts, and how you can stay up to date at theCTOplaybook.com, helping you build your own playbook for your path at your pace.