Ownership explained for Engineers and Managers
Introduction
Ability to take ownership is critical for the majority of careers. For me, as a manager, how people handle ownership and with what level of ambiguity is one of the clear distinctions between senior and junior positions. And to explain my understanding of ambiguity - it’s not only engineering complexity; high ambiguity might mean that no one did this before at the company, that the potential risks are very big or that we don’t have strong hypothesis and will need to adjust product very quickly during this project. Ambiguity is about much, much more than just engineering.
You might ask why ownership is important? It’s a powerful trait of high performing teams when people trust each other that problems will be solved and value will be delivered. As a team member, you can trust others and focus on your area of ownership. As a manager, you can delegate in a predictable manner and trust that the work is going to get done. Ownership is one of the most critical traits to scale your organisation. Problems and projects that you own may vary in size depending on where you are in your career - from fixing a bug, through improving our infrastructure of feature X, to shipping a new release of our whole product.
However, ownership is an ambiguous word. It can be hard to draw lines around good ownership. It’s not a result; it’s a behaviour that can drive results. A few months ago, I read Thinking in Systems, and over the last couple of weeks, I was trying to flesh out how I understand ownership and what does ownership, that is most valuable for my team and organisation, look like.
Low-impact ownership.
The most simple, but low-impact ownership is about solving a problem and bringing it to completion. If we manage to deliver value, the work we have done is net additive. You need to balance opportunity cost, but assuming that you identified a proper problem, it’s good for the team and the organisation. In such a world, a model of ownership is straightforward. We start with a problem and execute to solve it.
However, if you follow the presented model, there is a considerable amount happening in the background that you are not helping. Your teammates and your manager might not know how the work is going. They don’t have visibility into your work and can’t learn from that or teach you. They might get confused or even disagree with how you executed. Maybe you made some assumptions or decisions that people don’t agree with.
In low-ambiguity situations, an approach like that usually delivers results. You do your job, without getting anyone in and the problem gets solved. Everyone is almost unconsciously on the same page. The problem usually is simple, and the stakes are low. Take note though that it is not building trust in a team. Especially if you are a new member of a team, without a proper feedback loop you won’t earn and build trust as fast as possible.
If the stakes are high or the ambiguity of the problem is massive, in any of the above situations someone will step in - be it at least Senior Engineer or Engineering Manager. It will visibly decrease your level of ownership immediately.
One of the most common examples where such model fails is when ambiguity is clearly not technical. In low-impact ownership, there is no space for collaboration. We assume that everyone else did their job right and now we own our part and crack on. What if product questions are still open? What if designs are not ready and probably won’t be in the next few days? What if your marketing team still didn’t decide how to package what you are working on and thus it might be contradictory to your solution? In all these cases, this model will fail. And to be honest, most of your work is even more complex than you realise and questions like these usually are true.
High-impact ownership.
High-impact ownership is what I am personally looking for in my team. This type of ownership is the “Aha! moment” you want to see in your team members.
Ownership for me is all about communication and resolving ambiguity and risks on time. It all starts similarly, but the execution is part of a virtuous circle that brings everyone on the same page and fuels your team’s collaboration and growth.
When you start working on a problem and want to show a good level of ownership, you enter a virtuous circle that you will need to repeat multiple times before actually delivering final value.
-
Getting alignment.
It starts from getting alignment. In the first iteration, it’s about getting alignment with your team and manager that you start working on that, what are next steps and who needs to be involved.
-
Manage risks.
In the next step, you manage your risks. What are the most significant unknowns in the project currently? What are the risks? How can you mitigate them? How can you resolve answer missing questions?
Managing risks phase is the place where you think outside of the engineer-box. What are your risks, dependencies and ambiguities across other teams? Are you sure that all product and design questions are answered? Do you 100% agree that it’s the best way to go? Do you think you need confirmation from your Marketing Director? If it’s not you asking these questions, it’s not you owning the problem.
-
Execution.
Later you execute. You do this on your own or by delegation. It doesn’t matter who is executing. Ownership belongs to the person that will take responsibility for the failure of the whole project and the majority of things in your software are much more complicated than one person can handle.
A classic example of delegation is when you own and plan a project that consists of multiple engineers. But if you reflect on “Manage risks” section, you can also delegate areas such as product or marketing. “Manage risks” is the moment when you flag to your Product Manager “Hey, we need packaging decisions by Friday, or we will need to stop engineering, can you take care of it?”.
-
Managing up.
Last, you manage up to your manager and your teammates what you (or you and the people you delegated to) achieved, what progress was made and how the risks look like. It’s your time to get feedback, regroup and attack the circle once again.
Don’t skip any of these steps when iterating. Every week sounds like a reasonable interval to get alignment with your team on what’s happening and how we approach it as a team. It’s also an excellent interval to manage up the progress and get some feedback from your manager. It’s a little bit too often for risks management usually, but going through that will help you make sure you are on the right path too.
Summary
The model of high-impact ownership is handy for me as an engineering manager. It helps me explain and set expectations for our projects. I use it quite often when setting goals for my team of engineers to make sure that we are on the same page. Of course, there are multiple ways to manage people and help them grow in their ownership skills. It varies between mentoring and coaching all the time, and it’s a two-sided lesson for both manager and IC.
When you think about ownership, think about these four activities repeated in a circle. If you are not doing some of them, there is a step up in your ownership, and you should do it.
