Four process tactics to improve any workflow

Executive overview

Most workflows slow down because they lack redundancy, centralise decisions, waste time on speculative work, or run tasks in sequence when they could overlap. Four targeted tactics fix these failure modes without a full process overhaul.

Apply each tactic selectively — the right one depends on where your workflow breaks down.

Process resilience comes from redundancy, delegated decisions, demand-driven work, and parallelism — not from adding more steps.

Tactic 1: backups

• Backups mean having a second person or a second checkpoint ready before you need it.
• Cross-train at least one backup per skilled role; rotate work between them so the backup style is already normalised.
• For high-stakes steps, add extra review checkpoints — more eyes catch more errors before output leaves the process.
• Redundancy in people and redundancy in steps are separate levers; apply both where the cost of failure is high.

Tactic 2: little decisions

• Little decisions are low-stakes choices that bottleneck at a single person — usually the founder or manager.
• Fix option 1: document the rule so no human decision is needed at all (e.g. "no refunds" policy handles the refund question automatically).
• Fix option 2: delegate a dollar or impact threshold below which front-line staff decide independently.
• Raise the threshold over time as staff gain experience; the autonomy ceiling is a direct function of training and competence.
• Hiring well reduces the cost of delegation — undertrained staff force the threshold back down.

Tactic 3: just in time

• Just in time means doing only the work that current demand requires, not what you anticipate might be needed.
• Producing in advance ties up capacity on output that may never be used.
• Revised flow: check actual orders or demand first, then produce exactly that quantity, then use remaining time on other defined tasks.
• This makes productive use of slack time rather than filling it with speculative inventory.

Tactic 4: parallel processing

• Parallel processing is running independent work streams simultaneously rather than in strict sequence.
• Like opening a second checkout lane — it does not reduce the active work time per task, but cuts total elapsed time by eliminating waiting.
• In practice: start a downstream task (e.g. designing visuals) as soon as enough inputs exist, before the upstream task (e.g. blog draft) is finalised.
• Only parallelise once dependencies are cleared — do not start parallel tracks before you have what you need.
• Measure impact by comparing passive time (total elapsed, including waits) before and after; active time per task stays roughly constant.