Time Management Without Scheduling — Editions, Feasibility, and the Fleet
Status: Idea (2026-07-28). Not approved, not scheduled, nothing built. Captured so the reasoning isn't lost. Purpose: Record how VERA could become proactive about time without becoming a project-management tool — and why the obvious approach (measuring progress against a linear plan) is wrong for a large class of real agencies.
Note on audience: this file is published at getvera.site along with the rest of
docs/. Written accordingly.
1. The problem
Agencies are told to run a bookend ritual — a short check-in when people arrive and another before they leave. Almost nobody does it. It requires two calendar events a day and a person willing to chair them.
VERA's current substitute is a Slack morning summary. It works, but it is ephemeral: it scrolls away, it carries no history, and there is no way to go back and establish that VERA said something needed attention two weeks before it became a problem.
The opportunity: a permanent, readable artifact that does the ritual's job asynchronously.
2. The reframe — this is yield management, not project management
VERA does not care about atomic tasks, due dates, or dependencies. It cares whether people deliver their hours and whether that work fits inside the business safely.
The right analogy is a haulage company:
A truck holds 100 boxes. It leaves A at the same time every day, full or empty, and arrives at B. You are selling roughly 260 truckloads a year. The goal is to get as close to 100 boxes on every truck as possible.
The defining property is that capacity is perishable. An hour nobody sold yesterday cannot be sold today. That is the entire economics of a time-based business, and it is a different problem from tracking whether a task finished.
Every hour of capacity sits in exactly one of four states:
| State | Meaning |
|---|---|
| Shipped | Logged time. Exact, backward-looking. |
| Booked, not shipped | Committed to an allocation envelope but not yet consumed. |
| Unsold | No commitment against it. Perishes daily. |
| Overbooked | Commitment beyond capacity. Something will spill. |
Every signal worth publishing is a statement about a transition between those four states.
3. Why measuring against a linear plan is wrong
The intuitive approach is to draw a straight line from kick-off to deadline and report how far actual hours sit from it. VERA already does this in places — the burn-up guideline, off-course alerts, projected-exhaustion dates.
It breaks badly for burst-shaped work, and burst-shaped work is normal. A production company front-loads pre-production, spikes into 12–15 hour days around a shoot, drops into a near-silent hangover, then shifts into editing. At almost no point does that project sit near a straight line — and it was never supposed to.
Telling that project manager to "pick up the pace" is not merely unhelpful. Their experience correctly tells them to conserve the remaining envelope for the intense bursts still to come. A constant warning light on a project that is running exactly as intended trains people to ignore all warning lights.
The rule that follows:
Every signal that asks "are you on pace?" assumes a shape nobody agreed to. Every signal that asks "do the commitments still add up?" does not.
A linear plan line is an assumption, not a commitment. Nobody agreed to spend a twelfth of the budget each month — they agreed to deliver by a date, within a budget. Only the second thing is real, so only the second thing may be reported.
Explicitly rejected: phased envelopes, per-period targets, or any mechanism that asks when work will happen. That is scheduling, and it is the thing being avoided.
4. The principle — manage the envelope of possibility, not the plan
Scheduling answers when will this happen. There is a different question with the same forward-looking power and none of the rigidity: what is still possible?
That is answerable from commitments, capacity and deadlines alone, and its answer never assumes a shape.
Instrument 1 — the feasibility frontier
Sort active projects by deadline. Walk forward. At each deadline D:
Σ committed hours for projects due by D ≤ Σ capacity available between now and DIf that fails at any deadline, the situation is impossible — not "behind", not "at risk". No ordering, no bursting, no heroics fix it, because total demand has been compared against total supply over the same interval without saying anything about when either occurs.
This permits bursting entirely. It fires only when the arithmetic has run out — and it fires early, because a breach at a November deadline is visible in July.
Instrument 2 — headroom
Rather than managing time, manage the scalar it reduces to: capacity minus commitment at each horizon. One number per deadline window.
Watching it trend tells the story without anyone being told when to work: "headroom to the September frontier has gone from 400h to 90h in three weeks."
Positive headroom is unsold inventory, which makes this the sell-side instrument too.
Instrument 3 — the last responsible moment
For a project with R remaining committed hours, deadline D, and discipline capacity c:
must-start-by = D − (R / c)This imposes no shape, no phases, no daily targets. It says one thing: "You can defer this until the week of 8 September. After that it cannot fit, however hard anyone works."
For a project in a deliberate lull, this licenses the pause — it reports how much runway the lull has instead of nagging anyone to fill it. VERA stops being a metronome and becomes a fuel gauge.
When the must-start-by date passes with nothing logged, that is worth reporting — because it is now a fact rather than a forecast.
5. The vehicle — a daily edition, not a notification queue
The natural instinct is an inbox of alerts. A daily edition — one page per tenant per day, stored permanently at its own URL — is better:
- Fixed footprint. A slow news day is still one newspaper. An inbox with a rising unread count feels like debt; nobody has ever felt nagged by a paper they chose to read.
- Permanence is native. A URL per day is the archive. No read/unread state, no dedup-and-age machinery, and the "go back two weeks and see what VERA said" property comes for free.
- The tone is right. "215h of a 252h budget is unassigned with three weeks to go" reads as information in an edition and as an accusation in a notification. Identical fact, opposite contract.
- It is a shared artifact. If everyone reads the same edition, that is the bookend — asynchronous, five minutes, no calendar invite.
A useful consequence: because the footprint is fixed, an edition may safely print standing status as well as changes. Newspapers print the weather daily. Changes become headlines; status fills the inside pages. (This is the opposite of the right rule for notifications, where only changes may interrupt.)
Sketch
The fleet — last week 312 of 400 hours shipped. 88 unsold. Fits — every deadline through November is still reachable with current commitments. Tightest point — 12 September. 640h due, 700h available. 60h headroom, down from 310h a month ago. Decide by — Acme Rebrand must start by 8 September to fit its 180 remaining hours. Sitting idle — Hartwell holds 215h booked and shipped 4h in a fortnight. Pressure — Design is oversubscribed next week; Development has 60 free hours. Excluded — 4 active projects have no deadline and aren't counted.
No task is mentioned. No person is named. No day of work is assigned to anyone.
6. Constraints this must respect
Speak in projects and disciplines, never in people. Capacity conflict is inherently per-person, so the naive rendering names whoever is double-booked. Aggregating to the discipline keeps it actionable without singling anyone out: "Design is oversubscribed next week across two projects." Drill-down to individuals stays on the existing, role-gated capacity page. This is a rule a renderer can enforce, not an editorial guideline someone has to remember.
Generation must be deterministic. A record that has to be defensible two weeks later must be reproducible from the numbers it stored. Prose generated on the fly cannot be replayed or explained. This is a correctness requirement, not a cost optimisation — though it also happens to make the highest-frequency output in the product free to produce.
Editions must be immutable and carry their own evidence. Retroactive time edits will make yesterday's edition wrong. Do not regenerate — that destroys the archive property. Store the figures as they stood and label the page hard as an as-of snapshot.
Permission gating is a real design problem. Financial figures are owner-only; deadlines are never shown to users; managers see percentages rather than money. A single edition for everyone either leaks or is redacted into uselessness. Per-role editions of the same day's data are the likely answer.
Trustworthy capacity is a prerequisite. Unsold-hours figures are only meaningful if time off, holidays and part-time schedules are accurate. A tenant that doesn't keep those current will see phantom headroom, and the first wrong number on page one costs the reader.
7. What is not worth publishing
- Anything phrased as off-course, percentage off plan, projected exhaustion, or "pick up the pace." Not softened, not thresholded higher — absent.
- Status items nobody will act on ("deadline passed, project still active"). True, cheap, and better as a filter on a list page than as something that interrupts a person.
8. Cheapest first step
Generate editions before building anything around them. A daily job that renders and stores a per-tenant, per-role page reachable at a URL — no nudge, no nav link, no announcement. Run it for a month.
Then answer the only question that matters — does anyone read it — before building a ritual around it or changing anything else. If nobody does, that is a week spent and something true learned.
Open questions
- Which roles receive an edition, and does that reopen console access for the
userrole? - Morning only, or both bookends? (Morning first; the evening edition is a different signal set and a different job.)
- Does an edition need a push notification to be read at all, or is a habitual URL enough?
- How are projects without deadlines handled beyond being excluded and counted?