Ownership

Leaders are owners. They think long-term and don't sacrifice long-term value for short-term results. They act on behalf of the entire company, beyond just their own team, and never compromise safety. They never say, "that's not my job."

Back to the universal principles

Calibration

Under, just right, over.

Situation	Under	Just Right	Over
Covering work before time off	Leaves without a handoff. Open threads sit until they get back.	Writes down what is in progress, who can make which calls, and the one kind of problem worth texting them about. The team keeps moving, and they actually rest.	Stays on email and chat all week and overrides the calls their backup makes. The backup never really owns the work, and they come back already tired.
Closing the ticket	Marks it done when the code is merged. Does not check whether the person who needed it can finish the job.	Confirms the person who asked for it can actually use it. If something is left, they name an owner for it before they close the ticket.	Leaves it open to chase extras nobody asked for. The work queued behind it waits.
A workaround that will stick	Ships the patch and walks away. The next person hits the same problem and finds no note explaining it.	Ships the patch so people can keep working this week, then either schedules the real fix or writes down why the patch is good enough.	Holds the release for a full rewrite. People wait on a problem that already had a safe patch.
A stalled decision thread	Watches the thread and adds nothing. The week slips while people wait for someone more senior to weigh in.	Posts a recommendation, who gets hurt by waiting, and when they will go ahead if no one objects.	Makes the call alone on something that commits other teams. The next few days go to undoing it.
Leftovers after a launch	Treats launch day as the finish line. Docs, known bugs, and follow-ups have no name on them.	Before the team scatters, they list what is left, what can wait, and who takes each piece.	Will not call it launched until every leftover is gone. The start date for the next project moves.
Two teams started the same work	Notices the overlap and keeps building their version. Two versions get built and one gets thrown out.	Stops, compares scope, and picks which team finishes. The other team's time goes back to their plan.	Takes over both efforts and rebuilds a combined version so they can be the owner. Both teams lose the week they already spent.
Changing a shared interface	Changes it for their case and ships. Other teams find out when their work breaks.	Lists the teams that depend on it, gives them time to move, and keeps the old version working through this week.	Waits until every team that depends on it has moved, even teams that never use the field being changed. A small fix sits while their own users stay blocked.
A promise someone else made	Tells the customer it is not their promise. The customer is left with no next step.	Takes the next call with the customer. They confirm what was promised, what can actually ship, and who will tell the customer.	Honors a promise the team cannot keep so they look like the owner. Planned work for the week gets dropped.
A shortcut that touches a hazard	Takes the shortcut and leaves the hazard on someone else's checklist.	Names the hazard, refuses the shortcut, and escalates until a real owner has the risk.	Blocks every shortcut nearby, including ones that do not touch the hazard, and the work stops for no safety gain.
Schedule pressure on a safety check	Moves the check to after the date so the milestone still holds.	Keeps the check in front of the date, and holds the work if the check is not done.	Adds extra checks that do not cover the hazard, and the date slips with no safety gain.
A known risk about to go forward	Sends the work and plans to catch the risk later.	Holds that work until the risk is mitigated or explicitly accepted by the person who can accept it.	Holds unrelated work that has no named hazard, and calls the hold safety.
Cost pressure on a safety step	Cuts the step to save the cost and does not say what hazard that step covered.	Keeps the step when it is what makes the work safe, and looks for a cheaper way that still covers the same hazard.	Refuses every cheaper option, even one that covers the same hazard, and the cost becomes the reason nothing ships.
Someone else's checklist	Assumes the checklist owner will catch it, and does not look at the item their own work can make unsafe.	Checks the items their work can make unsafe, and leaves the rest with the owner.	Takes over the whole checklist and becomes the bottleneck for work they do not understand.
A hazard with no name	Says it feels unsafe and stops, without saying what could hurt someone.	Names the hazard, the consequence, and the smallest hold that covers it.	Keeps the hold after the hazard is named and covered, because stopping felt safer than deciding.
Skipping a safety step for convenience	Skips the step because it is inconvenient and the last few times were fine.	Does the step when skipping it would put a person or the hardware at risk, and drops a step that no longer covers a real hazard.	Keeps every old step, including ones that no longer match the hardware, and the team works around them.
Escalating a real risk	Mentions the risk once and goes back to the schedule.	Escalates until the risk has an owner and a next step, then returns to the work that is still safe to do.	Escalates every discomfort as a stop, and the people who own the real risks stop listening.

Further reading

Sources and essays on this principle.

Blue Origin Work Culture
The published wording of this principle.
blueorigin.com
About Blue Origin
The mission this principle is meant to serve.
blueorigin.com