Drive Ownership

Every decision and deliverable needs one owner, and everyone should know who it is. The manager's job is to make that true and then protect it. Coordination failures (a decision made twice, a decision never made, a dependency three people each assumed someone else had) usually trace back to a missing name.

Appoint a DRI

Every initiative gets a directly responsible individual. Any technical person can hold the role. A senior engineer can be DRI on one initiative and not on another.

The DRI owns the spec, the estimate ranges and the schedule built from them, risk, progress updates, and delivery. Delivery is the load-bearing part: when it's late, the DRI explains why and what's changing.

Rotate it. When the most senior person gets it by default, they tend to become the bottleneck, and a junior DRI on a small initiative learns more in a quarter than in a year of tickets.

Push ambiguity to the front lines

One person gets a sprint goal for a product area. No ticket is perfectly specified, so that person resolves the ambiguity: they decide what the ticket meant, do that, and say so in the demo. This is mission command at sprint scale. The manager sets the intent, and whoever is closest to the information makes the call.

It only works if people make good calls unsupervised, which is why hiring screens for it first.

Make decisions stick

For anything cross-team or contentious, write one line: the decision, who owns it, who gets consulted, by when. Skip the RACI matrix (mostly ceremony). Without a named owner, the decision usually goes to whoever is loudest, or nobody makes it.

Once the owner decides, the disagreement is over. Say so out loud: "You've made your case. Sam owns this, and we're doing it Sam's way." Reopen only for new information or a one-way door.

Avoid overriding an owner. When a manager does, people tend to start checking with the manager before deciding anything, and the team ends up dependent on the manager instead of adding leverage to them. The opposite failure is treating ownership as territory. An owner is accountable for how their service performs, and anyone can still send it a PR.

Spot orphaned decisions

An orphaned decision looks like:

• The same design question in three consecutive planning meetings
• A 40-message Slack thread with no conclusion
• Two services implementing the same thing slightly differently
• "We should really decide about X," said by someone who could decide about X

Assign an owner. The decision usually gets made within a week, whichever way it goes.