Growing Your Delivery & Operations

Delivery is getting it live safely and knowing it landed. Small PRs behind flags, instrumented and watched, mitigate before investigate. It is the half of the job that starts where “the code works” ends: a change is not done when it runs on your machine, it is done when you can prove it is correct, see it working in production, and know the instant it stops.

This page is how you move yourself up one rung on it. It is a mirror, not a scorecard: find the row just above where you sit, and put your reps there. The mechanics live in How We Ship, Prove It Works, and the Engineering group.

Where you are now#

Find the line that matches how your last few changes actually reached production.

Level	The tell
Intern	You ship a clearly-scoped task and are still learning the rollout flow.
Junior	You follow the release plan and cut small PRs when reminded.
Mid	Your PRs are small and behind flags, instrumented by default, and you confirm the thing is used.
Senior	You own the release end to end, mitigate before investigating, and nothing surprises anyone.
Lead	You set the team’s ship discipline and its mitigation playbook.

What moves you up#

Delivery climbs on shrinking the blast radius and raising the visibility of everything you release:

Ship small, behind a flag. A large change is a large bet placed all at once. Small PRs behind feature flags let you release the code and enable the behavior separately, and turn it off without a deploy when it misbehaves.
Instrument it as you build it, not after the incident. Add the one signal you would want at 2am while you are writing the change. If you cannot answer “is my thing working right now?” from a dashboard, you have not finished. See Observability.
Mitigate before you investigate. When something breaks, the first job is to stop the user being hurt: flip the flag, roll back, drain the queue. The root cause can wait until the bleeding stops. See Incidents.
Confirm it landed. Shipping is not the finish line; impact is. A change that deployed cleanly but did not move the number it was meant to move is a lesson, not a success.

The habits that keep you stuck#

Everyone has shipped a change they could not see and hoped for the best. It works until the one time it does not, silently, for 3% of users. Catch yourself here:

Bad: a 40-file PR that migrates the billing schema, changes the invoice UI, and adds a new export, merged Friday, no flag, no dashboard, verified by “it worked when I clicked through it.”

Good: the migration first, behind nothing user-facing; then the UI behind a flag enabled for the team only, with a chart of invoice-render errors; then the export, once the first two are quiet. Each reversible on its own.

The tells that your delivery is still a hope with a green checkmark:

“Works on my machine” as the end of the story rather than the start of it.
The big-bang PR that cannot be reviewed, cannot be flagged off, and cannot be rolled back cleanly.
No signal for the thing you shipped, so “no one complained” stands in for “it works.”
Reaching for the root cause during an incident while users are still being hurt.

The reps that level it up#

Move a rung by taking on the next row’s ownership before it feels comfortable, then close the gap with review:

Own one rollout end to end: the flag, the instrumentation, the enable sequence, and the check that it landed. Not the code alone, the whole path to live.
Add the signal before the feature works. Build the trace, metric, or log first, so you are watching the change come to life instead of inferring it did.
Cut your next change into the smallest shippable slices and release them one at a time. If you cannot slice it, that is the first problem to solve.
Walk through one real mitigation with someone who has run incidents: what you would flip, in what order, before you diagnose anything. Practice the reflex before you need it.

The one question#

For anything you have shipped, ask the four that separate code that runs from a system you can stand behind: is it correct (tests, including the edges), is it working right now (a signal you can point at), is it fast enough (a measurement, not a guess), and will I know when it breaks (an alert on what matters)?

If you can answer all four with evidence, you own it. If not, you shipped a hope.