The Two-Week Check-In: How to Tell If a Decision Actually Landed

A meeting can end perfectly. Decisions stated. Owners named. Deadlines on the calendar. Everyone leaves with the same understanding of what's going to happen.

Two weeks later, half of those decisions are in a quieter state than anyone wants to admit. Not failed, exactly. Not actively wrong. Just stalled. The owner got pulled into something else. The context shifted. The deadline came and went and nobody re-litigated it because nobody was tracking it. The decision is still technically live, but operationally it's drifting.

This is the gap between making a decision and the decision actually landing. And it's where most of the value of better meetings either materialises or quietly evaporates.

Read first. The 5-Minute Meeting Close: End Every Meeting with a Decision — the framework for ending meetings cleanly. The check-in is what happens after.

Why Decisions Silently Drift

The drift window is roughly two to four weeks. Inside that window, three things conspire against any decision that isn't actively maintained:

• Context erodes. The reasons a decision made sense in the room get forgotten the moment the calendar invite closes. Two weeks later, the owner is staring at the action item and the surrounding rationale is gone. Without that context, even a perfectly captured decision starts feeling negotiable.
• Ownership softens. Even with a single named decider, the social pressure to follow through fades fast once the room disperses. Nobody is watching. Nobody asks. The decider has six other things on their plate that do have someone watching.
• Reality changes. Some share of decisions stop making sense within two weeks because the world moved. That's fine — decisions should be re-decided when conditions change. The problem is that nobody re-decides them; they just quietly stop being acted on, which is the worst of both worlds.

The result is a class of decision waste that's almost invisible from the outside. The decision was made. It's in the notes. The owner agreed. And yet the work didn't happen, and nobody noticed until somebody else's project got blocked on it three weeks down the line.

A decision you don't check on is a decision you don't actually have.

The Four Outcomes of a Check-In

The whole point of a two-week check-in is to give every live decision exactly one of four labels — and to do it explicitly, on a date, by the person who owns it.

These are the same four outcomes the product itself records. Use them whether or not you ever touch a piece of software:

• Played out. The decision happened the way it was scoped. Archive it. Stop tracking it. Move on.
• Partially landed. Some of it shipped, some of it didn't, the shape of it changed in flight. Worth a one-line note on what actually happened so the institutional memory survives.
• Did not happen. The decision was made, the deadline passed, and nothing moved. The follow-up question is binary: re-decide it now, or accept that it's no longer the plan. Letting it sit is not an option.
• Too early to tell. The decision is in motion but the outcome isn't visible yet. Re-check in another two weeks. Don't conflate this with Did not happen — those have different fixes.

If you can't put a decision in one of these four buckets, the decision wasn't specific enough to begin with — which is itself useful information for the next time that meeting happens.

Played Out

This is the boring outcome, and it's the one you want most often. The owner says "yes, did it, here's the thing" and the decision quietly becomes part of how the team operates now. The check-in itself is the only acknowledgement; no further action required.

The mistake teams make is not closing the loop here. Decisions that played out cleanly should be archived — explicitly marked as done — not left in the registry as ambient noise. An archive of clean wins is one of the best artifacts a team can have, but only if it actually accumulates.

Partially Landed

This is the most common outcome in practice, and the most interesting one to capture. The decision happened, but in a different shape than scoped — a smaller scope, a different owner, a different timeline. The original decision was adapted, not abandoned.

Capture the delta in one sentence. Not a post-mortem; just what actually happened. Six months later, when somebody asks "why did we end up doing it this way?", that one sentence is worth more than the whole original meeting transcript.

Did Not Happen

This is the outcome the ritual exists for. The decision was made. The deadline passed. Nothing moved. The temptation is to either (a) quietly re-set the deadline and pretend, or (b) give up on tracking it. Both are wrong.

The right move is binary, and it has to happen in the check-in conversation itself: either re-decide and re-commit (new deadline, same or new owner, fresh agreement), or formally accept that the original decision is no longer the plan. Marking a decision as did not happen and explicitly archiving it is a much better outcome than leaving it indefinitely live in some shared doc.

Too Early to Tell

Some decisions need more than two weeks to play out. That's fine. The mistake is conflating too early to tell with did not happen — the former needs another check-in window, the latter needs an immediate re-decide.

If you find yourself routinely marking a decision as too early to tell across multiple check-ins, that's a signal: the original deadline was wrong. Reset it explicitly to a date that's actually plausible, instead of letting the same item bounce through three check-ins on the original (broken) timeline.

The Ritual: A Step-by-Step You Can Run This Week

You don't need software to do this. You need a calendar, a list, and a one-line email template. The whole thing fits inside a normal workweek without adding any meetings.

1. At the close of the meeting, every decision gets a check-in date. Two weeks out is a good default; anything inside the natural cadence of the work is fine. Put it on the decider's calendar, not the meeting organiser's. The decider owns the date.
2. At the close of the meeting, put the decision text and its check-in date into one shared place — a doc, a board, an email thread, doesn't matter. The point is that two weeks from now, the decider can find it without searching.
3. On the check-in date, the decider gets one prompt — calendar reminder, an email to themselves, however they remember things — and answers exactly one question: which of the four outcomes is this? Played out / partially landed / did not happen / too early to tell. No essay. No post-mortem. One word.
4. Record the answer in the same shared place as the decision itself. If it's played out, archive it. If it's partially landed, add the one-sentence delta. If it's did not happen, schedule the re-decide conversation right then, while the context is fresh. If it's too early to tell, set the next check-in date.
5. Once a month, scan the list. Anything still open after 30+ days without a recorded outcome is a decision that's silently drifting. Those are the items that need a human to chase, not another reminder.

That's the entire ritual. It takes the decider about 60 seconds per decision per check-in, and it catches the overwhelming majority of decisions that would otherwise quietly die between the meeting and the next quarterly review.

Why two weeks specifically. It's long enough that the work has had a real chance to happen, but short enough that the context — the why of the decision — is still in everyone's head. Wait six weeks and the re-decide conversation becomes a re-meeting from scratch. Two weeks is the window where the cost of catching a stalled decision is at its lowest.

What This Looks Like When the Whole Team Does It

Individual practice is high-leverage but it caps out at the individual. The compounding benefit shows up when every decision across the team gets a check-in — at which point three things happen that don't happen with ad-hoc follow-up:

First, you get an actual distribution of outcomes to look at over time. Played out should be the largest bucket; if it isn't, your team has a decision-quality problem, not a follow-through problem. Did not happen should be small; if it isn't, your scoping or your prioritisation is off. The shape of the distribution is more diagnostic than any individual decision.

Second, you get a searchable record of partial landings. This is where most of the institutional memory of how a team actually operates lives — not in the original decisions, but in how those decisions adapted on contact with reality. A team that captures the deltas can answer "why do we do it this way?" in seconds, not in a half-hour archaeology session.

Third, you get early warning on systemic drift. If a particular kind of decision (cross-team commitments, say, or vendor-dependent timelines) keeps showing up as did not happen, you've found a structural problem worth fixing — not a discipline problem worth lecturing about.

---

The two-week check-in isn't glamorous. It doesn't make meetings shorter or fewer. It just makes sure that the meetings you do run produce decisions that actually land — which is, when you trace it back, the only reason any of those meetings exist in the first place.

If your team is doing this manually, the ritual works fine; the overhead is real but it's bounded. The thing software adds is removing step 3 from human memory entirely: the prompt fires automatically on the check-in date, the answer is one click without a login, and the four-outcome distribution accumulates into a trend you can actually look at. The framework stays human. The reminders don't have to be.