The Cotomic Method: Why Operational Transformation Should Happen One Process at a Time

Picture a regional service business. Jobs arrive by email and phone. Someone copies the request into a shared tracker. Someone else builds the week's schedule in a spreadsheet only they fully trust. The customer calls for a status update because nothing in the system answers the question cleanly. An invoice waits because a code is missing. Nobody would call any single step a crisis. Each snag costs a few minutes. The week, though, is made of those minutes.

That pattern is familiar because it is ordinary. The work gets done. People invent workarounds so customers still get served. Over time the workarounds become the real process. What was designed on paper and what happens on Tuesday quietly diverge. In an office, the friction often lives in the side spreadsheet, the re-email, or the "just call me" loop that exists because the main workflow does not.

The temptation, when friction shows up everywhere, is to treat the whole company as the thing that needs to change. Launch the program. Redesign everything. Buy the platform. Train every department. That impulse is understandable. But broad scope can make it harder to isolate what is actually creating the friction and what change would meaningfully improve it.

The unit of change is the process

When the unit of transformation is the entire organization, attention scatters. Accountability softens. You can spend a year measuring activities—meetings held, tools rolled out, people trained—while Tuesday still looks the same. Large programs sometimes are necessary: a merger, a location that cannot run on the current tools, a regulatory shift that forces a rebuild. Those are real. But treating a multi-year, multi-initiative remake as the default response to everyday operational friction makes it harder to finish anything that changes how the work actually moves.

The Cotomic Method takes a different practical unit. Instead of making the whole organization the object of transformation, make the individual process the object of improvement. Quote-to-schedule. Intake-to-job. Job-to-invoice. One workflow with edges you can see. Transformation, in this view, is what accumulates when you finish focused improvements and keep going. It is not a single massive project that has to succeed all at once.

The Cotomic Method cycle

The Cotomic Method is a repeating cycle:

1. Find the friction

2. Understand the work

3. Find the cause

4. Make the smallest meaningful change

5. Measure

6. Repeat

None of that is methodology theater. It is how you get from "everything feels hard" to a change you can finish and judge.

Find the friction. Start where recurring friction is already visible in the work. Rescheduling that never ends. Work sitting between two people. The customer who keeps calling for status. The correction someone makes every Tuesday. When invoicing means hopping from the accounting tool to email to a spreadsheet to a portal, each hop is tiny and the day is made of them. Friction often looks ordinary, not like a fire.

Understand the work. Before you try to improve a process, understand the real workflow—not only the documented one. There is often a gap between the process as written and the process people actually perform. Follow a job through the work. See what actually happens. Who touches it. Where information comes from. Where employees leave the intended workflow. What workarounds they use. Where people wait, chase, copy, correct, or compensate.

In the service-business example, that means following one job from the inbound request through the tracker, the schedule spreadsheet, the status call, and the invoice. The official SOP may say one thing. The side loops tell you where time and errors live. Nelson Repenning, Don Kieffer, and Todd Astor put the discipline bluntly in MIT Sloan Management Review: if you are not embarrassed by what you find when you go see the work, you probably are not looking closely enough. Interviews help. So do walkthroughs, shadowing, and reconstructing a real job's path. The point is not which technique you favor. The point is to understand the work as it is before you choose a change.

Find the cause. The visible friction tells you where to investigate. It does not automatically tell you what is causing it. Write the problem as a gap you can count before you pick a remedy. "Quotes sit three days waiting for a code" beats "we need better systems." Jumping to a ready-made solution is a documented failure mode. Paul Nutt studied 356 real organizational decisions and found that roughly half failed by sustained-use criteria. Failures often traced to managers who imposed a solution early, limited search, and tried to push the plan through. Setting clear desired results before locking the fix was associated with better sustained use. Repenning and colleagues make the same practical point: a problem statement that smuggles in a tool or a diagnosis ("we haven't upgraded the system") skips the real gap. In the service shop, the cause might be a missing intake field, not "we need a new platform." Buy tools after you know what the work is asking for.

Make the smallest meaningful change. Small here means the scope of the intervention, not the importance of the issue. The goal is not the smallest possible change. It is the smallest change capable of meaningfully improving the problem being investigated—not an easy change that leaves the real gap untouched.

Karl Weick defined a small win as a concrete, complete, implemented outcome of moderate importance. One such outcome can look limited. A series of them changes who will support the next step. In the service business, the smallest meaningful change might be fixing how a job moves from request to schedule so the copy-and-paste, the one-person spreadsheet, and half the status calls move together. That is still one process. It is not a companywide remake. And it is not a ten-minute chore dressed up as strategy.

Measure. Measurement begins with the problem. Decide what you will count before and after, and choose evidence connected to the friction you set out to improve. If the problem is delay, measure time. If it is repeated correction, measure rework or errors. If it is status chasing, measure follow-up. If it is missing information, measure how often work arrives incomplete. Activity is not a result. Training attendance is not turnaround time. Short cycles make cause and effect learnable. You change one thing, you watch the week, and you answer "Did it get better?" with evidence tied to the original problem. Without that, you are guessing.

Repeat. Solving one source of friction often reveals the next. That does not mean the first improvement failed. It means the operation is showing you where to look next. Before moving on, make sure the improvement is actually working and can hold without constant intervention. Clear the bottleneck that was killing quote turnaround and the pile often moves to fulfillment or invoicing. Finishing one change is useful on its own. It also makes the next solvable friction more visible. Keep going.

Small scope is not small impact

Owners sometimes hear "start with one process" and hear "tackle something trivial." That is not the claim.

The quote-to-schedule path in the service example can touch customers, cash timing, employee stress, and how much capacity you actually have. The intervention is contained. The stakes do not have to be. Weick's "moderate importance" is about finishable scale, not about picking problems nobody cares about. Cumulative gains from repeated focused improvements can create more practical value than a sweeping program that never changes the work.

The principles behind The Cotomic Method are not disconnected from established process-improvement thinking. Observing the real work, understanding causes before choosing solutions, making focused changes, and measuring results are well-established ideas. COT brings them together in a practical method built around one process at a time—with the individual process as the unit you can understand, improve, measure, and stabilize before moving to the next source of friction.

What to ask of your own week

You do not have to fix everything to make something meaningfully better.

Look at the work that recurs. The copy between systems. The spreadsheet that exists because the primary tool does not. The status call that should not be necessary. The missing field that creates another follow-up. The handoff that sits between two people. The schedule only one person can build.

Ask: what is one process, narrow enough to understand and important enough to matter, where friction shows up every week?

Then run the cycle. Find that friction. Understand the work as it is. Name the cause before you buy a fix. Make the smallest change that would meaningfully improve the problem. Measure whether the week improved. When it does, look at what the improvement exposed next.

Operational transformation does not have to begin as a companywide project. It can begin as one finished process improvement, then another. That is The Cotomic Method: one process at a time, until the improvements compound into transformation.