The point of your first week as an operations owner is to understand rather than to change. Changes made before you know why something exists are changes you will reverse. What to resist The pressure to demonstrate immediate value. * Removing a step whose purpose is not yet clear * Adopting the
Understanding what a mature operation looks like is useful as a target. Maturity is not having systems — plenty of companies have systems nobody uses. What maturity is not These are often mistaken for it. * Having a tool for everything * Extensive documentation nobody reads * Detailed processes that people work around * Dashboards
To make the case for operational structure, address the real objection. The concern is not process in the abstract — it is that process means slowness, and at small scale that concern is often justified. The objection, taken seriously Founders have usually seen structure go wrong. * Formality adopted before it was
To find the process costing you most, look past the loudest complaints. The expensive process is often one nobody mentions because everyone has accepted it. Why complaints are a poor guide They reflect visibility rather than cost. * The loudest problem prioritized over the largest * Distributed costs invisible because each instance
Handling a process that works but nobody likes starts with taking the complaint seriously. A process disliked by everyone who uses it is a process being worked around somewhere. Why dislike matters even when results are good The results are measured and the workarounds are not. * Data entered minimally to
Knowing when to stop improving a process matters because attention is the scarce resource. A process that works well enough is competing with one that does not work at all. Signs you have reached the point Each suggests the returns have flattened. * Stage timings stable across several quarters * Recent changes
To run a discovery conversation about a process, ask about specific recent cases rather than about the process in general. General descriptions are always tidier than reality. Why general questions mislead People describe the process they believe in. * The official version described, not the practised one * Exceptions omitted because they
To keep documentation and process in sync, attach the document to the process it describes. Documentation stored separately drifts because nothing connects a change in one to the other. How drift happens The process changes and the document does not. * A phase added and the document describing the old flow
To combine small processes into one system, share the records rather than merging the processes. Forcing unrelated work into one pipeline produces a process that fits none of it. What to share and what to keep separate The distinction is between data and flow. * Share — clients, suppliers, products, cost centres,
To explain an operations platform, describe the problem rather than the category. Nobody recognizes themselves in "no-code relational database", and everybody recognizes a spreadsheet that four people edit. Why category language fails It describes the mechanism to someone asking about the outcome. * Terms that mean nothing outside
To choose your first three processes, pick them as a set rather than one at a time. Three processes that share data compound; three unrelated ones are three separate projects. Why the set matters more than each one Shared records are what make the second and third faster. * An isolated
To retire a process, you stop new work entering it, finish what is in flight, and preserve what it produced. Deleting it loses the history; leaving it running creates confusion. Why obsolete processes linger Nobody wants to be the one who deleted something. * Forms still accepting submissions nobody handles * Automations