Ownership

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

Back to the universal principles

Why it matters

What this principle is for.

Renters pay the bills and call someone when something breaks. Owners fix the problem, or they bring in an expert and stay until the work is done to a high standard.

You own what you own. You take responsibility for your area, you own your mistakes, and you deliver on your commitments. You do not put a bucket under a leak. You find the leak and seal it, even if that means replacing the roof.

You also own what you do not own. You speak up when you see a problem outside your area, and you do not let go until someone capable is on it. "It is not my fault" is almost never an acceptable answer. You own your dependencies.

You own the future. You examine whether today's foundations can support growth. You make the long-term call even when the short-term call is easier and more popular.

In some ways Ownership is the other principles applied. Customer Obsession tells you what is worth owning. Deliver Results is what ownership looks like when the date arrives. Have Backbone; Disagree and Commit is how you fight for the long-term fix when it is unpopular.

Calibration

Under, just right, over.

Look for what someone did when the work sat outside their job description, and what they did when a dependency failed. "I flagged it" is not ownership. Neither is taking over someone else's area so you can be the hero.

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.

Examples

What it looks like in the work.

The leaky roof

A renter puts a bucket under the drip. An owner finds the leak and seals it, even if that means replacing the roof. Look for which one they did when a tactical fix would have made this quarter look fine and next year worse.

The silent dependency

Another team missed a date that your launch needed. A status update that blames them is under. Rewriting their plan for them is over. Just right is following up, escalating, offering help, and still treating the customer outcome as yours. That is owning a dependency, not taking over their team.

Give it to a better owner

You built a tool. Another team would serve customers better if they ran it. Owners inventory what they have and can give it away. Hoarders call that a threat. Look for a time they let go because the customer got a better owner, not because they were tired of the work.

In the role

Individual and manager.

Individual

You pick up work that is languishing. You do not wait to be assigned the unowned gap. When you miss, you say so early and stay on the hook. You document what you know so the next owner is not starting from zero.

Manager

You make the long-term call when it costs your team this quarter. You do not let "not my org" be the end of a customer problem. You build the relationships and the regular checks so dependencies do not become surprises, and you export ownership instead of collecting it.

Go deeper

Questions that make the principle concrete.

When is the last time you picked up something languishing that would not have happened without you?
What did you do the last time a dependency failed to deliver to you?
What have you given away because another owner would be better for the customer?
When did you sacrifice a short-term result for long-term value, and what did it cost you?
Do you measure your work in effort exerted or in value delivered?
What problem sits outside your area right now, and what have you done to make sure it is owned?
How do you share what you invent so other teams can use it?
When you dropped the ball, how early did you say so, and what did you do next?
Are you doing something easy today that will cause a customer or another team a problem tomorrow?

Sources and essays on this principle.

Ownership
Owners do not say that is not my job, and they do not stop at their team's scoreboard.
kindel.com
How We Scaled Alexa: One Problem, One Leader
One owner for one problem. That is how you scale without the work becoming nobody's.
kindel.com
Working Backwards, the book by Colin Bryar and Bill Carr
The single-threaded leader chapter. One leader, one problem, and nothing else competing for their day.
macmillan.com

Principles that sit next to this one.

Principles lean on each other, and some pull against each other on purpose (the tension is intentional). Here is how Ownership connects to the rest of the set.