What Makes a Problem Cotomic?

Most operational problems arrive in the wrong size. Either they are framed as "fix the company"—too big to finish—or they get reduced to a tidy chore nobody will notice. Both frames miss the useful middle.

A Cotomic problem sits in that middle. It is a process-sized problem: small enough to understand and change, and important enough to matter. Both tests have to pass. That is what makes a problem Cotomic: not "tiny," and not "everything"—a right-sized process unit.

Small enough to understand and change means the work has edges. You can say where the process starts and where it ends. You can follow a real job through it. You can name who touches it, where information comes from, and where people wait, chase, copy, or compensate. If you cannot watch the work and tell whether a change helped, the problem is still too large—or too vague—to treat as Cotomic.

Important enough to matter means the stakes are real even though the scope is contained. If this process failed for a month, someone would feel it: a customer waiting, a person on the team covering for a broken handoff, cash sitting because an invoice cannot leave, capacity lost because only one person can build the schedule. Importance is not measured by how dramatic the project sounds. It is measured by what happens when the process keeps failing in ordinary weeks.

A Cotomic example is not "operations." It is something like request-to-schedule: one process with a start, an end, and a week that shows whether it is working. Fixing that unit is not a companywide remake. Leaving it alone is not free either.

A Cotomic problem is also not a ten-minute tidy-up dressed up as strategy. Renaming a folder, adding a field nobody uses, or polishing a form that is not where the friction lives can feel like progress and leave Tuesday unchanged. Finishable scale is not the same as picking something nobody cares about. The goal is a process unit you can finish improving in a way that meaningfully moves the problem.

Karl Weick defined a small win as a concrete, complete, implemented outcome of moderate importance. Moderate importance is the point. That same discipline applies here: contained enough to finish, weighty enough to count.

If a problem fails the first test, you cannot see what you are changing. If it fails the second, you are tidying. Cotomic work lives where both pass: one process with edges you can understand, stakes high enough that finishing the improvement changes the week, and a scope small enough that you can actually change it.