Knowing Is Not Deciding

I have written these on subjects that looked unrelated when I started. Risk appetite and security posture. Frameworks that stop running while everyone assumes they are fine. Provenance. Assessment. Plant floors. ERP. Mentorship. Building people to leave you. Going back through them, they are all making the same argument from different directions, and it took writing this one to see it.

The argument is that knowing technology and having a way of deciding what it means are different capabilities, and organizations routinely buy the first while believing they have bought the second.

I do not merely know technology. I have a method for deciding what it means, how it should be governed, how it should be assessed, how it behaves under pressure, and how an organization carries the standard forward after the person who set it has gone.

Those five are not a list of topics. They are the sequence, and each one fails without the one before it.

Meaning → Governance → Assessment → Pressure → Continuity

What technology means comes first, because a system that is misfiled is mismanaged from that moment onward. An ERP recorded in the portfolio as an application will be evaluated on features and implemented as a migration, when what it actually holds is how the company costs a product and decides what the plant runs next. Getting the category wrong sets every downstream decision at the wrong altitude.

How it should be governed comes second, and the trap there is mistaking a prohibition for a control. Forbidding a failure is a statement about intent. Catching one is a mechanism. Frameworks are load-bearing precisely because they are the thing still holding when nobody is watching, and a framework nobody has tested is a framework nobody knows the state of.

How it should be assessed comes third, because no one can approve a plan for a system they cannot see. The first deliverable is never the rebuild. It is an honest picture of what is actually there, what it depends on, and what it will take to make it enterprise grade. Everything downstream of a bad assessment inherits the error, and provenance is what lets you find that error later instead of arguing about it.

How it behaves under pressure comes fourth, and this is where most of it gets tested. Risk appetite sets posture long before any control does. A plant floor breaks the assumptions the enterprise playbook is built on. Downtime is measured in product, not minutes. None of that is visible in a design document. It shows up at two in the morning, on a Sunday changeover, in the ninety seconds after something fails.

How the standard carries forward comes last, and it is the one that decides whether any of the rest survives you. A standard differs from an opinion in exactly one property: you can be held to it when the person who taught it to you is not there. If the discipline leaves when you do, you built a dependency rather than a capability.

Put together, that is the seat where the pieces come together. Applications, infrastructure, data, security, process, vendors, budget, and the business held as one estate rather than eight functions that happen to report to the same person.

Specialists are findable. Deep ones, good ones, better than me inside their own domain, and I have hired them and learned from them. The scarce thing is not depth. It is somebody who can see the whole board, decide what a given system actually is, choose which findings matter, and then build the team that carries the standard after they leave.

The failure mode in an organization with more than one technology leader is almost never competence. It is the seam between them. Nobody is bad at their part. The part nobody owns is the boundary, and the boundary is where the outage starts, where the finding gets logged and never funded, where the plant network sits between two teams who each reasonably believe it belongs to the other.

That seam is the job. Not the stack underneath it.

Which is why I say I am deliberately agnostic to the technology. Not because it does not matter, and not because I have not been close to it. I spent roughly sixteen years with my hands directly on the work, and the years since leading the people who do it. I am agnostic because I have owned enough different stacks to know the stack is rarely the variable that decides whether something holds.

The method is the variable. The method is what I brought to every one of them, and it is the only thing I have that transfers.

— Keith Formell