Roland Butcher hit the fastest century of the 1987 English season. 100 runs off 73 balls against Sussex. It won him the Walter Lawrence Trophy.
Here's the part people skip. He'd been playing for Middlesex since 1974. Thirteen seasons before he hit the quickest hundred of the summer. By the end of his county career he'd played 550 matches and scored 16,920 runs, according to his own site.
The fast hundred didn't come from rushing. It came from the long game.
Debra and I had Roland on Corey-osity Unleashed. He made history as the first Black cricketer to represent England, and he has plenty to say about leadership. One of his ideas keeps nagging at me: not all work needs to be fast.
Most engineering teams I see have forgotten this.
Every Task Gets the Same Clock
Look at your sprint board. Bug fix: two weeks. New feature: two weeks. Database migration: chopped into two-week chunks so it fits. Mentoring your next tech lead: somehow also on the board, also in two-week pieces.
Sprints work well for work with a short feedback loop. Ship, learn, adjust. The problem starts when the sprint becomes the only clock in the building.
When every task runs on one clock, the slow work loses. Every time. Nobody sits down and decides to neglect the architecture review or the platform rebuild. It never fits inside two weeks, so it never starts.
Cricket solved this problem a long time ago. It runs two formats. A T20 match lasts about three hours. A Test match runs up to five days. Same sport. Same bat. Same ball. A different game.
A batter who plays a Test innings like a T20 innings gets out cheaply and leaves the team in trouble. A batter who plays T20 like a Test match loses the game by being too careful.
Your team needs both formats. Most leaders only run one.
Signs You're Only Playing T20
Check your own team against this list:
- Every roadmap item has a delivery date inside the current quarter.
- The "tech debt sprint" appears on the plan once a year, then gets cancelled for a customer request.
- Your most senior engineers spend their days closing tickets instead of shaping the design.
- Nobody owns anything with a lifespan longer than a release.
- Retros cover what went wrong this sprint, never what keeps going wrong every sprint.
- "We'll come back to it" has become a team joke.
If three of those sound familiar, your team runs on one clock. The short one.
The Bill for Short-Game Thinking
Stripe's Developer Coefficient survey asked developers where their week goes. The average developer spends 13.5 hours a week on technical debt and another 3.8 hours on bad code, out of a 41.1-hour week.
Run the numbers. Over 40% of every developer's week goes on paying for yesterday's shortcuts.
Those hours don't come from lazy engineers. They come from a thousand decisions made on the short clock. "Ship it now, we'll fix it later." Later never got a sprint.
The pattern shows up at company level too. The McKinsey Global Institute built a Corporate Horizon Index across 615 large and mid-cap US companies. From 2001 to 2014, the long-term firms outperformed the rest:
- Revenue grew 47% more on average
- Earnings grew 36% more
- Economic profit grew 81% more
- By 2014 they'd spent almost 50% more on R&D, and they kept spending through the financial crisis while other firms cut
McKinsey says plainly its data doesn't prove long-termism causes the outperformance. Fair enough. I'll still take those numbers over the alternative. I've never met a team who cut corners for a decade and ended up with a platform they loved.
Speed and Stability Aren't Enemies
Here's where engineers push back. "We have to move fast." Yes, you do. The research agrees with you... and goes further.
DORA, the long-running research programme behind the best-known software delivery metrics, puts it bluntly: "speed and stability are not tradeoffs." Top performers do well across all five of its metrics. Low performers do poorly across all five.
The same guide quotes Dave Farley from Modern Software Engineering: the real trade-off, "over long periods of time, is between better software faster and worse software slower."
Read the Farley line twice. Fast teams are fast because somebody played the long game. Somebody built the deploy pipeline. Somebody wrote the test suite and set up the observability. None of it looked urgent at the time. All of it made everything afterwards quick.
Roland's 73-ball hundred works the same way. Fast on the day. Built over years.
How to Run Two Clocks
Here's what I'd do on Monday morning.
Sort the work by horizon, not by size
Ask one question about each piece of work: when does it pay back? This week, this quarter, or next year?
Size tells you effort. Horizon tells you which clock the work belongs on. A one-line config change to fix a flaky deploy belongs on the long clock, because it pays back for years. A big feature for a customer demo on Friday belongs on the short one.
Protect a long-game budget
Give long-horizon work a fixed slice of your team's capacity. Pick a number your team agrees on. Write it down. Defend it when the quarter-end panic arrives.
If the budget gets raided every time a deadline looms, it never existed. Your team will notice, and they'll stop proposing long-game work at all.
Measure the long game on a long clock
Don't judge a platform rebuild on sprint velocity. Judge it on what it changes six months later: deploy frequency, change failure rate, time to restore service. Velocity charts reward the short game and punish everything else.
Treat your people as long-game work
Growing a junior engineer into a senior one takes years. No sprint captures it. No burndown chart shows it.
Leaders who only reward the short game end up with teams full of people who never grew. Then the same leaders complain about a shortage of senior talent.
Applaud the patient innings
Fast wins get the applause. The release, the demo, the launch. The engineer who spent a quarter making the build reliable gets a thumbs-up emoji, if they're lucky.
Put the long-game work in front of the whole team. Name it in the all-hands. Promote people for it. People repeat whatever you celebrate.
Know Which Match You're In
A good Test batter doesn't panic when the scoreboard moves slowly. They know the match lasts five days. They leave the balls outside off stump, wait for the bad one, and build an innings.
Some of your work deserves the same patience. Your architecture. Your platform. Your people.
Some of it doesn't. Fix the outage now. Ship the small feature. Play the shot.
The skill isn't speed, and it isn't patience. It's knowing which match you're in.
So look at your board this week. Which of those tickets is a Test match pretending to be a T20? And who on your team has been batting through the long innings while you applauded somebody else's sixes?