How to fix your operations
Operations break quietly, then all at once.
Measure a week of where the hours go, fix the three worst handoffs by hand, give every recurring task one named owner, write the procedure down as you fix it, then put a weekly cadence around the numbers. Automation comes after that sequence rather than instead of it.
Is it a fit?
Bottleneck
One area is holding the others still, and it is usually not the loudest one.
Evidence
You can see how long work waits, not only how hard people are working.
Order
Fix the cause before the symptom, or the symptom comes back with interest.
Start here. You get back which of the six areas is the constraint, and what to do about it before anything else.
Check the whole operationWork it out in a minute
Eighteen questions across six areas. Names the one weakness holding the others in place, and the first ninety days in order.
The plan
Do these seven, in order
A time against each one and a way to tell it is finished.
List every recurring process
Mark the ones a customer waits on.
2 hours · Done when each has an owner name against it
Follow one job end to end
Write down every hand it passes through and every wait between them.
half a day · Done when the path fits on one page
Measure a week of hours
Each person logs time against those steps for five working days.
10 minutes a day · Done when hours a month exist for every step
Fix the three longest waits
Remove one step from each. Not all of them, three.
1 week · Done when the wait is re-timed and shorter
One owner per recurring task
Written where the team can see it.
1 hour · Done when no task has two owners or none
Write the SOP while you are in it
Not afterwards, when the detail has gone.
as you go · Done when someone else runs it from the document without asking
Install the weekly numbers cadence
Same five numbers, same day, thirty minutes.
30 minutes a week · Done when it has run four weeks without being moved
Almost nobody calls an operations problem an operations problem. They call it a hiring problem, a software problem, or a people problem. The tell is different: the same fire starts every week, the same three people are the only ones who can put it out, and nobody can say out loud where the week went.
What follows is the sequence that works, in the order that works.
Where the time goes
When a team feels underwater the instinct is to hire or buy software. Both are expensive answers to a question nobody has measured. The lost capacity is almost always in these four places.
| Cost | What it looks like | How to measure it | First move |
|---|---|---|---|
| Waiting | A task takes four minutes of work and clears in four days. The time is spent in queues, not in the doing. | Cycle time minus touch time, on the last ten items that went through. | Remove one approval, or set a default so only exceptions need a decision. |
| Re-entry | The same customer detail typed into a form, then a spreadsheet, then a system of record. | Count the systems one record passes through before the job is finished. | Name one system as the source. Everything else reads from it rather than storing its own copy. |
| Rework | Work that comes back because something upstream was wrong, missing or ambiguous. | Share of items that need a second pass. Two weeks of tallying is enough to see it. | Fix the input, not the output. Required fields and a template beat another reviewer. |
| Checking | Somebody reviews everything, in case. Most of what they review was already correct. | Hours spent reviewing, split by what the review caught. | Sample instead of checking everything, and put the check on the step that fails. |
None of these are fixed by working harder and only one is fixed by software, which is why the work starts with measurement.
01.Watch the work, not the org chart
Pick one live example and follow it the whole way through. One order, one client, one hire, one invoice. Sit with the people who touch it and watch what they do, including the parts that are not in any document: the spreadsheet someone keeps privately, the message they send to check a thing the system should already tell them, the approval they chase twice.
The written process and the real process are never the same.
02.Measure a week of hours
For five working days, have everyone note where their time went in rough half-hour blocks. Not a timesheet, not surveillance, and not something anyone should spend more than two minutes a day on. Say plainly why you are doing it, which is to find the work that should not exist, not to judge anyone.
The result reframes the argument.
03.Fix the three biggest handoffs
Operational pain concentrates in the seams, not inside the departments. Sales to delivery, delivery to billing, request to approval, customer to support. Each seam is a place where information gets retyped, context gets lost, and a thing waits for somebody to notice it.
Rank your seams by how many hours the log shows sitting in them.
Twenty minutes with a practitioner from our team, and you leave with a plan for your specific situation.
Talk to an expert04.Give every recurring task one owner
Every recurring task gets one name against it. Not a team, not a role, one person, plus a date and one place where its status lives. Shared ownership sounds collaborative and functions as nobody owning it, which is why the task that everyone owns is always the one that slipped.
This is the least glamorous step and often the one that changes the most.
05.Write the SOP as you fix it
Write the procedure while you are rebuilding it, not once it is finished. Documenting afterwards never happens, and if it does the memory of why each decision was made has already gone. A working SOP is short: the trigger, the steps, the owner, what done looks like, and what to do when the exception shows up.
The test is whether a capable new person could run it on their second day without asking anyone.
06.Install a weekly numbers cadence
Pick a small set of numbers that leadership will read, and review them at the same time every week without exception. Five to eight numbers, one page, same format each week. Pipeline, delivery load, cash, and whatever the specific bottleneck of this business is.
The cadence matters more than the metrics.
Buying software before fixing the process it automates.
Fixing symptoms department by department while the seams stay broken.
Changing everything at once; sequence beats scale in operational change.
Questions we get
The ones that come up on almost every call.
How long before this shows results?
The hours log gives you something usable inside a week.
Do we need new software for this?
Usually not, and buying it first is the most common expensive mistake.
Our team is small. Is this overkill?
It is more valuable when the team is small.
What if people resist the time log?
They resist being measured, not being asked.
On who holds the seat while this happens, a fractional COO or a full time COO. On sequencing, document it or automate it says where to stop writing and start building. If the fix turns out to need a person, hiring and talent starts from the same measurement. Work that crosses teams needs project management.
Most of this is doable in house.
Your results so far
Kept in this browser, sent nowhere.
By Shaheer Shaikh, technology and operations consultant · Updated October 3, 2026
Read next
The service behind this guide, the questions people ask, and the next thing worth reading.
Shaheer leads the work, with engineers, writers, filers and analysts behind him. C-suite operations for a San Francisco AI company, Six Sigma on the process side, Anthropic certified on the Model Context Protocol, ten years across eight industries. See what we have built