Ownership

We take ownership of our work. We think long-term and bias toward long-term value over short-term results. We act on behalf of the entire company, beyond just our own team.

Back to the universal principles

Under, just right, over.

SituationUnderJust RightOver
Covering work before time offLeaves 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 ticketMarks 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 stickShips 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 threadWatches 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 launchTreats 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 workNotices 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 interfaceChanges 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 madeTells 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.

Sources and essays on this principle.

See something wrong or missing? Fix it in Facet.