What Was, What Is, What Will Be

I have worked with a lot of teams over the years, in a lot of seats. Developers reporting to managers, managers reporting to leadership, leadership reporting to the board, the board answering to funders, and all of it answering to the users and customers who actually have to live with the product. Lately, AI agents reporting to me. The problem that shows up in every one of those relationships is the same problem, and it is not about the code. It is that we speak about the past, the present and the future in one flat tense, what was, what is and what will be all sounding the same, and leave the listener to guess which is which.

A developer says "it's done" meaning "it's merged," and the user finds out otherwise. An agent tells me the gate is red because it was red when the agent last looked, hours ago. A founder sells what the product will be as if it already is. A funder hears that plan and books it as a result. Each speaker believes they told the truth. Each listener walks away holding an expectation that the world will not honor.

When that happens enough, trust goes, however good the underlying work is. I have come to treat an unclear past, present and future as grounds for bankruptcy on a collaboration. The fix is a discipline rather than a tool: say which tense you are in, say when you saw it, say how you know it and how far from now it sits, and if you are describing the future, say what has to happen for it to arrive. Then carry only the past and future snapshots that bear on the decision at hand. It turns out this is the second O in observe, orient, decide, act: orientation, written down with its time. The principle is written up properly at Status Carries Three Tenses. This is the story behind it.

For over a decade I have been fighting this with my warm-blooded teammates, and for more than a year now with the ones that run on electricity and never need lunch. Every time, I chose the more imminent battle instead. Until this morning, when the thing that finally tipped it was embarrassingly small.

Last night, around a quarter past eleven, I answered a question for one of my AI seats. Yes or no, done. This morning the same seat asked me the same question again. Then it told me the main branch was red. I checked. The branch had gone green at six. It was now nine-thirty.

Nothing the seat said was false. The question had been open at one point. The gate had been red at one point. The seat had simply carried both facts forward without the time attached, and from its side of the table there was no way to tell a memory from an observation. From my side, I had to stop, re-verify everything it had told me, and decide whether to trust the next message at all.

I have had that exact feeling in rooms full of humans. The sales engineer who learns mid-conversation that leadership already promised the feature. The project lead reading a roadmap and not knowing which rows are shipped, which are building, and which are hopes with nice names. The difference this time was that I could do something about it the same day. Before eleven the principle was drafted and ruled. It merged at five past.

It would be convenient to pin this on sales. I can't.

I have been the lead developer, the architect, the sales engineer and the CTO at the same company, sometimes in the same week. I have watched leadership sell a thing that did not exist and then gone back to my desk to backfill it before anyone bought. Some people call that how startups work. One co-founder makes the bold promise, the team figures out how to deliver. Fine. I understand the move.

But I've also made the bold claim myself, because I could see the vision so clearly that the gap between the vision and the current build stopped registering. I have described a Bible translation tool by what it was going to do, to people who reasonably heard what it did. Casting vision is part of the job. You cannot lead a team or raise money without saying where this is going. What gets lost is the discernment in the gray area between the vision and what exists right now, and losing that discernment is the lie, even when every individual sentence was sincere.

My stubborn hope, and it may be naive, is that the opposite can be true. That you can build a long track record of bold promises kept without ever letting the future get delivered in the present tense. I have seen it work. The same product, with the same team, kept its clients and its funders when the tenses were kept straight, and lost them when they were not.

I'm not claiming to have invented anything here. Applying time to a product is as old as the roadmap. I am saying this is what I have watched, across enough teams and enough years to stop treating it as coincidence, and this is what I am writing down. If someone shows me a team that collapses the tenses and keeps its clients, or keeps them straight and still loses the room, I'll come back and revise this.

When I first started dictating this I thought the answer was three states. Past, present, future. Label everything, done.

That would already be a big improvement, but it is not enough, because the past and the future are not single points. A button on a screen can have a dozen past states. A roadmap has a next train, a next release, and the vision. Collapsing all of that into "we had that" or "it's coming" is the same conflation wearing a smaller hat.

What I actually track, on both sides of now, is three independent things. How confident I am in the claim: did I see it myself, or do I just remember it; is it gated, or merely hoped. How close it is to now: this session, or three releases ago; the next train, or the vision. And how much it bears on what we are deciding right now.

Proximity has a catch that the other two do not: now keeps moving. Every distance on that axis is measured from a point that has already slid by the time anyone reads it. The sentence "the gate was green an hour ago" is true when I type it and drifting the moment I hit send; by the time it is read in another timezone, or by an agent that wakes up on the hour, "an hour ago" may be half a day. There is no fixed now to measure from, only the reader's now and the reporter's now, and they are never the same. So proximity is a last-mile rendering, the way a chat app turns a timestamp into "2 min ago" at the moment you look at it, and only then. The thing that gets stored, carried and handed off is the timestamp. The distance gets computed at the reader's now, every time, by whoever or whatever is doing the showing. When a status arrives with the rendering already baked in and the timestamp gone, I treat it with caution, because reverse-engineering "a while ago" back into the date and time a simple stamp would have given me is quite a leap, and usually a wrong one. "Recently" hands the reader a distance with no origin. "Observed 09:41" hands them a point they can measure from wherever, and whenever, they happen to be standing.

Those axes are independent, and that's the part I used to get wrong. A hoped-for feature can be near. A contracted one can be far. "It was green" from a CI badge an hour ago and "it was green" from a colleague's message yesterday are not the same confidence or the same proximity, and both may be irrelevant to the gate I am actually waiting on. The principle lays the axes out in tables; I won't repeat them here. The point is that "soon" and "basically done" are the sound of three axes being flattened into one word.

Relevance is what keeps this from becoming its own flood.

If we have spent two hours tweaking the look of a screen, I don't want two hundred screenshots. I want three frames: now, before this session started, and what shipped last release. Maybe the release before that, if it changed something I still carry in my head. Pixel-by-pixel history is noise. The natural cut points are where the reader's mental model actually lives.

The same goes forward. Carry the next gate, and as many gates beyond it as the current decision reaches. The roadmap past that horizon is a different conversation. And the filter is relevance to the reader's moment and task, never comfort. Dropping a transition because it is embarrassing, or carrying a far-off feature because it is attractive, is exactly the collapse we are trying to prevent.

I want to be careful about three things this could get confused with.

It is not the working modes. Explore, plan, build, validate have their own clock; past, present and future ride inside whichever one you are in.

It is not a version scheme, though semantic versioning is a useful cross-section of it. Where I part ways with semver is the future. Our cycle now is weeks at the slowest, usually days, often hours or minutes, and one day it will be seconds, so I don't want to block progress predicting which feature lands when. Ship when the gate passes, cut the patch when the fix lands, number it afterward.

And it is not a skill. I went back and forth on that during the dictation and landed on principle: a lens applied across skills, methods and the contracts agents write to each other between layers. The data-side twin, readings carry the time they were observed, gets its own page.

It hit me while I was writing the last section. We already solved this, in principle, years ago, and then applied it everywhere. Observe, orient, decide, act. The first O is observation, and we built a whole discipline around it: observe before you claim, stamp what you read. The three tenses are the second O. Orientation is placing what you observed on the timeline relative to where you are standing right now, and that placement goes stale the moment now moves. The seat that told me the gate was red had observed correctly, hours earlier. It had simply never re-oriented. It was deciding and acting off an orientation it had cached the night before, which is the one thing ODD's reading of OODA says you cannot do: orientation is the center of gravity, and it has to be refreshed and written down, not remembered. We lean on that loop at every scale I work at. In our sprint method it is the whole shape of a window: name the one constraint that is actually holding things up (Theory of Constraints, the ToC in the name), run a fixed thirty minutes against it, ask before you start how it will have failed by the end (a premortem), then look again when the timer runs out and re-orient before the next one. Smaller still, it is the orient call an agent makes before it touches anything. And it runs through the operating rhythms in my private kitchens, which I won't drag onto this page. Each is the same move at a different zoom. Was, is, will be, each with its time, is what a written-down orientation looks like.

In April I wrote up time blindness: models have no clock, so they infer elapsed time from context and guess confidently when they guess wrong. We built a clock and put it in the model's hand, and that one fix unlocked more than I expected across the whole system.

This is the human side of that observation. A human with a perfect clock who says "the build is red" without a time has made the same mistake as the model that never had one. The reader still cannot tell whether to act. Time blindness explained how a model loses the clock. This principle says why losing it costs trust no matter who is speaking, and no matter which of the three tenses they lose.

What sinks projects is not the code. It is the inability to deliver on the expectations that were set: delivery in a reasonable time, to meet a real business demand. In ministry the leash is longer and the deadline is softer, but the funding fades just the same, and it is the same story. Threading the needle of time is the fourth dimension of product.

The root of all of it is trust, and trust is nothing more mysterious than expectations managed honestly over time. Honesty, transparency, observability across the product lifecycle. The principle ends with a one-question test for any status; I'll let it keep that. Mine is simpler. If I have to ask "wait, is that still the case?", the work underneath won't save us.

See also: Status Carries Three Tenses — the principle this piece tells the story of. Time Blindness — the model-clock side of the same problem. Every Handoff Drops Context — what happens to tense across session boundaries.