| name | solo-operations-manager |
| description | Design a sustainable operating system for a solo founder or tiny team using capacity planning, work-in-progress limits, service levels, weekly reviews, automation, and recovery boundaries. Use whenever the user is overwhelmed, context-switching, missing priorities, juggling product/marketing/support, working reactively, or planning a realistic weekly rhythm. |
| category | business |
| license | MIT |
Solo Operations Manager
Create an operating system that protects the highest-leverage work while keeping
customers, reliability, administration, and recovery from being neglected.
Themed days are one option—not a universal solution.
Operating Rules
- Start from current commitments, deadlines, customer obligations, health/life
constraints, and available capacity.
- Plan below theoretical capacity. Interruptions, support, maintenance, and
recovery are real work.
- Limit simultaneous initiatives and explicitly choose what will not be done.
- Do not use arbitrary revenue, hour, or productivity benchmarks as universal
standards.
- Treat persistent exhaustion, sleep disruption, cynicism, or impaired
functioning as a reason to reduce load and seek appropriate support—not as a
scheduling defect to optimize through.
- Automation must preserve review, reversibility, security, and a manual
fallback.
Workflow
1. Inventory Work and Obligations
Capture every active responsibility:
- product/build;
- customer support and success;
- marketing/sales;
- finance/legal/admin;
- reliability/security/maintenance;
- learning and strategic research;
- personal commitments and recovery;
- waiting/blocking dependencies.
For each item record outcome, deadline, recurrence, consequence of delay, effort
range, owner, and whether it can be deleted, deferred, delegated, automated,
batched, or simplified.
2. Establish the Capacity Budget
Estimate sustainable weekly capacity from recent reality, not aspiration.
Reserve explicit buffers for:
- support and incidents;
- administrative work;
- maintenance and cleanup;
- planning/review;
- breaks, exercise, relationships, sleep, and a full off-duty period;
- uncertainty.
Do not allocate 100% of time to planned project work. When demand exceeds
capacity, change scope, service levels, deadlines, or commitments before
extending hours by default.
3. Choose the Current Outcomes
Select:
- one primary business outcome;
- at most one secondary/maintenance outcome;
- essential keep-the-lights-on obligations;
- a visible “not now” list.
Use a short decision frame: impact, urgency/consequence, confidence, effort,
reversibility, and strategic fit. RICE and ICE
calculators can support—not
replace—judgment.
Set work-in-progress limits. A useful default is one major build/growth
initiative plus a small maintenance lane, adjusted to the work.
4. Design the Weekly Rhythm
Choose a structure based on interruption patterns:
- themed days;
- morning deep-work blocks with afternoon operations;
- alternating build and market days;
- fixed support windows;
- maker/manager split;
- launch or incident mode for a limited period.
Use weekly templates and customize them.
Protect the highest-energy block for the primary outcome. Batch shallow tasks
and keep transition time between incompatible work types.
5. Create Service Classes and Triage
Define:
| Class | Examples | Response |
|---|
| Emergency | Security, data loss, severe outage, safety/legal deadline | Interrupt with clear criteria |
| Time-sensitive | Paying-customer blocker, expiring deal, scheduled launch | Handle within stated window |
| Standard | Normal support, bugs, admin | Queue and batch |
| Improvement | Refactors, ideas, optimizations | Prioritize at review |
Create support and communication service levels the founder can actually meet.
Use boundary scripts to communicate response
times, availability, and refusals without overexplaining.
6. Build a Lightweight Control System
Maintain one trusted board/list with:
- current outcome;
- ready queue;
- active WIP;
- waiting/blocked;
- recurring operations;
- someday/not-now;
- decision log.
For each major task define “done,” next physical action, and owner/dependency.
Separate calendar commitments from flexible tasks.
7. Automate and Delegate in the Right Order
First delete or simplify. Then document. Automate stable, frequent, low-judgment
steps. Delegate when the output and escalation path are clear.
For every automation define trigger, inputs, permission scope, idempotency,
observability, error path, rollback, owner, and manual fallback. Do not automate
ambiguous customer or financial decisions without review.
8. Review and Rebalance
Weekly review:
- outcomes completed versus merely busy;
- unplanned work and interruptions;
- support/reliability load;
- acquisition/customer learning;
- capacity forecast and commitments;
- energy/recovery trend;
- what to stop, defer, automate, or renegotiate;
- next week’s primary outcome and WIP limit.
Monthly, review whether the operating model supports business strategy. Change
the rhythm when the evidence changes.
Metrics
Use trends from the founder’s baseline:
- primary-outcome completion;
- cycle time and age of active work;
- WIP and blocked time;
- planned versus unplanned load;
- response/service-level adherence;
- incidents and recurring failure demand;
- founder hours and recovery periods;
- revenue/customer-learning time;
- energy and sustainability self-rating.
Metrics should trigger a conversation, not gamify overwork.
Output Contract
Return:
- obligation and capacity audit;
- chosen outcomes and not-now list;
- weekly rhythm with buffers;
- WIP limits and triage/service levels;
- task-board structure and recurring checklists;
- automation/delegation candidates;
- weekly review template;
- overload triggers and recovery plan.
Sources
