Design for Momentum: Give People the Experience of Winning. Frequently.

By Darryl Brown

In the last post I wrote about removing repetitive manual work from our process. In the post before that, about reducing the friction in how information moved through our team. And in Post 2, about shortening the release cycle so that work reached production in days rather than months. All of those changes had a secondary effect we didn’t fully anticipate: they made the experience of doing the job fundamentally different. This post is about that effect and about two additional changes we made specifically to address it.

I always knew that job satisfaction depended on the conditions around the work — culture, flexibility, recognition. Those things are real and they matter. What I didn’t fully appreciate until recently was how much the shape of the work itself contributes. Specifically: how long, how onerous, and how disconnected the journey from “I understand what needs to be done” to “it’s live in production” actually feels.

That journey has many steps. Understanding the task clearly enough to estimate it. Planning the implementation. Writing the code. Getting it reviewed. Getting it tested. Watching it release. Each of those steps, in our old process, was a source of friction, and the whole journey took months. By the time a developer’s work reached production, they had long since moved on to something else. They might have had to re-acquaint themselves with code they’d written weeks or months earlier just to answer a question about it. And the release itself, the moment the work actually shipped, happened at some distant point, executed by someone else on the team. The satisfaction of completion was diluted by time and distance until there was very little of it left.

That’s what we changed. Not just the speed, though speed matters. What we changed was the experience of completing something.

Today, a developer works on a task and sees it through to production while it is still fresh in their mind. The review happens within a day of the changes being made. Testing follows quickly. When the work ships — released by the reviewer or a quality engineer who has been closely involved — the developer receives a notification. That notification arrives while the work is still alive in their memory. The satisfaction of completion is immediate rather than deferred. The journey from start to finish is something they can hold in their head as a single experience rather than a series of disconnected episodes spread over months.

Several things contributed to improving job satisfaction over the last two years — the compressed journey from start to production, the culture of safety and experimentation, the removal of process friction from the work itself. But two of the more concrete and immediate interventions are worth describing in detail, because the mechanism behind each is instructive.

The first was moving to weekly sprints.

This was important in part because of a new challenge in our development context. Over the last two years our development work has grown significantly, and the markets we’ve begun serving changed the time horizon of that work. Tasks that previously unfolded over months were now expected in weeks or days. For a team whose processes were built around longer cycles, it created real stress, not because the work itself was harder, but because the rhythm of the work had changed and our systems hadn’t changed with it.

One of the things that amplified that stress was the backlog.

Every development team has more work than time. That’s normal and healthy. It means there’s always something worth doing next. But there’s a meaningful difference between an infinite pile of shifting priorities and a finite, agreed set of commitments for the current week. We had the former. People were staring at an enormous list of tasks whose priorities changed weekly, with no clear signal of what mattered most right now. The pile felt overwhelming not because it was larger than usual, but because it was unbounded and unstable.

The stress wasn’t really about the volume of work. It was about the absence of clarity. Sprints were how we chose to address this. Not a new idea, I considered it a good thing we were not inventing a solution from scratch.

A sprint is essentially a commitment: here is what we are certain about for this week, here is the work we are agreeing to do, and everything else can wait. The pile doesn’t get smaller. It never does. But it becomes legible. Instead of an undifferentiated mass of tasks, you have this week’s work and everything else. That distinction, it turns out, does a significant amount of the work that “motivation” usually gets credit for.

We started this process by looking at our metrics, specifically the average number of points estimated on work items we were completing each week, and used that as our sprint goal. It didn’t take long to notice a problem with that approach: average means you don’t hit the target half the time. It also didn’t account for unplanned work coming in from support. A sprint you regularly fail to complete is not a sprint that makes people feel like they’re winning. So we adjusted. We now define sprints with a lower total than the average — sprints that are genuinely achievable rather than theoretically possible. The goal is a sprint you can finish, not one that proves how much you can take on.

Once defined, the sprint lives on its own Kanban board with all work prioritized from top to bottom. A developer doesn’t need to ask what to work on next. The board answers that question. They can see exactly where the finish line is.

There’s a subtlety here worth naming. Priorities did still shift. That’s the reality of any software business, and we weren’t going to pretend otherwise. But the sprint created a protected window. Whatever was happening to next week’s priorities was not relevant — no developer was watching next week. Their current week was static. The work was agreed, the order was clear, and nothing was going to change it mid-stride. That stability, even just for five days, turned out to matter enormously. It’s the difference between running a race where someone continuously moves the finish line and running one where you can see exactly where it is.

The second intervention addressed the daily clarity problem.

Each morning, every developer receives an automated Slack message — built with n8n, drawing from both our project management tool and our code repository — that summarizes exactly what tasks are on their plate for that day. 

Here’s what one of those messages looked like for a developer on our team this week:

The odds of hitting your target go up dramatically when you aim at it.— Mal Pancoast

In Review

• TVC – Pipes welded too many times… 1

In Progress

• API 751 Create the Failure Reason chart… 2

Blocked

• Update permission on dashboards and tvc so all use… No estimate.
• Create a project progress chart… 3
• Audit Trail is not recording values populated duri… 3
• Traceability – Convert JS files to TS and add unit… 2

All tasks assigned to them, in priority order. All code reviews waiting for their attention. Everything in one place, at the start of the day, without anyone having to compile it or send it manually. And, because a little humanity goes a long way, a daily quote to start things off.

It sounds like a small thing. In practice it changed the experience of starting the workday. Instead of opening multiple tools and trying to reconstruct a picture of what needed attention, the picture was already there. One message. Clear priorities. No ambiguity about where to start.

It also removed a category of interruption we’d normalized without realizing it — the mid-morning ping asking whether someone had seen a review request, or the end-of-day message checking in on a task. When everyone already knows what’s in their queue, those conversations become unnecessary.

Underlying both of these changes is the same principle from the earlier posts in this series: don’t ask people to do things that the system can do for them. Sprints removed the need to make daily priority decisions. The morning summary removed the need to reconstruct your own to-do list. What remained was the work itself, which is what people came to do.

Shawn Achor’s research in “The Happiness Advantage” inverts the assumption most of us carry into work: that success produces happiness. His finding is that it works the other way. Positive emotion, a sense of progress, and small wins prime the brain for higher performance. We weren’t trying to make the team happier as a side benefit of moving faster — but Achor would predict exactly what happened: the happiness and the higher performance came together, both the result of designing a process where people could complete their work, see it ship, and feel the satisfaction of that — quickly and regularly.

Any developer will tell you: they want to build things and ship them. They want to hold a complete piece of work in their mind from start to finish and feel the satisfaction of seeing it land. The longer and more fragmented that journey, the harder it is to stay connected to why the work matters. We compressed that journey as much as we could. In LEAN terms, we were reducing cycle time, or the elapsed time between starting a piece of work and delivering value from it. Shorter cycle times don’t just improve efficiency. They improve the human experience of doing the work.

There’s a line I wrote in an earlier post in this series that I want to return to here:

Momentum creates pride. Pride creates ownership. Ownership creates quality.

I believe that. And I’ve watched it play out. When developers could hold their work in their heads from start to finish — when completion was days away rather than months — the experience of the job changed. They spent less time navigating process and more time solving problems. Which is what they came to do.

Job satisfaction, in the end, wasn’t something we designed directly. It was a byproduct of designing everything else well. Get the process right, shorten the journey, make the work winnable — and the satisfaction follows.

If a metric doesn’t change what your team does, it’s just something you’re tracking.

Next: as the work itself changed, so did the demands on the people leading it. The next post is about what happened when our directors had to shift from doing the work to thinking strategically about it.