Ownership Needs Authority

Consider an engineer asked to own a migration. They can write the code, but cannot change the sequence, negotiate with dependent teams, reserve time for rehearsal, or postpone the release. Those decisions belong to four different people. The engineer can report the status. Whether they can actually own the migration is less clear.

Ownership becomes useful when a person can connect a desired outcome to the decisions that shape it. Giving someone a name on a plan is easy. Giving them enough authority to make the plan work requires more care.

Start with the decisions

Before assigning an owner, write down the decisions the work will require. Be specific enough to expose the difficult ones. “Technical decisions” is a wide and unhelpful boundary. “Choose the migration sequence within the agreed outage limit” tells someone what they can do.

For an illustrative migration, the owner might be able to select the first service, choose the implementation approach, allocate the agreed engineering time, and stop a rehearsal that exceeds the recovery threshold. Changes to customer commitments, additional spending, or broader access to sensitive data might need approval elsewhere.

That arrangement can work. The owner does not need unlimited power. They need a workable area of control and a reliable way to resolve decisions outside it.

Ask what happens at a boundary. Who decides? What information do they need? How quickly must they respond? What is the default while the answer is pending? A dependency on an unspecified meeting next month is part of the delivery plan, whether anyone writes it down or not.

Agree on the constraints together

Constraints are easier to respect when their purpose is understood. An outage limit may protect a customer operation. A spending limit may preserve capacity for another commitment. A security review may cover a consequence the delivery team cannot responsibly accept alone.

Explain those reasons. Invite the owner to challenge whether the current constraints are compatible with the desired outcome. If they are not, resolve the conflict before work begins. Otherwise, the assignment quietly asks someone to choose which promise to break.

This conversation should include acceptance evidence. An owner cannot make sensible trade-offs if success means “complete the plan” to one person and “improve the customer workflow” to another. Name the behavior that must be dependable, the uncertainty being tested, and the point at which the investment will be reviewed.

Keep ownership connected to contributors

A named owner does not make everyone else a pair of hands. Design, operations, quality, security, and other disciplines may understand consequences the owner has not seen. They need meaningful ways to shape the work while decisions remain changeable.

Distinguish consultation from permission. A security specialist may advise on a proportionate control while a designated authority approves an exception. A designer may challenge the workflow while the initiative owner decides how to bound the first pilot. Treating every contributor as an approver can make the owner powerless again.

Write down the few decisions where agreement is genuinely required. For the rest, specify who should be consulted and who makes the call after hearing them. People can disagree with a decision and still understand how it was made.

Review the arrangement when it fails

When delivery stalls, examine the assignment before judging the person. Could the owner obtain the necessary access? Were dependent teams aware of the commitment? Did someone repeatedly reverse decisions from outside the agreed process? Did the owner surface a constraint early enough to address it?

Accountability includes the owner’s conduct. It also includes the conditions leadership created. Both deserve specific examination.

For the next piece of work you assign, complete three sentences with the proposed owner: “You can decide…”, “You need agreement before…”, and “If we cannot resolve a boundary, we will…”. Then test those sentences against one awkward but plausible situation. If neither of you knows what happens, the assignment needs another conversation before it needs a deadline.