Operations that run
without the founder
in the room.
Joy Santos · Fractional COO and Operations Manager
I get hired to reduce the number of things that have to reach the founder. Workflows, documentation, capacity, accountability: those are the mechanism. Fewer interruptions is the result I am judged on.
A two minute introduction
Rather than read about how I work, watch it.
What the first 90 days looks like
Built to be true rather than impressive. Each phase earns the right to the next one.
Learn it before I change it
- Sit inside the real work and watch a full cycle end to end
- Log every interruption that reaches the founder, and its cause
- Learn the systems as they stand, including why they were built that way
- Map what actually happens, not what the procedure says happens
You get a written map of the operation and a ranked list of what is costing the most.
Fix in order of what interrupts you
- Work the day 30 list from the top, highest interruption cost first
- Write the procedure for anything that repeats
- One owner and one due date on every recurring item
- Start counting actual workload, by volume and by hour
You get documented procedures and the interruption count moving, with the number to show it.
Answer the staffing question with evidence
- A full cycle of workload data exists, so capacity stops being an opinion
- Recommend staffing: same, fewer, or the same people allocated differently
- Close the gaps that only appear once the obvious things are fixed
- Document to the point where someone else could run it
You get a staffing recommendation with the workload behind it, and an operation that survives me.
The interruption log, working
Day 1 to 30 produces this. Every question that reached the founder, what it cost, and why it had to reach them at all. Click an item to write its procedure and watch what happens to the count. Then switch views: the same log, grouped by cause, is where the capacity answer comes from.
What I am not going to promise
Because the version of this plan that promises more would be a worse plan.
I will not tell you your team is the wrong size in month one.
I need a full cycle of real workload first. Anyone answering that in week two is guessing, and a guess about headcount is expensive.
I will not replace your systems.
I will learn why they are set up the way they are before touching them. Systems usually look irrational until you know what they were protecting against.
I will not add tools.
Every tool I introduce is one more thing someone has to maintain. Removing steps beats adding software almost every time.
I will not give you a number I have not measured.
If I claim interruptions dropped, I will show you the count from before and after.
Systems I designed, still in production
A community ran its attendance, streaks and rewards by hand, every week. Rather than hire that job, I designed and coded it out of existence. Members claim their own rewards; the tracking runs itself.
Built so somebody else can run it
A system nobody else can operate is not an asset, it is a dependency. Every build I hand over ships with the manual: what the automation does, what a person does, and the things not to touch.
Roles before steps
The manual opens by saying who does what. Most procedure documents describe actions and leave ownership implied, which is where they fail.
What not to do, written down
A Do and Don't section exists because the expensive errors are almost always someone helpfully editing a field the script owns.
Written for the next person
Not for me. The test of a handover document is whether it works when the person who wrote it is unavailable.
The layer that removes the repeat work
A live view of my own automation account. Client identifiers redacted, every status toggle on.
An error alert manager
Most people automate the happy path and find out it broke when a client complains. This one reports its own failures.
A staleness watchdog
Watches synced data for going quietly out of date, which is the failure nobody notices because nothing visibly breaks.
Nobody gets chased
Two scorecards from two businesses. A target beside an actual, visible to the person who owns the number. Accountability stops being a conversation and becomes a column. Names and figures redacted.
I map it before I touch the tools
Improvement starts with agreeing what the process actually is. These are working boards, not illustrations.
Scoping a process before improving it
Suppliers, Inputs, Process, Outputs, Customers. The Define step of DMAIC. It settles where a process starts and stops before anyone argues about how to fix it.
Recurring marketing, run as a process
Planning through to published, with the handoffs drawn. Recurring content is the work that quietly eats a small team, because nobody owns the gaps between the steps.
Who reports to whom, roles not names
Built in two frames: an internal one with names, and this external one with roles only. The split exists so the map can be shared without sharing the people.
End to end, automated versus human
A member moving through a programme, start to finish. Colour-coded for what runs itself and what a person does, because that distinction is the whole point of a map.
Five rules I build by
- Fewest possible moving partsA process someone can follow beats a clever one they cannot.
- Build it off, let the owner turn it onNothing goes live because I decided it was ready.
- Record first, status secondIf it is not written down it did not happen, and nobody should have to ask.
- No automation speaks to a clientSystems detect. People talk. Clients hear from a human.
- Document so I am replaceableYou should be able to change anything I built without me in the room.