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 annexing 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 what is in flight, who can decide what, and the one case worth a ping. The team can move, and they actually rest. | Stays in the threads all week and redoes the backup's calls. The backup never owns it, and they return 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 outcome landed. If something remains, they name an owner for it before they close. | Leaves it open to chase extras that were never in the ask. Work behind it waits. |
| A workaround that will stick | Ships the patch and walks away. The next person hits the same hole with no note. | Ships the patch so the week is unblocked, then either schedules the real fix or writes why the patch is the answer. | 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 a more senior voice. | Posts a recommendation, who is hurt if they wait, and a time they will proceed if no one objects. | Calls it alone on something that binds other teams. The next days are spent 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 next start date moves. |
| Two teams started the same work | Notices the overlap and keeps building their version. Two answers land and one gets thrown out. | Stops, compares scope, and picks which team finishes. The other team's time goes back to their plan. | Takes both piles 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. | Names who consumes it, gives them a window, and keeps a path for old callers through this week. | Waits until every consumer has moved, including teams not using the field. 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. | Owns the next conversation. They confirm what was promised, what can actually ship, and who will say so. | 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. The under story is a status update that blames them. The over story is you rewriting their plan. The just-right story is you followed up, escalated, offered help, and still treated the customer outcome as yours. That is owning a dependency, not annexing a 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 audit mechanisms 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?
From the blog
Writing that goes deeper.
- Ownership
Owners do not say that is not my job, and they do not stop at their team's scoreboard.
- How We Scaled Alexa: One Problem, One Leader
One owner for one problem. That is how you scale without the work becoming nobody's.
Related