What Is Missing When We Ask People to Take Ownership

Ownership is a word I think about a lot while running a small company. I want to work with people who spot the problem that needs solving without waiting to be told, and who carry a piece of work all the way to the end. If every judgment still has to pass through the founder as the team grows, the ceiling on what the company can do arrives fast.

But the more ownership I expect, the more a question comes back to me. What exactly did I hand over, and how far did I let people decide? When a result missed my expectation, had I explained the criteria from the start? The sentence "please take ownership" usually leaves out that first half.

Why is "please improve this page" not a sufficient request?

Because the same request can produce two different deliverables. "Improve this page" might mean make the design cleaner, or it might mean help the user find what they need to approve faster. Those two goals produce different screens. If the person asking had the second in mind and got the first, it is hard to explain the gap purely as a failure of understanding on the other side.

After running into this, I changed the order in which we work on product screens. For each page we first write down why a user arrives there, the single most important question on that screen, and the action we expect. "Make this screen good" gives far less to work with than "the user must be able to check the readiness of this release and decide whether to approve it." With that one sentence, the person building the screen can decide on their own what to make prominent and what to fold away.

What conditions make ownership possible?

Four things have to be shared: the problem to solve, the range of choices available, the criteria for checking the result, and a path for asking for help when stuck. With that much in place, a person can make their own choices and explain them to others.

The one most often missing is the second. The range of choices.

Can structure and copy be changed freely, while permission policy needs a joint review? Between schedule and scope, which one can be adjusted? When boundaries that look trivial stay vague, people either postpone decisions or make them and then reverse them. Stating the boundary out loud takes five minutes. The rework caused by its absence takes days.

What should a leader explain when priorities change?

What changed, and which assumption behind the earlier decision no longer holds. Adjusting priorities after learning something new from a customer is necessary and normal in a small company. The problem is never the adjustment itself. It is the explanation being skipped. If a criterion that changed because of new information gets applied as though it had been obvious all along, people start expecting hidden criteria next time too. From that moment they stop judging and start reading the room.

This is also why I care less about the length of a document than about whether it carries what a decision needs: the problem being solved right now, the scope of this round, the definition of done, and the questions still open. The goal is not to fix everything in advance. It is to stop people from spending time guessing at what is already decided, so they can focus on the part that is actually theirs to judge.

What responsibility comes with autonomy?

Accounting for the result. Explaining the goal and granting authority does not solve everything on its own. The person doing the work is responsible for sharing progress, verifying what they promised, and flagging risk early. Building or learning the skills the work requires is part of that too. Autonomy is not doing as you please. It is working while leaving a trail of the reasoning behind each judgment.

The habit a leader wants to build has to be explicit as well. If only the people who show up with a finished answer after the problem has grown get recognized, surfacing uncertainty early becomes a losing move. The team needs the experience of bringing an unresolved question with its impact and options laid out, and finding that this is enough to decide together. That is what lets ownership and collaboration move in the same direction.

Anyone looking at many parts of a product at once will tend to expect results without having passed on the context in their head. So before I ask the team for ownership, I turn the sentence on myself. What do I have to provide so that this person can judge? Problem, range, criteria, path. I check that those four are written down, and then I send the request.

In the organization I want to build, nobody needs to get good at guessing the founder's taste. They need to understand the customer's problem, decide within shared criteria, and review the outcome together. "Please take ownership" is only a complete sentence when it travels with the work of creating those conditions.