A Guide to Owning Instead of Helping
Helping others is great, but it doesn't hold a candle to owning things. I walk through ownership vs helping, and why your kids are bad at doing the dishes.
What's a common complaint from junior employees who were let go? You can easily read those quotes on Reddit or Blind.
"I did everything they told me to do!"
"No one told me to do more!"
"I did it exactly as I was asked!"
This screams a lack of ownership. An employee expecting to be a told what to do, is an employee adding little value. You're just helping, not owning.
What does helping mean?
Someone else needed to describe the problem, and come up with the solution. You implement it, and likely someone else validates that you did it the way they wanted.
This is the classic new engineer challenge. They say that they finished their sprint tasks. "What should I do next?"
If you expect your manager to find you work, and tell you what to do, you're a drain on resources. You're exhausting to manage. You're only doing a small portion of the actual job. The queue and priority of work that needs doing (project queue, operational queue) is still owned by your manager or senior co-workers.
At home, this can be the classic situation where wives need to ask their husbands to do the dishes, or bring the dirty laundry to the laundry room. I'm certainly guilty of it. There's a great cartoon talking about this situation at home. In this case, the wife is owning the home maintenance. The husband only owns the execution. Owning the entire home is mentally exhausting.
To provide true value to your spouse or co-workers, what's the answer? You need to demonstrate full ownership.
What does ownership mean?
It means owning an area fully. An area is a definable scope of ownership which allows others to recognize where your ownership boundaries begin and end.
The scope of an area can be large or small. You could own a website, or a specific function of a website, or the latency of a specific function on a website. The key is that you can look at anything, and identify who the owner is.
At a company, you often have nested ownership. Some VP owns a business, a Director owns the website for that business, a Senior Manager owns a set of functions on the website, a manager may own a single function, and an engineer on their team may own a project for rebuilding the data storage.
In these cases, the overall ownership is split up. Somewhat like a pie. And just like a pie, every piece needs to be eaten (owned). You should hopefully never end up in a situation where something is unowned. That's dangerous (because opportunities or problems may be entirely ignored), and a sign of a poor organizational structure.
In general, addressing a problem or opportunity should go to the lowest level of owner. Imagine a specific function of a website has become slow, and customers have started complaining. The head of customer service passes this information to the VP who owns the business.
The VP passes that to the Director, who passes it to their Senior Manager, who passes it to the manager in charge of that function. The manager may have an engineer who already specializes in performance, or they may ask (delegate to) an engineer on their team to own the performance issue. This chain of information passing and delegation is common, as funny as it sounds when written out.
At a higher level, you own the area, but have delegated all the aspects of ownership apart from your own audit quality bar. If you're the VP, and you're not happy with the performance of the website (even after your team said they fixed the problem), you'll pass that concern back down the chain.
Where does the chain of message passing end?