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 |
|---|
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