On shipping: a discipline, not a verb.

For the first decade of my career I used the word ship as a verb. As in: we'll ship this feature next sprint. I thought I knew what it meant. Two years as a production manager at a marketing-and-development firm in the early 2010s taught me I had been using a different word with the same letters.

Production management — the kind that runs print campaigns, video shoots, multi-vendor brand launches — uses the word differently. In that world, shipping is not a button you press. It is a chain you hold.

What software thinks shipping is

In software, "ship" is a deploy. Code goes from staging to production. The button gets pressed. We say shipped and move on.

The word implies completion. The feature exists. The user can use it. Job done.

This is the casual use of the word, and it has produced two decades of features that technically deployed and never actually landed correctly. Releases that broke observability. Launches that arrived faster than the support team could prepare. AI features that went live before their eval harnesses were running. Migrations that were "complete" in the database while half the user-facing surface still pointed at the old shape.

Each of these was technically shipped. None of them was actually delivered.

What production management taught

In production management, shipping is the moment the work leaves your control and lands in the world it has to work in. That moment is not a single press of a button. It is the convergence of:

• The calendar — every dependency timed against every other, with realistic slack built in.
• Operations — every vendor coordinated, every handoff explicit, every waiting room avoided.
• Communications — every stakeholder informed at the right moment, in the right channel, with the right level of detail.
• Quality — every output reviewed against the standard before it leaves your control.
• Recovery — every predictable failure planned for, with a quick fix already in your back pocket.

If any of these is broken, you have not shipped. You have published, which is a different and lesser thing.

The difference between shipping and publishing is the difference between a brand launch that lands cleanly across press, retail, social, and customer support — and one where the press release went out on Monday but the retail displays didn't arrive until Thursday and the support team learned about the new product from a customer ticket. Both technically "shipped." Only one actually landed.

The hidden discipline

The discipline behind real shipping is the chain. The strongest link doesn't matter; the weakest link fails the whole thing. The production manager's job is the chain — not any single link inside it.

What that looks like, hour by hour:

• Schedule reads, three times a day, looking for slipping dependencies before they slip.
• Vendor calls, fifteen minutes each, six per day, to check that everyone has what they need.
• Pre-mortems before every major dependency lands: what's the worst-case failure here, what's our response if it happens.
• Quick fixes ready for predictable failures, so the response time when something breaks is measured in minutes rather than hours.
• Communication scripts written ahead of time for the most likely incidents, so the words to use are not invented under stress.

None of this is romantic. It is mostly boring. It is also what makes the difference between work that got done and work that landed correctly. The discipline is the chain.

Shipping is not a button. Shipping is what surrounds the button.

What this means for software now

Software adopted "ship" from production language and kept the word while losing the discipline. The deploy is one link in the chain. If observability isn't ready, you haven't shipped. If support docs are stale, you haven't shipped. If the changelog email is delayed, you haven't shipped. If the rollback path hasn't been rehearsed, you haven't shipped.

Every engagement I run today treats shipping as the chain rather than the deploy:

• Calendar. Every dependency tracked in the client portal. The slipping ones are visible before they slip the launch.
• Ops. Any external partners coordinated explicitly. Webhook handlers tested under realistic load. Migration runbooks rehearsed.
• Communications. Client knows what's coming, when, and what to watch for. The status of every in-flight piece of work is visible without being asked.
• Quality. Code reviewed by Atlas. AI features evaluated by Sextant before deploy. Format and contract tests on every endpoint.
• Recovery. Rollback plans documented. Runbooks for known failure modes. The quick fix is staged before the launch, not invented after the alert.

None of this is novel. All of it is the production-management discipline applied to software, fifteen years late, by people like me who learned the word in another industry first.

The closing argument

The word "ship" is misleading because it sounds like a moment. The thing it describes — when done right — is a practice. It is what you do for the days before the deploy and the days after, with the deploy itself being a quiet step in the middle that almost nobody notices.

Every engagement that goes well is one where the chain held. Every engagement that did not is one where someone — often the person whose job was the chain — forgot which link was theirs.

If you are hiring an operator or an agency, the test question for shipping is not can you deploy quickly. It is do you understand what surrounds the deploy. The answer to the first one is usually yes. The answer to the second one is what separates the practices that land the work we ship from the practices that merely publish it.

— Mikkel, Bangkok