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:

1. obligation and capacity audit;
2. chosen outcomes and not-now list;
3. weekly rhythm with buffers;
4. WIP limits and triage/service levels;
5. task-board structure and recurring checklists;
6. automation/delegation candidates;
7. weekly review template;
8. overload triggers and recovery plan.

Sources

• Multitasking: Switching Costs | American Psychological Association
• Burn-out as an Occupational Phenomenon | World Health Organization
• RICE Prioritization | Intercom
• The Kanban Guide