Picture a plant that makes plastic bottle caps by the billions. Lines running a couple thousand caps a minute, takt time in seconds, changeovers every time a customer’s SKU switches color. Hanging by line three is the downtime log. A clipboard. The operator writes down why the line stopped, which is almost never why the line stopped. The stops that matter are the sixty-second jams, forty of them a shift, cleared before the pen comes out. Nobody logs a stop that outlives its own coffee break.
The shift lead’s scrap workbook has fourteen tabs, and the person who built it is the only one who understands tab nine. Somewhere around cavity seven, scrap is running light and nobody will know until a customer complaint lands. Last week a veteran tech fixed the filler that jams after every changeover, at 2 AM, and the fix lives in his head, and in two years it retires with him.
Two states over, the same company runs a distribution center with the same disease. On-time-in-full is a number someone assembles on Mondays. Dock-to-stock time lives in a system nobody trusts. The floor knows which dock runs slow. The reports do not.
That plant is a composite of places I know, not any single facility. The clipboard is not.
Then the mandate comes down from the top, and it is a good mandate: we are becoming a data-driven organization. The flagship is a Manufacturing Dashboard, built by IT for operations, one screen of truth fed by real manufacturing data points. Line performance, downtime reasons, changeovers, scrap, quality, and the flow of goods through the distribution network behind it. Everyone agrees. Everyone is right. And the single decision that determines whether that dashboard changes anything is not a technology decision at all. It is an org chart decision: which IT model builds it.
Because the same project, with the same tools and the same budget, goes two completely different ways depending on how IT is organized. Watch both.
In the traditional model, IT is centralized and request-based. The business submits a request. The request becomes an intake form, the intake form becomes a project, the project gets a BI team, a data architect, and a requirements workshop. Eight workshops, to be exact, because the manufacturing engineers can only attend Tuesdays. The team builds the data pipelines away from the floor, writes the dashboards against the requirements document, and ships eleven months later. The dashboard works. Technically, it is flawless. It answers every question anyone asked in the workshops, which is the problem, because the workshops were eight months before go-live and the floor has moved on. The downtime categories are subtly wrong, so the techs keep their clipboard. The distribution metrics measure what the Monday report already measured, so nobody opens it twice. Adoption stalls. A year later there is a refresh project to fix the requirements, which will be wrong by the time it ships again.
Nobody in that story is lazy. The model is the problem. Request-based IT is built to move work through a queue, and it does exactly that. The queue is where the value dies, because by the time software arrives, the operation that asked for it has changed.
Now the same mandate at a company that runs IT on the Forward Deployed Engineer model. Same dashboard. Same budget. The difference is where the builders sit. An engineer on IT’s org chart is deployed into operations, solid line to IT, chair on the floor. Solid line to IT means the skills, the standards, and the security perimeter come with the badge. The chair on the floor means the priorities come from the shift leads, the maintenance techs, and the dock supervisor.
Their first three weeks: no workshops. They stand next to line three and the inbound dock instead, and they learn the real data points, the jam events already sitting in the PLC registers that nobody reads, the reasons the clipboard actually collects, the dock-to-stock times buried in the WMS. Then they ship one screen, one slice: pace versus plan on line three, live, in caps per minute, plus the jam counter that outruns the clipboard. It shows what the deck never showed. Line three is not running at 85 percent. It is running at 79, and now every shift watches the gap happen.
That screen is not a deliverable. It is a conversation. The shift lead looks at it and says the counter is missing the changeover spikes, and it appears the following week. The maintenance lead wants the top three downtime reasons wired to the work order system, and it ships the week after. The dock supervisor asks for on-time-in-full by carrier and gets it before the next quarterly review. The dashboard grows the way the floor pulls material, one pull at a time, and adoption is not a rollout plan because the users pulled it into existence.
Same mandate, same budget. One org got a working screen in three weeks and a growing cockpit by month six, with predictive maintenance on the labeler, scrap tracked by mold cavity so the day cavity seven runs light is the day someone walks over, OTIF by lane, dock-to-stock trends, and knowledge capture so the 2 AM fix does not retire with the tech who made it. The other org got a technically flawless dashboard, eleven months later, answering last year’s questions. The difference was never tools, talent, or budget. It was the delivery model. One org moved the work through a queue. The other moved the engineer to the work.
Here is why the FDE model wins, stated in the language operations already speaks. Manufacturers invented flow. Takt time, small batches, single-minute changeovers, the whole religion. Every person on that floor knows that a big batch is where waste hides, that a queue is money sitting still. Then they let technology reach the same floor as an annual giant batch, an intake form becoming a steering committee becoming a go-live that ships a year after the problem was seen. The plant measures flow in seconds. Its IT department measures delivery in quarters. Same company. Same building. The FDE model applies the plant’s own religion to IT’s value stream: batch size drops from one project a year to a capability a week, the queue becomes a walk across the floor, and the governance cycle becomes a hallway conversation with the security team who already knows the engineer because they sit ten feet away.
And the flow compounds, which is the part the request model can never do. Every connection the FDE builds stays built. Every PLC and every dock scanner the FDE learns makes the next integration cheaper. Every screen that turns out to be right buys the trust that makes the next conversation shorter. Year one produces the cockpit. Year two produces whatever operations asks for next, at a third of the cost, because the pipes, the trust, and the context already exist. Under the request model, every initiative starts from zero, a new intake form, a new discovery phase, a new vendor. The FDE is not a project. The FDE is a production system for capability, and production systems compound.
Count the value the way operations counts it, in units the floor recognizes. Six points of OEE back on line three is roughly a hundred caps a minute that were already paid for. Four minutes off an average changeover, times three a day, is an hour of capacity a shift that required no capital. OTIF up two points is customers who stop calling. None of it shows up as a line item called software value. It shows up as caps, minutes, pallets, and avoided downtime, which are the only currencies a plant or a distribution center respects.
There is a multiplier arriving, and it is why this model wins now and not five years ago. Agentic AI tools keep getting better at writing the code, building the pipelines, and handling the boring glue. A single engineer with an agent team behind them now does work that used to take a five-person delivery squad, which is a claim I would have laughed at before running one of these setups myself. The Forward Deployed Engineer is the human in that loop. One person embedded in your operation, with disciplined agent tooling behind them, shipping real systems weekly. The org chart hasn’t caught up.
So for the IT leaders, here is the version of this you can act on Monday. You are going to fund a data-driven organization either way. The question is which org model delivers it. Keep request-based IT and you will get technically correct dashboards, delivered late, answering stale questions, adopted by nobody. Add the FDE model and you get the same dashboards growing in the building, answering the questions the floor asks this week, adopted because the floor built them. Write the job description: an engineer on IT’s org chart with a chair in operations, manufacturing or distribution, wherever the data is born. IT owns their skills, their standards, and their access. The business owns their priorities and their results. Point them at one visible problem the floor already complains about. First working capability inside thirty days, or you hired a consultant with a better title.
Both orgs support the business. Only one of them ships the value the business asked for faster. The plant already believes in flow. The last queue in the building is the one between the floor and IT, and the FDE is the person who removes it.