Tech Productivity

How I Run a Weekly Review That Actually Changes What I Do Monday Morning

Three failed versions of a weekly review before landing on one that survives a busy Friday afternoon and actually changes what gets worked on the following week.

By Aissam Ait Ahmed Tech Productivity 0 comments

Three separate attempts at a weekly review died the same way: they felt productive on the Friday afternoon they happened, and by Monday morning nothing about the actual work had changed. The review became an exercise in reflection with no mechanism connecting it to what actually got worked on next, which is a genuinely common failure mode and not an argument against weekly reviews generally — it's an argument against the specific shape those first three versions had.

Version one: too long to survive a busy week

The first version, borrowed close to verbatim from a popular productivity framework, took ninety minutes when done properly — reviewing every project, every someday/maybe list item, every area of responsibility, in full. It worked exactly twice. On the third week, a genuinely busy Friday made ninety minutes feel impossible to justify, the review got skipped "just this once," and by the fifth week skipping had quietly become the default. A process that only works when the week has been calm is a process that fails precisely when it's needed most — a chaotic week is exactly when a review would help reorient, and exactly when a ninety-minute version gets abandoned first.

Version two: fast, but too vague to act on

The second attempt reacted directly to the first's failure by cutting it down to fifteen minutes: skim the task list, note what feels important, move on. This survived longer — several months — and it stopped producing anything genuinely useful somewhere around week six, when it became clear the fifteen-minute version was really just re-reading the same task list every week without asking any question sharp enough to actually change what was on it. "What feels important" is vague enough that the honest answer most weeks was "whatever I was already planning to do," which meant the review had become a ritual with no real decision-making inside it — present, but not doing anything.

What version three actually asks

The version that stuck is closer to twenty-five minutes, and the difference isn't really the time — it's that every step ends in a specific, written decision, not just a feeling or an impression. Four questions, in this order:

  1. What actually shipped or finished this week? Not what I worked on — what's genuinely done. This forces an honest look at real completion versus busy motion, and it's often the most clarifying question of the four on a week that felt productive but produced surprisingly little that's actually finished.
  2. What's still open that I said would be done by now? Every slipped item gets one of exactly two outcomes: a new specific date, or a deliberate decision to drop it. No item is allowed to just sit unaddressed carrying an old, already-missed date — that's the single change that made the biggest difference over the earlier versions.
  3. What's the one thing that would make next week meaningfully better if it got done? Not a list — one thing, forced to a single answer even when several things compete for it, which is deliberately uncomfortable and exactly the point.
  4. What did I avoid this week, and why? The most useful question of the four, consistently. The honest answer is almost always either "it's unpleasant" or "I don't actually know how to start it," and naming which one it is changes what happens next in a way vague avoidance never gets addressed by itself.

Why the fourth question does the most work

Avoidance rarely announces itself directly — a task doesn't get consciously marked "I'm avoiding this," it just quietly doesn't get scheduled, week after week, while other things take its place without any explicit decision being made either way. Naming it directly, once a week, on a fixed schedule, is what actually surfaces it. A specific recent example: a needed but awkward conversation with a client about scope creep sat unaddressed for three consecutive weekly reviews before finally getting named honestly as "avoided because I don't know how to raise it without sounding confrontational" — a completely different, more specific problem than "haven't gotten to it yet," and one that's actually solvable once it's named precisely rather than left as vague background guilt.

The part that makes it survive a busy week: a fixed, small template

The actual document is short enough to fill in from a phone during a commute if Friday afternoon genuinely doesn't have twenty-five free minutes — a fixed template rather than a blank page every time removes the excuse that "I don't have time to figure out what to write" from ever being a reason to skip it:

  • Shipped: [one or two lines]
  • Slipped, new date or dropped: [item → decision]
  • The one thing for next week: [single line]
  • Avoided, and why: [one line, honest]

Filling this in takes under ten minutes most weeks, closer to twenty on a week with more slipped items than usual needing individual decisions. The template itself — not the underlying questions — is what makes the twenty-five-minute version survive weeks the ninety-minute version never would have.

The mechanism that actually connects it to Monday morning

The genuinely load-bearing change wasn't any single question — it was a rule that the "one thing for next week" answer gets written directly into Monday's calendar as the literal first work block of the day, before checking email or Slack, before anything else has a chance to quietly displace it. Without this explicit step, the earlier versions' insights evaporated by Monday because nothing forced them into the actual schedule; naming a priority on Friday and hoping it survives an unstructured Monday morning is optimistic in a way that consistently didn't hold up in practice.

What a real month of this looked like

Over four consecutive weeks: the "one thing" was completed as the actual first work block on three of them. On the fourth, a genuine production incident took priority instead — which is a legitimate, not a failure, since the review's job is setting intent, not guaranteeing an uninterrupted week. What mattered was that the incident didn't quietly bump the priority item into permanent limbo the way it would have under version two — it showed up explicitly in the next Friday's "slipped" section, got a new date, and got done the following Monday instead.

What didn't survive from the earlier versions, on purpose

  • Reviewing every individual project and area exhaustively — the four-question version trusts that anything genuinely important will surface through "shipped," "slipped," or "avoided" without needing a separate exhaustive audit of every active project every single week.
  • A long someday/maybe list review — dropped entirely; if something on that list is actually still relevant, it tends to resurface on its own without needing a dedicated recurring check.
  • Vague reflection prompts like "how did this week go" — replaced with the four specific questions above, each one ending in a written decision rather than an impression.

If your weekly review is feeding into a broader task system rather than standing alone, this pairs directly with the task system I actually stuck with as a solo developer, and if avoidance keeps surfacing around the same category of task — meetings, specifically — async communication habits that cut our meeting load in half is worth reading alongside this, since it addresses a common root cause from a different angle.

What happens on a week with genuinely nothing notable to report

A fair question about any weekly ritual: what happens on the inevitable quiet week where nothing shipped, nothing slipped, and nothing was especially avoided? The honest answer is that these weeks are rarer than they feel in the moment — the "shipped" question in particular tends to surface small, easy-to-overlook completions that wouldn't have registered as accomplishments without being explicitly asked for, a bug fix that took twenty minutes, a decision finally made after sitting unresolved for a few days. On the genuinely rare week where all four questions come up close to empty, that's itself useful information worth writing down honestly rather than padding out with something that didn't really happen — a string of empty reviews is a legitimate signal worth noticing on its own, not a sign the process itself has failed.

Why Friday afternoon specifically, and what happens when it moves

The timing matters more than it might seem. Friday afternoon sits close enough to the end of the work week that "shipped" and "slipped" are both still fresh and easy to recall accurately, and far enough from Monday that the "one thing for next week" answer has a full weekend to settle rather than being decided in the rush of Monday morning itself, when the temptation to just default to whatever's already sitting at the top of an inbox is strongest. Testing a Monday-morning version of the same four questions for a few weeks, out of curiosity, produced noticeably vaguer answers to the "avoided" question specifically — a Friday looking back has more honest emotional distance from an avoided task than a Monday about to dive straight back into the same pressures that caused the avoidance in the first place.

A month where the system nearly broke, and what held it together

Six months in, a genuinely brutal stretch of back-to-back deadlines made even the twenty-five-minute version feel like too much to justify for three consecutive Fridays. Rather than let it lapse entirely — which is exactly how the first version quietly died — a deliberately reduced emergency form kicked in: just the "one thing for next week" question, answered in under two minutes, nothing else. Imperfect, and enough to keep the Monday-morning mechanism intact through the rough stretch, which mattered more than maintaining the full four-question version at that particular moment. Having a named, deliberately smaller fallback version ready in advance — rather than improvising one under pressure or simply skipping entirely — turned out to be what kept this version alive past the point where the first two attempts had already failed under similar pressure.

Comments

Join the conversation on this article.

Comments are rendered server-side so the discussion stays visible to readers without relying on a separate widget or client-side app.

No comments yet.

Be the first visitor to add a thoughtful comment on this article.

Leave a comment

Share a useful thought, question, or response.

Be constructive, stay on topic, and avoid posting personal or sensitive information.

Back to Blog More in Tech Productivity Free Resources Explore Tools