Dear Dave,
Category: things tech workers reliably hate.
My guesses given this Family Feud would include: meetings, process, planning — the harbingers of building slow. AI is in; process is decidedly out, in favour of compressing as much as possible so we start at the end with the finished product and work backwards where we need to. Even the good old double diamond of design has become a dirty duo (say that five times fast).
But while AI has smushed the double diamond into a thin line, disdain for process is nothing new. The perils of moving slow have always been a concern in software development, and with good reason — the slower we are to get work in front of customers, the riskier it becomes. Over-investing up front in something people don’t value is wasteful and demoralizing.
What I’ve always noticed in conversations about speed, though, is that everyone has a different framework for what fast and slow actually mean. Where one person thinks two weeks is a compressed timeline, another thinks it’s far too long. We all look at the same project and see different scope. A designer sees information architecture foundations crumbling beneath the surface. A researcher sees a gap between the feature and the problem. An engineer sees technical gotchas. A PM sees an urgent customer escalation that needed to be resolved yesterday. So we debate scope, agree on a timeline, and everyone goes off to do their part.
Then comes the doing — and this is where things get lost.
There’s an update here or there, chatter among the working team. But for leaders and stakeholders, questions start surfacing quickly: What’s happening? What’s taking so long? What are people actually doing? Planning software provides answers, but in my experience they’re nearly always oblique — missing some layer of detail that someone needs, frustrating everyone in one way or another. These tools make work legible to the business, but they don’t tell its story.
This brings me to a distinction I come back to constantly in coaching: speed vs. momentum.
Speed is quantitative — the hours, days, weeks, or months it took to do the thing. Momentum is qualitative — how it felt while we were doing it. Did it feel like consistent forward movement? Did we learn from customers and the team along the way? Did stakeholders feel like they were part of the journey, or did the work just... appear one day?
The good news: momentum is entirely within our control. And it’s not about big, packaged updates. It’s the active Slack channel. The small win shared mid-sprint. The quick check-in with a stakeholder — not a formal update, but a genuine question or a focused ask for feedback. It’s showing how decisions are evolving, not just announcing where they landed.
Momentum is deeply undervalued. We focus on hitting the big deadline and sharing updates at milestones, rather than involving curious stakeholders along the way. This instinct is pragmatic (updates take time!) and, perhaps tacitly, defensive — we want to build conviction before exposing work to a wider, more senior, scarier audience. But the cost of that approach is that stakeholders experience the work as opaque, which breeds the very anxiety and scrutiny we were trying to avoid.
The instinct to keep momentum going is one of the clearest things I pattern-match in high performers. They recognize that bringing people along isn’t just about maintaining buy-in — it actively makes the work better. It treats stakeholders and customers as true partners, not a box to tick.
At a time when AI is compressing timelines and raising the bar for what “fast” means, momentum matters more, not less. When the output is faster, the journey becomes a differentiator. Teams that move quickly and bring people with them won’t just ship more — they’ll build the trust and alignment that lets them keep shipping.
Speed gets you to the finish line. Momentum makes people want to run the next race with you.
From being flattened beneath the double diamond,
Danielle.
I loved this one!!!