6 Harnessing the Relentless Movement of Time
This chapter is currently in draft form.
Six months from now, you will be somewhere. The question is whether that somewhere represents progress or stagnation. Time doesn’t wait for permission. It moves, relentlessly, whether you’re ready or not.
The clock doesn’t care about your intentions. It only registers what you actually accomplished.
Most leaders understand this intellectually. Few internalize it. The urgent crowds out the important (Eisenhower, 1954), quarter after quarter, until one day they look up and realize years have passed. Nothing broke catastrophically, so nobody noticed the drift. But drift is its own form of failure—the slow kind that doesn’t trigger alarms until it’s too late to reverse.
This chapter is about refusing that drift through a specific discipline: threading long-term progress into short-term work. The leaders who compound progress aren’t the ones who find room for the important. They’re the ones who make every urgent action serve a longer purpose.
6.1 The Realization
I learned this the hard way. At one organization, we were trapped in what I came to call permanent emergency mode. Everything was urgent. Every request demanded immediate response. We prided ourselves on agility, on never letting anything slip through the cracks.
What we didn’t do was anything big.
Urgency always won the prioritization battle. Big projects required sustained focus, but every week brought a new fire. Long-term improvements kept getting bumped for this quarter’s crisis. We told ourselves we’d get to the important work when things calmed down. In permanent emergency mode, things never calm down—that’s the definition.
After about eighteen months, I had a sobering realization. We hadn’t moved. All that urgency, all that agility—and the organization was in essentially the same place it had been a year and a half earlier. The infrastructure was the same. The technical debt was the same. Our cost of change hadn’t dropped. We had been running hard and going nowhere.
The problem wasn’t that we were doing small projects. Small projects are fine. The problem was that our small projects weren’t connected to anything larger. Each one solved its immediate problem and contributed nothing to our strategic position. We were efficient at tactics and absent at strategy. And the constant pivoting was destroying something I didn’t have words for yet—the physics of organizational velocity that The Conservation of Momentum will make explicit.
The breakthrough came when I started asking a different question. Instead of “What’s the fastest way to solve this immediate problem?” I started asking “What’s the fastest way to solve this immediate problem that also moves us toward where we need to be in a year?”
The answers were rarely the same. The fastest tactical solution often cemented existing patterns. The solution that served both horizons took longer—sometimes significantly longer—but it moved the needle twice.
We started weaving infrastructure improvements into feature work. A ticket to add a new capability became an opportunity to modernize the subsystem that capability touched. A bug fix became a chance to add the observability we’d been lacking. Each project took longer than the pure tactical version would have. But each project left us somewhere better.
After another eighteen months, the difference was stark. We hadn’t paused for a grand rewrite or a strategic offsite. We hadn’t found mythical “room for strategy.” We’d simply threaded strategy into tactics, consistently, project by project. The cumulative effect was transformational in a way that no single initiative could have been.
6.2 The Two Horizons
The job requires holding two realities at once (O’Reilly and Tushman, 2004). The now: delivery pressures, stakeholder demands, production incidents, the tactical grind of keeping the lights on and shipping what was promised. The next: where the organization needs to be in six months, what capabilities you’re building, what architectural direction you’re establishing.
Think of it like driving. You need one eye on the road directly in front of you and one eye on the horizon. Focus exclusively on the road in front and you’ll navigate the next hundred feet perfectly while driving off a cliff. Focus exclusively on the horizon and you’ll crash into the car ahead.
Most leaders are better at one than the other. Operators excel at the now—brilliant tacticians, utterly reliable for delivery—but their strategy collapses into roadmaps: lists of projects with no coherent direction. Visionaries excel at the next—they see the destination with crystalline clarity—but their delivery collapses into theater: offsites and decks that never connect to today’s work. They burn through political capital on vision while starving for the credibility that only visible delivery provides. This is The Blub Paradox applied to time horizons: operators can’t perceive the value of strategic thinking because they’ve never experienced its payoff; visionaries can’t perceive the value of tactical excellence because they’ve never needed to deliver.
The job is both. Not alternating between them. Both, simultaneously, all the time.
The discipline is refusing to let the horizons disconnect. Every tactical decision is also a strategic decision. The question isn’t “Should I do tactics or strategy?” The question is “How does this tactical action serve my strategic direction?”
The simplest version: What’s the immediate win, and what’s the lasting improvement? If you can’t answer both, something is wrong with the work.
If the answer to the second is “there isn’t one,” you’re solving the wrong problem or solving it the wrong way.
6.3 The Fallacy of Rewrites
What does it look like when leaders abandon one horizon entirely? The most common example is the rewrite.
Nothing tempts engineers like starting over (Brooks, 1995). The existing system is a mess—accreted complexity, outdated patterns, the sedimentary layers of a dozen different eras and a hundred different developers. Surely it would be faster to start over. Surely a clean slate would let us do it right this time.
This reasoning is almost always wrong. I’ve walked into multiple organizations running three versions of the same system simultaneously in production—v1, v2, and v3, each representing a rewrite that never quite finished, each still handling some traffic because the replacement never fully replaced. This is what happens when you abandon the present for a future that keeps receding.
A rewrite is the ultimate failure to hold both horizons. You sacrifice the now entirely, betting that eighteen months of zero delivery will pay off when the new system arrives. But the new system is late. It always is. Meanwhile, the old system still needs maintenance, splitting the team’s attention. Priorities shift. The rewrite gets deprioritized, then frozen, then quietly abandoned—except it can’t be fully abandoned because half the organization’s institutional knowledge is now embedded in a codebase that will never ship. So you maintain two systems, or three, forever.
When your engineering leader proposes a major rewrite, be skeptical. Ask: What’s the incremental alternative? What if we improved the existing system piece by piece, while continuing to deliver value, instead of betting on a single large delivery?
If they dismiss incrementalism as too slow, probe further. How long will the rewrite take? (Add 50% to whatever they say.) What happens to the existing system during that time? What happens if priorities shift before the rewrite is complete?
The best engineering leaders almost never propose rewrites. They’ve learned, usually through painful experience, that the gardener’s path is both more reliable and ultimately faster. If your leader is excited about starting over, they may not have that experience yet.
6.4 The Gardener’s Approach
The alternative to rewrites is the gardener’s approach (Ohno, 1988). A gardener doesn’t rip out the entire garden because some plants are struggling. They tend what exists. They improve incrementally. They leave the garden better each day than they found it, through small consistent actions that compound over seasons into transformation.
Applied to software, this is aggressive incrementalism. You never rewrite; you improve. Every time you touch a subsystem, you leave it slightly better. Modernize one pattern. Extract one abstraction. Add one missing test. No single change is dramatic. The accumulation is. Over time, like Theseus’s ship, every piece gets replaced—but the ship remains seaworthy throughout.
The rewrite abandons the present for a future that never arrives. The gardener threads improvement into every touch, and the future arrives without anyone noticing the transition.
6.5 Threading Strategy Through Tactics
Holding both horizons is necessary but not sufficient. You also have to connect them. Today’s work has to advance tomorrow’s position. This is the core discipline: threading (Mintzberg and Waters, 1985).
Threading starts with knowing where you’re going. If you don’t have a clear picture of the six-month target, you can’t thread toward it. Strategy work earns its keep here—not as an abstract exercise but as the prerequisite for intelligent tactical decisions.
Here’s what threading looks like in practice.
At one company, we had a legacy surface written in a language so deprecated that finding developers who could maintain it was becoming impossible. The obvious solution was a rewrite—carve out two months, replace the whole thing, be done with it. Before I arrived, the team had attempted this rewrite four times. Each attempt ran into unforeseen complexity, got deprioritized when something urgent hit, and quietly died. Two years of “two-month rewrites” and the legacy surface was still running.
We stopped trying to replace it whole. Instead, we started thinning it. Every time a feature touched that surface, we moved a piece of it into the modern stack. No dedicated rewrite project. Just a standing rule: if you touch it, you shrink it. Eight months later, we turned it off with a quiet commit that deleted the last remaining integration. The legacy surface shrank as a side effect of work we were doing anyway.
That’s threading at the architectural level. The same principle applies everywhere:
Feature work threads infrastructure. A request to add payment processing becomes an opportunity to introduce the API versioning you’ve been planning. You’re building the feature anyway—threading adds the versioning layer that makes future payment changes safer. Two purposes, one project.
Bug fixes thread observability. A production incident requires a fix. Instead of just stopping the bleeding, you add the monitoring that would have caught this class of failure earlier. The fix ships, and your alerting coverage expands.
Performance work threads scalability. A page is slow and needs optimization. Instead of a point fix, you introduce the caching layer that prepares you for the traffic growth you’re planning for. The immediate problem gets solved, and your architecture advances.
The gate is simple: What’s the immediate win, and what’s the lasting improvement? No work starts without answering both. If you can’t answer the second question, the work either needs reframing or shouldn’t be prioritized yet.
Threading doesn’t fail the way rewrites fail. A rewrite fails dramatically—the project gets cancelled, everyone remembers the boondoggle. Threading fails quietly. You lose stamina. The improvement slows down, then stops, and nobody notices because there was never a project to cancel. You just end up with things half-migrated, and that becomes the new normal. The only defense is discipline: making the threading habitual enough that it survives the inevitable dips in attention.
Sometimes the honest answer is that a piece of work is purely tactical—it solves an immediate problem but doesn’t advance you anywhere. That’s acceptable occasionally. It’s a danger sign if it’s the pattern. Look at the past quarter’s work. How much of it moved you toward your six-month goals? If the answer is “little to none,” you have a threading problem. Time is passing and you’re not progressing.
6.6 Time as Ally
Time isn’t the enemy. It’s the medium.
Every project can leave the codebase more capable. Every quarter can accumulate improvements that compound into transformation. Time works for you when you use it deliberately. It works against you only when you let it pass unused.
This is what the gardener knows. No single day of tending produces visible change. But a year of daily attention transforms a vacant lot into a flourishing garden. The transformation happens through time, not despite it.
Six months from now, you will be somewhere. The leaders who end up somewhere better aren’t the ones who found room for strategy. They’re the ones who refused to let tactics and strategy disconnect. They thread—relentlessly, habitually, until it stops being a technique and becomes simply how they lead.
Ask your CTO to show you how this quarter’s delivery connects to the six-month strategic position. Not in abstract terms, but concretely: which projects advance which strategic goals, and how.
If they can’t answer clearly, you have a disconnection problem. But before assuming it’s a leadership gap, examine the system. Quarterly delivery pressure, stakeholder demands for visible features, and metrics that reward output over improvement all make threading harder. The best leaders can thread despite these forces—but the forces are real.
The answer you want to hear is specific. “This feature work is also modernizing our payment infrastructure, which positions us for the European expansion.” “This bug fix is part of our reliability initiative, which is why we’re adding monitoring at the same time.” Every project, two purposes.
One note on cost: threading takes slightly longer per task. This is paying technical interest instead of accruing technical debt—a bit more upfront so the future is cheaper. If your leaders can’t articulate that tradeoff, they may be optimizing for the wrong horizon.
If instead you hear that strategy will be addressed later, when there’s time, when things calm down—there will never be time. Things will never calm down. The threading has to happen now, in the work you’re already doing, or it won’t happen at all.
Work that doesn’t thread doesn’t start.