Mandate Drift Inventory

The decision it forces

Which recurring commitments still deserve to exist?

Not which meetings are boring. Sam is specific on the episode that the subtraction is narrower than that:

So the subtraction here is not cancel all your boring meetings. That's kind of, you know, generic advice, hard to apply. Um, it's to eliminate for loop meetings.

A for loop runs a fixed count that was set once and never questioned. A do loop rechecks its exit condition every pass and stops when the goal is met. The inventory is a way of finding out which kind each entry on the calendar is, one row at a time.

So now I can say a do loop knows when it's done. A for loop just knows how to count.

Where the entries came from

Most of them were never assigned. From the episode, on how a commitment ends up on a calendar:

So if you're like me, probably nobody in the org chart sat you down and bestowed upon you this sacred duty. Uh, it just drifted onto your plate, and you kept doing it, and nobody ever noticed that it never really got assigned, right? It's just an expectation now. So all I wrote down in my notes was mandate drift.

That is what the inventory's who_assigned_it column is for, and the honest answer for most rows is the one Sam gives: nobody, it drifted. And the cost is not the big project:

it's not the big project that wears you down, it's the recurring drag of all these obligations, the standard meetings, the weekly reports, the sync that you inherit and that just keeps running forever, um, because somebody had a need one time, and now there's a calendar commitment that sucks time from me and my team.

The two questions

The whole method, as delivered:

Open your calendar and look at your recurring events. For each one, ask two questions. One, what is its exit condition? Two, who checks it? If there is no exit condition or the person who checks it isn't there, you're running a for loop, and it's for somebody else.

Note the or. Either empty column is enough. A commitment with an exit condition nobody checks is a for loop with a comment in it.

The columns

One row per recurring event. The left half is arithmetic; the right half is judgment.

annual_hours stays in hours. The episode puts no figure on what recurring meetings cost and this page does not either; the number on your inventory comes from your calendar and nowhere else. Hours are also harder to argue with than a dollar figure that rests on an assumed loaded rate.

There is no worked example on this page. A filled inventory is one organisation's calendar with the names of the people who never assigned anything, and that is theirs.

The two empty columns

exit_condition and who_checks are the load-bearing fields, and they are almost always empty. That is the finding rather than a gap in the method.

A commitment with no exit condition is not a commitment. It is a habit with a calendar entry. A who_checks that holds a role name rather than a person is a blank, the same rule Name the Human applies to its accountable column: a team cannot notice that a need has ended.

The count at the end is what to report. How many rows, how many hours a year, how many with no exit condition, how many converted to a do loop, how many killed. On the episode the last number was three, one of which was delegated two steps up the org chart, and one came back.

The schema

{
  "schema": "mandate-drift/v0.1",
  "commitments": [
    {
      "name": "what it is called on the calendar",
      "cadence": "weekly | fortnightly | monthly | quarterly",
      "attendees": 0,
      "annual_hours": 0,
      "who_assigned_it": "a person, or: nobody, it drifted",
      "original_need": "what it existed to solve",
      "need_still_live": null,
      "exit_condition": null,
      "who_checks": null,
      "verdict": "unresolved"
    }
  ],
  "totals": {
    "reviewed": 0,
    "annual_hours": 0,
    "no_exit_condition": 0,
    "no_checker": 0,
    "converted": 0,
    "killed": 0
  }
}

Run it with any model

Nothing to install. If the model can read a calendar export it will enumerate the recurring events and do the hours arithmetic; if not, it will ask. Either way it may not touch the right half of the table.

Help me build a Mandate Drift Inventory: one row per recurring commitment on my calendar, so I can see which ones still have a reason to exist.

The rule it tests, from the episode this comes from: for each recurring event, what is its exit condition, and who checks it? If there is no exit condition, or nobody is checking, it is a for loop, running on a count that was set once and never questioned.

MODE
If I give you a calendar export or a pasted list, work in SCAN mode: enumerate every recurring event, and for each one fill name, cadence, attendees, and annual_hours as attendees times duration in hours times occurrences a year. Show the arithmetic for each row. Do not include one-off events.
If I give you nothing, work in INTERVIEW mode: ask me to list my recurring events, three at a time, and fill the same four fields from what I tell you.

FOR EACH ROW, THEN ASK ME, in this order
- who_assigned_it: a named person, or "nobody, it drifted". If I hesitate, record "nobody, it drifted".
- original_need: what it existed to solve, in one line. If I cannot say, record that I could not.
- need_still_live: yes, no, or I do not know.
- exit_condition: what would end it. A date, a milestone, or a state of the world. "When it stops being useful" is not an exit condition; say so once and record whatever I answer.
- who_checks: the person who would notice the exit condition being met. A team name or a role is a blank; tell me so and leave it null.

RULES YOU DO NOT BREAK
1. Never fill need_still_live, exit_condition or who_checks yourself, and never suggest candidates for them. Empty is the finding.
2. Never set a verdict. Leave every one as "unresolved". I decide what to keep, convert or kill.
3. Do not tell me a meeting sounds important or unimportant. You do not know, and the name on the calendar is not evidence.
4. Do not ask for attendee names. A count is enough.
5. If I answer with a dollar figure for a row, record hours instead and tell me why: hours are observed, dollars rest on an assumed rate.

OUTPUT
Valid JSON matching the schema mandate-drift/v0.1 as published at https://sigsub.show/takeaways/mandate-drift/, with totals for rows reviewed, annual hours, rows with no exit condition, rows with no checker, and zeros for converted and killed. Then the same as a table sorted by annual_hours descending, with the two human columns left visibly empty where they are empty. Then the shortest list you can of the rows I should look at first, ordered by annual hours among those with no exit condition, and say why each one is on it.

What a machine may never do

It may read the calendar, count attendees, and multiply. The annual hours number is the one nobody has, and it is the part of this page that a script does better than a person.

It may never fill need_still_live, exit_condition or who_checks, and it may never propose a verdict. Those are the columns that make the inventory mean something, and a model can fill them plausibly for every row, which is precisely the problem.

The part that's not optional

Recheck it at the end of the quarter, which is what the episode actually describes doing:

I'm not lazy. Uh, it's just, it's way too easy to optimize for the wrong loop type, right? So I stop, I remove or convert, and I do this as a regular practice, which is true.

Then, for any row with a verdict of kill, do it without announcing it, and see what breaks. On the episode nobody said anything. That silence is the last column, and only a calendar with an entry removed from it can fill it in.