Monika Dainyte recently shared something that caught my attention: "There’s a number behind teams that last. Twenty miles." She retold the 1911 race to the South Pole and pulled out a simple rule from Jim Collins' "Great by Choice": the Twenty-Mile March - the idea of covering the same distance every day, regardless of conditions.

In Monika’s words: "Good weather, stop anyway. Bad weather, march anyway." No hero pushes. No "we’ll catch up later." Just a pace you can repeat.

That story is polar exploration, but it lands hard in modern product and engineering work. Teams do not usually fail because they cannot sprint. They fail because they cannot pace. And the most dangerous moments are often the "good weather" weeks when everything seems to be going well.

The Twenty-Mile March, translated for teams

Jim Collins used Amundsen’s approach to explain a broader principle: the best performers create a self-imposed, consistent operating rhythm. It is not maximum effort. It is controlled effort.

"Consistency beats intensity. Because it keeps the team strong enough to show up tomorrow."

That is the heart of Monika’s post. A team that can keep showing up with clarity and energy wins in the long run, even if another team occasionally looks faster.

In knowledge work, the "distance" is not miles. It is output you can count, quality you can defend, and habits that keep decision-making sharp.

Why consistency is a performance advantage (not a vibe)

Monika pointed out something many leaders feel but rarely name: "The brain hates unpredictability." When the workload swings wildly, your body and mind treat it like risk.

Here is what that looks like in a tech organization:

Teams stop planning because plans do not hold.
People start multitasking because priorities change daily.
Individuals shift into survival mode: react, patch, appease, repeat.
Quality slips because speed becomes the only visible metric.

The cost is not just burnout. It is degraded judgment. Predictability, even at a lower speed, gives people enough safety to think: to make trade-offs, to question assumptions, to simplify designs, to prevent incidents instead of celebrating recoveries.

The tech-team trap: "good week" scope creep

Monika described the pattern perfectly. A good week arrives and we treat it like a surplus we must spend immediately:

Add 20% more scope
Say yes to extra meetings
Open new Slack channels
Start a new initiative because momentum feels free

It feels productive in the moment, but as she wrote, it is "debt, borrowed from next week. With interest." The interest shows up as context switching, missed code reviews, longer cycle times, regression bugs, and the quiet dread of an always-growing backlog.

A useful mental model: when you "pull" work forward because you can, you are often stealing capacity from the things that keep the system healthy:

Design and architecture thinking
Testing and reliability
Documentation
Onboarding and mentoring
Recovery time (which is not laziness, it is sustainability)

What a Twenty-Mile March looks like in product development

If you want to apply Monika’s advice, you need two numbers:

a minimum you will hit even on bad days
a maximum you will not exceed even on good days

That second number is the one most teams avoid, because it feels like leaving performance on the table. But it is exactly what protects quality and morale.

1) Define the daily (or weekly) output that always counts

Monika’s first step is deceptively hard: "define the daily output that always counts." The goal is not to create a new vanity metric. It is to define what "progress" means in a way the team trusts.

Examples that tend to work:

PRs merged that meet a definition of done (tests, review, monitoring notes)
Small, releasable slices shipped to production
Story cycle time under an agreed threshold
Escaped defects kept below a threshold
A fixed number of customer tickets resolved with quality notes

Choose something that rewards finishing, not starting.

2) Set a hard limit you do not cross on good days

This is the "good weather, stop anyway" part. Pick one or two non-negotiables:

Maximum number of stories in a sprint
Maximum meeting hours per engineer per week
Maximum concurrent initiatives per squad
Maximum on-call load without compensating recovery

The point is to stop the organizational reflex of turning every calm week into a land grab.

3) End on time (twice this week), even when you could keep going

Monika’s third step is behavioral, not procedural. Leaving on time signals something powerful: "We are not in an emergency." It trains the team to believe the system is stable.

If you are a lead, do it visibly. Do not glamorize late nights. Do not praise "above and beyond" when it is really a broken plan.

4) Cap work in progress: fewer projects, fewer open loops

WIP is where momentum goes to die. A team with too many open loops pays a tax every day in handoffs, reloading context, and re-negotiating priorities.

Simple WIP moves:

Limit each person to one primary item at a time
Limit each team to a small number of active epics
Require an explicit trade when something new enters (what stops?)

5) Protect one focus slot and one recovery slot

This is an underrated pairing. Focus without recovery becomes brittle. Recovery without focus becomes drift.

Try:

A recurring meeting-free block for deep work
A recurring slot for maintenance: refactors, flaky tests, docs, backlog cleanup
A real break after on-call, not a symbolic one

If it is not protected on the calendar, it will be eaten by "quick syncs."

6) Change the language: from "push" to "pace"

Monika suggested swapping "push while we can" for "keep the pace we can repeat." Language sets expectations. If leaders keep saying "just this once," teams learn that limits are negotiable.

Try adopting phrases like:

"What can we sustainably deliver?"
"What are we stopping to start this?"
"Is this a good-weather surge, or a real priority shift?"

A practical 2-week experiment (low drama, high signal)

If you want to test the Twenty-Mile March without a big re-org:

Week 1:

Pick one repeatable output metric (ship frequency, cycle time, or finished stories)
Pick one cap (meeting hours, WIP, or sprint scope)
Add one protected focus block

Week 2:

Keep the same targets even if things go well
Review results in a retro: energy, quality, surprises, and throughput
Adjust the caps, not by guessing, but by what the team can repeat

The success criterion is not "did we go faster." It is "did we stay steady while keeping quality and morale intact."

Closing thought: pace is a strategy

Monika’s post is not anti-ambition. It is pro-endurance. The teams that last are the ones that can make good decisions week after week. And good decisions require a nervous system that is not constantly bracing for impact.

If you take one thing from the Twenty-Mile March, let it be this: create a pace you can keep in both good weather and bad, and treat every tempting surge as a potential loan against the future.

This blog post expands on a viral LinkedIn post by Monika Dainyte. View the original LinkedIn post →