Operate at the Edge of Your Capacity

Proof required

Submit your operating system map (which tools you use, how you process incoming requests, how you track commitments, how you communicate status) plus your 1-week log of breakdowns (interruptions / context switches / dropped balls / late deliveries with specific dates and brief descriptions) and a 200-word gap analysis naming one specific breakdown pattern.

What gets checked

• Operating system map is specific enough to be actionable — 'I use a to-do list' does not qualify; the map should specify which tool, how items enter, when they are reviewed, and what the failure mode is
• 1-week log contains real events with dates and brief descriptions — not a retrospective summary
• Gap analysis names one specific breakdown pattern (e.g. 'I respond to Slack immediately instead of batching, which causes context switches every 12 minutes on average') with evidence from the log

Common mistakes

• Writing the operating system map as the system you intend to use, not the one you actually use — the log will expose the discrepancy, so the map should be honest from the start
• 1-week log with fewer than 10 entries — operators who work in complex environments typically have 5–15 meaningful interruptions per day; a log with 3 entries per week is under-capturing
• Gap analysis that blames external factors entirely ('too many meetings', 'Slack is too noisy') rather than identifying the personal behaviour pattern that makes those factors costly

Resources

What a verifier looks for

• Ask the submitter to describe a specific dropped ball from the log in detail — what was the commitment, when was it made, and when did they realise it had been dropped?
• Check that the operating system map and the log are consistent — the log should show breakdowns in the system described in the map, not a completely different set of problems
• Confirm the gap analysis is a pattern, not a single event — one bad week does not constitute a pattern; the diagnosis should reference at least 3 similar instances in the log
• Ask the submitter what they would change in their operating system map if they were writing it today after seeing the log — this tests whether the diagnosis has generated genuine insight

You'll sign in first, then come straight back here.

Proof required

Submit your operating system redesign document (what specifically changed, why, and what you predicted would improve) plus your 8-week operating log (minimum 8 weekly entries, each with: prescribed behaviour / actual behaviour / that week's interruptions-dropped balls-late deliveries count / one adjustment made).

What gets checked

• Redesign document is specific about what changed — 'I will be more organised' does not qualify; the change must be to a specific process element (e.g. 'I will process my inbox once at 9am and once at 5pm instead of continuously')
• 8-week log shows actual behaviour, not prescribed behaviour — entries that never deviate from the prescription are self-reporting as perfect adherence, which is almost never accurate
• Log shows at least 3 adjustments across the 8 weeks — a system that required no adjustment over 8 weeks was either perfect from day one (unlikely) or the log is idealised

Common mistakes

• Redesigning the entire operating system rather than the one breakdown point — breadth is the enemy of the 8-week experiment; focus on the single gap identified in M1
• Log entries that report 'zero interruptions' or 'no dropped balls' consistently — this almost never reflects reality in complex professional environments
• Adjustments that are aesthetic rather than structural (e.g. 'I switched from Notion to Todoist but the process is the same') — adjustments must address the root cause of the breakdown

Resources

What a verifier looks for

• Ask the submitter what the metric looked like in week 1 vs week 8 — a real operating improvement should show a measurable change in dropped balls or late deliveries over time
• Check that adjustments in the log are structural rather than cosmetic — switching tools without changing process is not an adjustment
• Ask the submitter to describe a week when the system failed — every 8-week experiment has at least one bad week; if none are recorded, the log is idealised
• Confirm the redesign targeted the specific gap from M1 — if M1 diagnosed 'dropped balls from unclear commitments' and M2 redesigned 'time blocking', ask why the connection was made

You'll sign in first, then come straight back here.

Proof required

Submit your M2 operating system documentation plus the reviewer's written assessment: their observations on the system's design, the scenario they introduced and how you walked through it, one gap they identified that was not in your own M1 diagnosis, and their sign-off confirming their role and that this was a live session.

What gets checked

• Reviewer identifies at least one gap not in the submitter's own diagnosis — a reviewer who only confirms the submitter's self-assessment adds no adversarial value
• Scenario walkthrough is specific — the submitter describes exactly how each element of their system would handle the novel scenario, not a general assurance that 'the system would handle it'
• Reviewer sign-off confirms current or recent (within 5 years) professional operations management background

Common mistakes

• Presenting a polished operating system that does not reflect actual usage — the reviewer should see the real log with its imperfections, not an idealised version
• A reviewer who only compliments the system — a qualified operations reviewer should find at least one gap in any self-designed operating system
• Scenario walkthrough that is conceptual ('my system would prioritise this') rather than procedural ('I would go to my inbox, capture it as a next action, add it to my project list, and block time for it this afternoon')

Resources

What a verifier looks for

• Introduce a genuine novel scenario — not one the submitter could have anticipated from their log — and assess whether they can walk through the system procedurally (step by step) rather than conceptually
• Ask for the weakest element of the operating system in the submitter's own view — then probe whether that element is actually the weakest or whether there is a gap they have not noticed
• Reviewer minimum qualification: 5+ years managing complex operations at scale (COO, senior operations manager, chief of staff, or equivalent) — a project manager with narrow scope does not qualify
• Check that the redesigned element from M2 is visible in the system and that the log shows its real impact — not just its prescribed impact

You'll sign in first, then come straight back here.