Human Middleware in Project Delivery

Human middleware is what happens when an experienced person becomes the integration layer between teams and systems. No interface carries a decision from engineering to procurement, so a project manager does. No rule says which schedule is current, so a senior engineer knows. The operation runs on what those people remember to carry across.

The term is deliberately borrowed from software. Middleware is the layer that moves information between systems that were not designed to talk to each other. In a growing project-delivery company that layer is often a person, and usually one of the most capable people in the building.

At three projects, carrying context by hand is not a failure. It is the cheapest and most reliable mechanism available: everyone sits close together, the project manager knows every open change, and a conversation is faster than a process.

The mechanism stays the same as the company grows, while the load on it does not. Each additional project adds its own changes and also adds interactions with shared engineering, shared procurement and shared crews. Coordination grows faster than project count, and it lands on the same few people.

The real status of a project is whatever its project manager says in the weekly call, and it differs from what the systems say. A change is considered safe only after a specific person has personally told procurement. Onboarding a new project manager takes months, because what has to be learned is not written anywhere.

The clearest sign is what happens when one senior person is away. If several projects slow down at the same time, that person was not managing those projects. They were the interface between them.

The visible cost is that the most experienced people spend their week reconciling instead of deciding. The less visible cost is that the operation has no memory of its own. What is known about the state of a project lives in a head, so it cannot be audited, handed over or scaled.

It also hides the underlying problem. Because the people are good, the handoffs appear to work. The missing architecture only shows when volume rises past what those people can absorb, which is typically during the growth the company was working toward.

Not a tool, at least not first. Human middleware is a symptom of handoffs that were never defined: what is handed over, by whom, to whom, and how the receiver knows it is complete. Until that exists, any system added on top inherits the ambiguity.

The work is to make the path explicit: lifecycle states with owners, a defined route for changes, and one agreed record for each fact. Some of that then deserves to be carried by a system. The experienced people stay; they stop being the cable.