Think Like a Time Lord and Stop Watching the Clock

September 30

A day without drama: Tuesday’s GREAT-2C session completed in 2 hours and 7 minutes with zero major issues, two sophisticated spatial architectures verified operational, a security vulnerability fixed, and comprehensive documentation created. Both PM and Lead Developer independently assessed satisfaction at 9/10 in our end-of-session ritual.

The smoothness felt almost suspicious. Where was the struggle? The discovery of hidden complexity? The midnight debugging session?

The answer lies in something we haven’t talked about publicly yet: we stopped measuring time in ways that distort priorities.

The tyranny of consensus time

Around September 29th, while reviewing gameplans and agent prompts, I noticed a pattern. Time estimates everywhere:

“Phase -1: 30 minutes”
“Router completion: 2 hours”
“Testing and validation: 1 hour”
“Must complete in X timeframe”

These weren’t planning aids. They were psychological constraints creating pressure where none should exist. An agent working on infrastructure would see “30 minutes max” and internalize that speed matters more than completeness. The 80% pattern we’d been fighting wasn’t just about verification — it was about optimization pressure from arbitrary time boxes.

Time estimates in development serve two masters badly:

As predictions: They’re usually wrong, teaching us nothing useful
As constraints: They pressure shortcuts, degrading quality

The solution wasn’t better estimates. It was recognizing that for foundational infrastructure work, Newtonian time is the wrong measure entirely.

Becoming a Time Lord

Here’s what I told the team:

I am a Time Lord and I can define time at will. If we must speak about time we should use my bespoke units:

Small efforts take a number of mangos
Medium efforts take a number of hurons
A person may get one diga worth of work done in a day (but it depends)
A team might spend a whole whale on a big project

I went on explaining my nonsense system:

There are 87 mangos in a huron, 43 hurons in a diga, 11 digas in a whale, 5–6 whales in a mole, and 8 moles in a yak.

If we must speak about time or estimates, it is purely as part of an empirical process of comparing guesses to actual. None of it matters and any references to objective Newtonian time risk distorting our priorities.

The units are deliberately absurd. You can’t feel deadline pressure about completing something in “5 mangos” because mangos aren’t connected to your calendar or your sense of running out of daylight. The conversion factors (87 mangos in a huron) make arithmetic tedious enough that you stop trying to calculate.

This isn’t whimsy for whimsy’s sake. It’s breaking the psychological connection between “time passing” and “must finish faster.”

Gambling with Quatloos

The philosophy extends beyond units. It’s about what estimates actually teach us:

Old way: “This should take 2 hours” → Work takes 4 hours → “We’re behind schedule” → Cut corners to catch up

Time Lord way: “I wager six quatloos this takes five hurons” → Work takes eight hurons → “Interesting! We learned something about scope”

OK, I am mixing my cheesy 60s science fiction references, but stay with me on this.

Estimates become empirical learning, not constraints. The difference between predicted and actual teaches us about our understanding of the work, not our failure to work fast enough.

When the Chief Architect creates a gameplan now, we prefer to use effort estimates insteasd of time (small, medium, large effort predicted vs. actual), but if time language crops up I keep insisting we use my bespoke units. Not to hide real timelines, but to prevent time-thinking from contaminating quality-thinking.

Plus we have timestamps all over our chat transcripts to keep the logs straight, which probably also contributes to the time obsession deeply training into the semantics of business software development.

What happens when you stop watching the clock

Tuesday’s session working on CORE-GREAT-2C (the third sub-epic in the second epic of the Great Refactor super epic on my Core Functionality track), demonstrated this philosophy in practice.

Phase 0: Investigation without pressure (20 mangos)

Code and Cursor agents spent time properly verifying infrastructure. Not “30 minutes max” but “until we understand the actual state.” They discovered:

21 spatial files across the codebase
TBD-SECURITY-02 vulnerability precisely located
Two different architectural patterns (Slack’s 11-file granular system vs Notion’s 1-file embedded intelligence)

No one rushed. The investigation took what it took.

Phase 1–2: Verification without shortcuts (30 mangos each)

Testing Slack’s spatial system revealed minor test infrastructure issues. Instead of deeming them “non-blocking” and moving on (the 80% pattern), Cursor distinguished clearly: “The core system works perfectly, here are 4 minor test-related items.”

This precision came from having space to think, not pressure to finish.

Testing Notion revealed a completely different architectural pattern — embedded spatial intelligence rather than adapter-based. This discovery happened because agents had permission to investigate thoroughly rather than confirm assumptions quickly.

Phase 3: Security fix without fear (17 mangos)

TBD-SECURITY-02 took 17 minutes to fix because:

Phase 0 had located it precisely
Phases 1–2 verified spatial systems worked
No time pressure made agents skip verification steps

Code uncommented 4 lines. Both agents verified spatial system compatibility. Security enabled with zero regressions. Done right because there was time to do it right.

Phase Z: The acceptance criteria discovery

Here’s where Time Lord philosophy really paid off. During the Phase Z bookending checklist, we reviewed acceptance criteria against completed work and found a discrepancy:

One criterion required “Integration tests passing for both modes.” But the work had focused on functional verification, not test suite execution. When Cursor noted test infrastructure issues, the initial instinct was “non-blocking, the systems work.”

Because there was no time pressure to declare victory and move on, we investigated. Code found and fixed a simple import error:

# Wrong
from services.database.async_session_factory import AsyncSessionFactory
# Right  
from services.database.session_factory import AsyncSessionFactory

Result: 547 integration tests now collectible, 40/40 executable tests passing.

This “gnat-sized chaos” would have been missed in a rush to completion. Time Lord philosophy created space to actually check acceptance criteria against deliverables rather than assume they matched.

In retrospect

Tuesday’s satisfaction ratings (9/10 from both PM and Lead Dev) reflected something deeper than technical success. They reflected the satisfaction of working well.

PM’s assessment: “Craft quality and harness resilience. Worried we missed something but the careful work is driving quality.”

Lead Dev’s assessment: “Inchworm Protocol prevented assumptions. Multi-agent coordination provided binocular vision. Systematic questioning revealed deep insights.”

Both recognized the same thing: the methodology worked because it had space to work. No artificial time constraints forced shortcuts. No deadline pressure encouraged “good enough for now.”

The work took 2 hours and 7 minutes. It also took so many mangos for Phase 0, and so on. The Newtonian time happened. The Time Lord units kept us focused on quality.

The vindication

GREAT-2C vindicated multiple recent methodology innovations:

Inchworm Protocol: Investigation phases prevented assumption-driven work
Cathedral Doctrine: Agent coordination around shared goals caught issues collaboratively
Anti-80% Safeguards: Preventively eliminated completion bias
Time Lord Philosophy: Quality completion without time pressure

But the Time Lord philosophy enabled the others. The Inchworm Protocol works when you have permission to investigate thoroughly. Cathedral Doctrine requires space for collaborative verification. Anti-80% safeguards need time to enumerate every method.

Remove time pressure and you create space for systematic quality.

Could anyone else use bespoke time units?

Not every project is a hobby with the luxury of taking all the time needed to get things right, but every project suffers if corners get cut to achieve arbitrary deadlines. You may no be able to introduce jabberwockian languge to your human collaborators or convince them that you control space and time, but if it’s just you and a bunch of bots, they pretty much have to take your word for it.

Also, not every task benefits from Time Lord thinking. Customer support tickets need response time commitments. Marketing campaigns have real launch dates. User-facing bugs deserve urgency.

But foundational infrastructure work? The stuff everything else depends on? That work deserves freedom from the clock.

If you’re in my boat, you could use bespoke units when:

Quality compounds: Today’s shortcuts become tomorrow’s technical debt
Discovery matters: Unknown complexity might emerge during work
Verification is critical: Systematic checking prevents costly errors later
Learning happens: The work teaches you about the domain

And still use Newtonian time when:

External deadlines exist (launch dates, commitments)
Time-sensitivity matters (security patches, user-facing bugs)
Scope is truly fixed (well-understood maintenance work)

The key insight: not all work should be measured the same way.

The paradox

Here’s the beautiful irony: GREAT-2C completed in 2 hours and 7 minutes. If we’d time-boxed it to 2 hours, we might have finished in 2 hours. But we would have:

Skipped the dependency fix (gnat-sized chaos unresolved)
Missed the acceptance criteria gap
Left 507 tests uncollectable
Claimed completion without verification

We finished faster by not trying to finish fast. The work took exactly as long as it needed to be done right, which turned out to be less time than cutting corners would have required plus later fixes.

Time pressure makes work take longer when you account for the full cycle: initial implementation + bug fixes + technical debt resolution + “why doesn’t this work?” debugging sessions. Time Lord philosophy frontloads the quality, eliminating most of the cycle.

What’s a mango worth?

I still don’t know how long a mango takes in minutes. That’s the point. When Code says “this will take about 5 mangos,” both of us understand:

It’s a small effort
The estimate might be wrong
Learning from the difference is valuable
The work takes what it takes

And when it actually takes 8 mangos? We learned something about the work. Nobody failed. Nobody needs to catch up. We adjust our understanding and continue.

The conversion factors (87 mangos in a huron) aren’t for calculation. They’re to make calculation annoying enough that you stop trying. Because the number doesn’t matter. Only the quality does.

Building in public

This Time Lord philosophy might seem strange to teams with deadlines, stakeholders, and quarterly planning. How do you coordinate without shared time metrics?

The answer: coordination and completion are different from constraint and pressure. We still know what needs doing. We still have priorities. We still ship work. We just don’t let arbitrary time boxes degrade the quality of foundational infrastructure.

And when you’re building in public, documenting every step, the proof is in the work. Tuesday’s GREAT-2C session verified two sophisticated spatial architectures, fixed a security vulnerability, created comprehensive documentation, and achieved 9/10 satisfaction from both PM and developer.

That’s what happens when you stop watching the clock.