There is a pattern that shows up in every growing company. Somewhere between 20 and 100 employees, a tool that was once clearly someone's responsibility becomes "the team's tool." Nobody specifically owns the Jira instance anymore. The AWS account is managed by "the engineering team." The company's Figma workspace belongs to "design."
This feels collaborative. It feels like shared responsibility. In practice, it is the beginning of an accountability vacuum that will cost you real money and real time.
The Tragedy of the Commons in IT
In 1968, ecologist Garrett Hardin described a phenomenon he called the tragedy of the commons: when a resource is shared by many people with no individual accountability, it gets neglected and eventually degraded. The same dynamic plays out with IT assets and software subscriptions in organizations every day.
When a SaaS tool belongs to "the team," predictable things happen:
- Nobody reviews the bill. The monthly charge lands on a shared credit card or department budget. Everyone assumes someone else is checking whether the plan level is right or whether all seats are in use.
- Nobody manages access. Former contractors still have accounts. Employees who switched teams still occupy paid seats. The admin panel has not been reviewed in months because it is not anyone's specific job.
- Nobody evaluates alternatives. The tool might have doubled its pricing or a better option might have emerged. But nobody is tasked with staying on top of it, so the status quo persists by default.
- Nobody handles the crisis. When the tool breaks, has a security incident, or requires an urgent update, there is a scramble to figure out who has admin access and who should make the call.
This is not theoretical. A 2024 survey by Productiv found that over 50% of SaaS licenses at mid-size companies are unmanaged, meaning no single individual is accountable for the subscription, its users, or its cost.
Why Shared Ownership Fails
The argument for shared ownership sounds reasonable on the surface. "If multiple people are responsible, we have redundancy. If one person is out, someone else can handle it." But in practice, shared ownership creates three specific failure modes:
Diffusion of responsibility. Social psychology has studied this extensively. When responsibility is shared among a group, each individual feels less personally accountable. This is the bystander effect applied to your IT stack. Everyone assumes someone else will handle the renewal, review the invoice, or clean up unused accounts.
Decision paralysis. When three people share ownership of a tool, who decides whether to upgrade, downgrade, or cancel? Who approves adding new users? Shared ownership introduces ambiguity into every decision, which means decisions get deferred or not made at all.
Accountability gaps during transitions. When the person who informally managed a shared-ownership tool leaves the company, the remaining "owners" often do not even realize they need to pick up the slack. The tool drifts into a fully unowned state without anyone noticing.
The One-Owner Principle
The fix is straightforward: every IT asset, software subscription, and tool in your organization should have exactly one designated owner. Not a team. Not a department. One person with a name.
This does not mean that person is the only one who uses the tool or the only one who can administer it. Ownership is about accountability, not exclusive access. The owner is the person who:
- Knows the current state. How many licenses are active? What plan are we on? When does it renew?
- Reviews the cost. Is the spend appropriate? Are we using what we are paying for?
- Manages access. Who has accounts? Do they still need them?
- Makes decisions. Should we upgrade, downgrade, switch, or cancel?
- Transfers responsibility. If they leave the company or change roles, they ensure someone else takes over before they step away.
This is the same principle that drives effective incident management. When an outage happens, you do not assign it to "the team." You assign an incident commander. One person coordinates, makes calls, and is accountable for resolution. Asset ownership works the same way.
How to Implement One-Owner Accountability
Rolling out the one-owner principle does not require a massive organizational change. Here is a practical approach that works for companies at any stage:
Start with an inventory. List every SaaS tool, IT asset, and software license your company uses. For companies in the 50-200 employee range, this list is typically 80-150 items long. Larger organizations often discover 200-400 or more.
Assign owners based on usage and authority. The owner should be someone who actually uses the tool and has the authority to make decisions about it. For department-specific tools, this is usually the department lead or a senior individual contributor. For company-wide platforms, it is often someone in IT or operations.
Document it in a central, accessible system. The ownership registry needs to live somewhere that is easy to update and easy to query. When someone leaves, you need to be able to instantly pull up everything they own. When finance asks who is responsible for a charge, you need to answer in seconds, not days. Tools like OwndUp are purpose-built for this, providing a central registry where every item has exactly one owner, with automatic renewal tracking and transfer workflows built in.
Build ownership transfer into your offboarding process. This is the most critical step. When an employee gives notice, every item they own must be reviewed and reassigned before their last day. No exceptions. Treat it with the same urgency as revoking system access.
Review ownership quarterly. People change roles. Teams reorganize. A quarterly review ensures that ownership records still reflect reality. This review should take 30-60 minutes and can prevent thousands of dollars in waste.
Common Objections and Honest Responses
"This creates single points of failure." Ownership does not mean only one person has access or knowledge. The owner can and should document how the tool is configured and ensure at least one other team member can administer it in a pinch. The point is that one person is accountable, not that one person is the only one who knows anything.
"We are too small for this." If your company has more than 10 people and more than 20 SaaS subscriptions, you are not too small. In fact, establishing this practice early is far easier than retrofitting it later. Companies that wait until they are at 200 employees to implement ownership tracking face months of cleanup work.
"Our team leads already handle this informally." Informal ownership is the most common and most dangerous pattern. It works until it does not. When the informal owner leaves, gets promoted, or simply forgets, there is no system to catch the gap. Formalizing what already happens informally takes minimal effort and provides significant protection.
"This is too much bureaucracy." Assigning an owner takes 10 seconds. Reviewing your ownership list quarterly takes an hour. Tracking down who is responsible for an unknown charge, recovering admin access to a tool nobody manages, or discovering 14 months of wasted subscription fees takes days. The overhead of the one-owner principle is trivially small compared to the cost of not having it.
The Ownership Mindset
Beyond the practical benefits of cost savings and operational efficiency, the one-owner principle establishes something more fundamental: a culture of accountability.
When every tool has an owner, people start thinking differently about software adoption. They do not sign up for free trials on a whim, because they know the tool will be tracked and they will be responsible for it. They evaluate new purchases more carefully because the cost is attached to their name. They stay on top of renewals because they know it is their job.
This is not about control or surveillance. It is about making sure that every dollar your company spends on software is a conscious, accountable decision made by a real person who understands the value being delivered.
The rule is simple: if nobody owns it, nobody manages it. If nobody manages it, you are paying for it anyway. Assign one owner to every tool in your stack, and you will immediately see the difference.