What Ownership Is¶

What is it?¶

Software engineers & organizations compete in the market of problem solvers. The software you write is your product, but your ownership is about the problems you solve.

So your ownership of a problem space is at risk if:

Your solutions can't be found by customers or don't solve their problems.
You aren't investing enough, or in the right ways, to keep up with competition.
Your solutions' design is too rigid to keep up with the problem space over time.
Your solutions have excessive costs relative to other potential solutions.

NOTE: This definition is compatible with Amazon & Meta concepts of ownership. Both say "there is no such thing as someone else's problem", and that's to ensure good ideas don't go to waste. Said differently, it promotes competition and combats stagnation.

When is this Useful?¶

Ownership is a framework that should inform all of your strategic decisions as a software engineer or engineering organization. If you don't have enough information to assess your ownership of a problem space, then you are not prepared to own a solution for it.

In a low-opportunity market, you should seek an alternate problem space to solve. In a high-opportunity market, you should seek to own an increasing share of the problem space.

Evaluating a Market¶

You should consider the following when evaluating a market (problem space):

The market is empty / has no solutions.
- Customer need might be low, implying very little opportunity.
- This might be a "deep" problem, requiring steady, long-term investment but which could yield rapidly growing returns.
- You might (although unlikely) be the first to identify a high-value problem space.
The market is dominated by a few mature solutions
- Consider improving on the existing solution, to increase your ownership over time.
The market is crowded with providers.
- Consider entering only if you have a strong differentiating factor.

Evaluating Individual Solutions¶

You should consider the following criteria for each solution in the market:

Can/do the customers find it?
How well does it solve the customer's problem?
Does it solve the whole problem space, or focus on a narrow area?
Is someone strongly in charge? (evaluate based on investment and quality of leadership)
Are enough people working on it?
Is the problem space shifting, and can the solution keep up?

Guideline¶

Outcomes over Output: Don't just ship code; solve the problem better than the alternative. If you ship a feature but nobody uses it, you have failed to compete.
Know Your Customer: You cannot own a problem space if you don't understand the people having the problem. Talk to them, measure their usage, and anticipate their needs.
Invest Wisely: Your time and resources are your capital. Spend them on high-leverage activities that increase the value of your solution. Don't waste capital on low-value toil.
No "Not My Job": In a competitive market, ignoring a problem in your domain is ceding ground. If you see a broken window, fix it, or you devalue your own product.
Adapt or Die: The problem space will change. If your solution is too rigid to adapt, you will be replaced by a more agile competitor (which might be a new team, a new tool, or a refactor).
Lifecycle Responsibility: You own the solution from design to deprecation. Abandoning a system while it's still in use is a failure of ownership and a breach of trust with your customers.