Not Manufacturing

When a project goes well, what remains?

Ideally, nothing. The client's problem disappears. The invoice gets paid without friction. That's it. Deliverables were always a side effect.

But most PMs treat IT like manufacturing. Specs, design docs, code as "product." Inspect, ship, done. That's the mental model. I get it. Handing over something tangible feels like work.

The trap is that engineers with pride fall into this the hardest. You want to build something technically beautiful. You want a robust architecture. That impulse is real. I have it myself. But "building something good" and "solving the problem" are subtly different things.

What the client actually wants is for their problem to vanish. Taken to the extreme, if you can solve it without writing a single line of code, that's the best outcome. No "deliverable" exists. The client is satisfied. This makes no sense through a manufacturing lens.

Think about it. The structure resembles a host bar.

A skilled host doesn't beg for the champagne tower. They create an atmosphere where the guest, in high spirits, volunteers: "Let's open a bottle." The guest appears to be paying for expensive liquor. In truth, they're paying for the time spent feeling good. The bottle remains, but it was never the point.

IT works the same way. Source code and documents remain. But what the client is really buying is "the state where the problem no longer exists." Not the deliverable itself.

Whether you hold this perspective changes how you run a project. Before asking what to build, you ask what to solve. Requirements take on a different grain. "Do we actually need to build this?" becomes a natural question.

I still oscillate between the urge to write clean code and the discipline of pure problem-solving. Probably always will.