Organizations often tell people to take ownership. The phrase appears in performance reviews, leadership meetings, and strategy documents. Someone is assigned to a project and told, “You own this.” It sounds clear enough. The ambiguity appears later, when the person who supposedly owns the work discovers that someone else controls the priorities, the budget, or a decision that materially changes the work. The person remains accountable, but the decisions belong elsewhere. That is not ownership. It is responsibility without authority.
Earlier in my career, I joined a company that had a solution deployed on customer machines. The company wanted to build a SaaS version of the product. I was told that I owned the initiative. The team and I wanted to continue using the existing technology because of its capabilities, but my boss directed us to use a free, open-source alternative. I later understood the financial reasoning: the company was experiencing revenue shortfalls, and the licensing expense mattered.
The decision was not necessarily wrong. I likely would have made the same decision given the context. The problem was that I had been told I owned the initiative while someone else retained authority over decisions that materially affected the outcome. I was responsible for the outcome, but I was not the owner of all the decisions that determined it. That distinction matters more than most organizations acknowledge.
A person can be responsible for executing work without owning the decisions that shape it. They can provide input, make recommendations, and remain accountable for an outcome while someone else retains the authority to act. Ownership and responsibility are related, but they are not interchangeable.
The difference is often invisible when everything is going well. It becomes obvious when the work encounters a meaningful tradeoff. Who decides when the budget is insufficient? Who decides when a deadline conflicts with the original scope? Who decides which requirements get deferred? Who decides when the team accepts additional risk? The person who owns the work should not necessarily make every one of those decisions. Strategic, financial, technical, and operational decisions may appropriately belong to different people. But the organization needs to be clear about who owns each decision.
Trust is often discussed as if it were primarily an attitude. Do leaders trust their employees? Do teams trust their managers? Do people feel trusted? Those questions matter, but trust also has an operational expression: What decisions is someone actually allowed to make?
A person can be told that they are trusted while every meaningful decision still requires approval. They can be encouraged to take ownership while being expected to ask permission before acting. They can be held accountable for outcomes while lacking the authority to make the tradeoffs required to achieve them. The operating model is often a more accurate expression of organizational trust than the language used to describe it.
This is how organizations gradually create friction. A control is added, an approval is introduced, or a committee is created for valid reasons. Over time, the organization arrives at a place where capable people are expected to own outcomes but are no longer trusted to make the decisions required to produce them. The organization may never explicitly decide that its people are untrustworthy. Its operating model simply assumes that they cannot be trusted.
There is another side to this argument. Giving someone authority does not guarantee that they will make a good decision. As a leader, I once gave a senior developer a small project with the authority to work with the PMO and build what had been agreed upon. His status updates looked good.
On the day the project was scheduled for deployment, he unexpectedly quit. When I picked up the work and reviewed what had been built, I discovered that the product did not meet the original intent of the business. The requirements document and test scripts matched what had been built, but the underlying business outcome had not been met. My boss told me to deploy it anyway. Technically, the documented requirements had been satisfied.
That experience taught me two lessons. First, the organization was measuring delivery more carefully than value. Second, status reports do not always tell the real story. I still do not believe the decision to give that developer authority was wrong. The problem was not that I trusted someone. It was that I misjudged where that trust belonged.
That distinction matters. The answer to a bad decision is not automatically to remove decision authority from everyone else. Nor is the answer to create enough reporting that every decision requires a committee. Trust requires judgment. It also requires attention to outcomes. A project can meet its documented requirements and still fail to deliver what the user actually needed. The outputs can look complete while the intended value remains absent.
The next time someone is told to “take ownership,” the most useful question may not be whether that person is sufficiently motivated. It may be: “What decisions are they actually authorized to make?” If the answer is unclear, ownership is unclear. If every meaningful decision requires someone else’s permission, the person may be responsible for the outcome without actually owning it.
The next time your organization asks someone to take more ownership, examine the permission structure around the work. If they cannot make the decisions that materially determine the outcome, they do not fully own the outcome. They may simply be carrying responsibility for someone else’s decisions.