Principles
Six working rules for changing how an organization operates. They are descriptive rather than aspirational. Each one came out of a system that behaved differently than it was supposed to.
Start with the operation, not the software.
Most change begins with a tool decision. That is the wrong end of the problem. Look at how the work actually moves first, then decide what the work needs. Software chosen before the operation is understood inherits whatever was already broken.
Friction is a systems signal.
Where people improvise, re-enter data, or keep a private spreadsheet beside the platform, the design gave out. Complaints are coordinates. Friction is evidence about the system, not a failure of the people absorbing it.
Deployment changes the problem.
A system behaves differently once real work runs through it. Volume, exceptions, and habit surface requirements no interview will. First contact with the operation is the only honest specification.
Technology is a component, not the objective.
Software, data, automation, and AI are inputs to an operating model. They carry leverage, not purpose. A platform installed inside a broken arrangement produces a faster version of the same loss.
The outcome is the unit of delivery.
Shipped capability is not the finish line. The work is complete when a measurable change holds in the operation and the organization can run, explain, and change the system without the person who built it.
Important work should not fight the systems around it.
People rarely need more effort available to them. They need less of it spent on coordination the system should have absorbed. Removing that tax is the whole purpose of an operational system.
These are descriptive rules, and each came out of an operation that behaved differently than it was supposed to. If one of them describes yours, the diagnostic is where that gets located.
How engagements begin