Shipping Is a Management Skill
If you cannot guide the team to ship, you are not managing, you are guessing.
This post is inspired by a single, brutally accurate sentence:
Managers keep failing to guide teams to ship working software that meets requirements on time and under budget.
If that makes you feel personally attacked, same. This is one of the most common forms of corporate dysfunction in tech. Not the dramatic kind. The boring, expensive kind, where everyone looks busy, nobody ships, and then leadership acts confused about why the roadmap is a graveyard.
So let’s rant about it.
Shipping is not an engineering problem
Shipping is a management system. Engineering does the building. Management makes it possible to build the right thing, in the right order, with the right constraints, and the actually get it out the door.
When teams do not ship, it is rarely because developers “did not work hard enough”.
It is usually because:
the goal was foggy
priorities changed weekly
dependencies were invisible
decisions took forever
scope grew like a mould in a forgotten lunch container
And then everyone acts shocked when the deadline misses.
If you are a manager reading this and thinking, “Yeah but my team is just slow,” I have bad news. Your team is not slow. Your system is slow.
What “shipping” actually means
Let’s stop being poetic about it. Shipping means you delivered working software that:
meets requirements
has acceptable quality
is used by someone
shipped on a timeline that did not require heroics
If you shipped “something” but the requirements were never clear, you did not ship. You released a surprise.
If you shipped “on time” by cutting testing and setting the on-call team on fire, you did not ship. You threw a flaming bag of shit over the fence.
If you shipped “under budget” because you quietly removed half the feature and never told anyone, you did not ship. You performed a magic trick.
Shipping is not a date on a slide. Shipping is a thing that is real in production.
The three-part failure: requirements, time, and money
That one sentence is really three separate ways managers blow delivery:
“Working software that meets requirements”
“On time”
“Under budget”
You can mess up any one of these and still look competent for a while, and you can even build a career out of it. But eventually the organization realizes it is paying for theatre, and the bill is enormous.
Requirements are not a guess
This is where it starts. Teams cannot meet requirements they do not have. And no, “Improve onboarding” is not a requirement. It is a wish.
A lot of managers accept requirements in these format:
a Slack thread
a meeting everyone forgot
a half-written doc
a Jira epic titled “Phase 2” with zero acceptance criteria
Then they wonder why the team cannot estimate, why QA “keeps finding issues”, and why stakeholders are angry.
What good requirements actually look like
Good requirements are boring. That is the point. They answer:
Who is this for?
What problem are we solving?
What does success look like?
What are the non-goals?
What does “done” look like?
If you cannot test it, you cannot call it “done”. “Done” is not “It seems fine on my machine”. “Done” is “A non-technical person can use it and the thing does what the requirement said it would do”.
The manager’s job: force clarity
You do not need to write the requirements. You need to stop accepting fog.
If someone hands you a vague goal, push back until it turns into something you can build and validate. Yes, this can be uncomfortable. That is why you get the manager salary.
Here are a few questions that work suspiciously well:
What decision is this feature meant to change?
What user behaviour are we trying to create or reduce?
What is the smallest version that proves this is worth doing?
What does success look like in a screenshot?
What does failure look like in a support ticket?
If the answer is “We will know it when we see it”, congratulations. You have discovered a requirements problem.
Acceptance criteria: the underrated adult supervision
One of the easiest ways to stop shipping chaos is to write acceptance criteria. Not a novel. Just enough specificity that you can test it. You can use Given, When, Then if you want. You can use plain English if you are a normal person.
Example:
Given a user with no existing projects
When they click “Create project” and enter a name
Then the project appears in the list and can be opened
Notice what is missing:
“Should be intuitive”
“Should feel modern”
“Should be easy”
Those are design goals. They are not requirements.
“On time” is a planning loop, not a motivational speech
Most missed deadlines are not caused by laziness. They are caused by pretending the calendar will respect optimism.
The fastest way to miss a date is:
plan once
never revisit the plan
hope nothing changes
Spoiler: things change, and your plan needs to change with them.
The dirty secret: most timelines are negotiated fantasies
A lot of deadlines are not dates. They are wishful thinking.
A senior leader wants a thing by the end of the quarter. Product nods. Engineering nods. Nobody breaks it down, talks about dependencies, or checks capacity. Then three months later everyone is angy.
If your timeline begins with “We need is by X”, and does not include “Here is what we are cutting to make X possible”, you are not planning. You are roleplaying.
What planning that works looks like
It is not fancy. It is a loop:
break work into slices that can ship in days, not months
estimate based on past throughput, not confidence
surface dependencies early
scheduled decision points
re-scope when reality shows up
You do not need perfect estimates. You need fast feedback and honest replanning.
“Just add more people” is how managers announce they do not understand delivery
Adding more people to a late project often slows it down, because onboarding is work, coordination is work, and communication is work.
If you are going to add people, do it early, or do it to reduce load elsewhere. Do not do it as a panic response to a deadline you did no plan for.
The manager’s job: manage risk, do not punish variance
If a delivery date slips, the question is not “Why are you behind?” The question is:
What did we learn late?
What did we assume?
What decision did we not get?
What scope grew?
Then fix the system. If your response is punishment, you train people to hide problems. Now you have a delivery problem. Worse, you have a trust problem.
“Under budget” is mostly about tradeoffs
Budgets get blown because scope grows, context switching explodes, and rework becomes the default. Managers do not control budgets by nagging. Managers control budgets by making tradeoffs early.
The hidden budget killer: starting too much
If one team is running five projects, you are not ambitious. You are expensive.
Context switching is a tax. Partial work is inventory. Inventory rots.
Pick fewer things. Finish them. Stop collecting half-built features like trophies.
The second killer: rework from late feedback
Rework happens. But rework caused by unclear requirements and late discovery is the kind that makes people quit.
Reduce it by:
demoing early
shipping small
involving real users
testing against explicit acceptance criteria
The third killer: quality debt disguised as speed
Nothing destroys budgets like shipping junk and then paying for it forever. You pay in:
support load
on-call
emergency patches
lost customer trust
developer morale
If your “fast” delivery strategy is “ship it and fix it later”, you are not moving fast. You are moving debt around.
How managers sabotage shipping (usually by accident)
Here are some classics:
They accept vague goals
If you cannot answer “How will we know this worked?” you are not ready to build.
They do not protect focus
Every urgent interrupt is a choice. If you keep choosing interrupts, you are choosing missed deadlines.
The do no make decisions
Teams get stuck waiting for:
priority calls
scope cuts
product direction
sign-offs
If decisions take week, delivery takes months.
They reward heroics
If the only time people get praised is when they work nights and weekends, you are building a system that can only ship via burnout. You will also get the fun side effect where people stop raising issues early.
Because the culture has taught them that the correct strategy is:
say nothing
suffer quietly
become a hero
quit six months later
Excellent work, everyone.
They treat quality as optional
Quality is not a phase. It is part of working.
If you ship bugs and call it speed, you are not fast. You are borrowing time at a brutal interest rate.
What managers should do this week (without turning it into a whole framework)
You do not need a laminated process. You need to stop letting shipping be optional.
Try this:
Pick one thing that must ship in the next 7 days.
Write acceptance criteria a non-technical stakeholder could read.
Cut scope until it feels almost insulting.
Demo it mid-week.
Decide what you are cutting the moment anything slips.
The goal is not perfection. The goal is momentum.
And yes, this will feel uncomfortable, because it forces you to trade off nice-to-have work. It forces you to say no to someone important. It forces you to admit you cannot do everything. That discomfort is your job.
If you are already behind
Do not panic-reorg. Do not start a three-week “war room” that produces a deck. Do this instead:
freeze scope for the next 2 weeks
pick one shippable slice
demo it to a real stakeholder
cut anything that does not move the needle
Then repeat. Momentum beats motivation.
The uncomfortable ending
If you are a manager and you team is not shipping, you probably do not need a new tool.
You need:
clear requirements
fewer priorities
faster decisions
smaller slices
honest tradeoffs
That' is the job. Not wishful thinking. Not theatre.
If you want one question to ask yourself this week:
What is the smallest things we can ship that proves we are solving the right problem?