The Floor Does Not Wait

Ask an IT organization what an outage cost and you will usually get a duration. Four hours. Ninety minutes. A number on a service level report, tracked against a target, reported monthly, and forgotten.

Ask a plant manager the same question and you get a different unit entirely. You get cases. Pounds. Pallets that did not get built. A truck that left the yard short, a customer order that shipped incomplete, a shift of people who stood next to a stopped line getting paid.

That is not a rhetorical difference. It is the whole difference, and it changes what technology leadership means in a manufacturing environment.

I have run 24/7/365 operations at three organizations. County corrections and public safety, where the facility never closes, and two food manufacturers whose plant floors do not stop. In every one of them the same thing was true: the systems people think of as IT were not sitting alongside the business. They were inside the thing that made the money, and when they stopped, the money stopped with them.

The first consequence is that maintenance windows are not a scheduling problem. They are a negotiation with production, and production is usually right. If the line runs three shifts and the only genuine window is a Sunday changeover, then your patch cycle, your firmware updates, your cutover plan, and your disaster recovery test all have to fit inside that window or they do not happen. Most enterprise IT calendars are built on an assumption of nights and weekends that does not survive contact with a continuous-production facility.

The second consequence is that redundancy stops being an architecture preference and becomes an operating requirement. In an office environment a failed switch is an inconvenience. On a plant floor the same switch sits between a scale and a scheduling system, and when it drops, product physically stops moving. The question is not whether the design is elegant. The question is what happens to the line in the ninety seconds after a component fails, and whether anyone has actually tested the answer.

The third consequence is the one most people miss. Escalation paths have to be built for the people who are actually there at two in the morning.

At that hour the person who notices the problem is not a director. It is a supervisor with a line down, a production schedule to hit, and a phone. If your escalation model assumes that person will correctly diagnose the issue, find the right on-call number, and describe the symptom in the vocabulary your team uses, you have designed a system that works during business hours and fails during the hours that matter. What works is the opposite: one number, answered by a human, who owns the problem from that moment forward regardless of which team ultimately fixes it.

I have watched an entire enterprise environment come back from nothing in forty-six days after an international cyberattack. Network, cloud, mobile, warehouse management, plant-floor systems, all of it rebuilt and secured from the ground up. The thing I took from that rebuild was not a technical lesson. It was that the clock was never mine. Every decision was measured against a plant that needed to run, and the correct answer was frequently the less elegant one that got a line moving sooner.

That is the discipline the floor teaches, and it does not transfer from anywhere else. You cannot learn it in a data center, because a data center will wait for you. You cannot learn it from a framework, because frameworks assume a change window exists.

You learn it standing in front of somebody whose line is down, who is not interested in your architecture, and who is going to ask you one question. When.

The right answer is a time, followed by the truth about your confidence in it. Not a status. Not an assurance that the team is engaged. A time, and what you actually know.

Everything else is a ticket, and a ticket has never restarted a line.

— Keith Formell