“Taking ownership” is a pretty common engineering leadership buzzword.
- “I loved how X really owned that problem”
- “I wish Y would show ownership during that incident instead of blaming others”
- “How do we teach the new hire to take ownership of Z?”
As consultants we see this often in client environments. A lack of ownership is a common gripe with underperforming teams, and showing ownership is often a standout property of high-performing teams.
It’s not uncommon for leaders to simply tell the team to “take ownership”, and repeat telling them until success. In my experience, this has, shall we say, varied success rates. Sometimes it “just works”, sometimes nothing changes.
But why only sometimes? What influences a team feeling they can take ownership?
Let’s take a look into some of the factors that can influence a team, and what changes can be made to help a team achieve ownership.
Enrolling engineers with empowerment
General rule of thumb: it’s really hard to feel accountable for something you have no control over.
The more control you have, both the more you feel empowered to “fix” problems, and the more invested you are when you’ve committed time and energy into a system.
For example: if a team inherits a system, and told not to change it, but to “own it”, they are unlikely to do so. This unfortunately tends to breed resentment for whoever gave them the system (the original authors of the system), and overall isn’t a great state to be in.
By contrast, if they are empowered to make changes to the system, that time commitment will both teach the engineers how it works, and allow them to invest in the system.
Encourage them to investigate, perhaps speak to the original authors if they’re available, and raise tech-debt cards if things need fixing. As those cards get raised, make sure the engineers are given some portion of time to act on them. Again, this is a time commitment, and a display that the new owners have a say over how the system should work, how it should be monitored, tested, etc. Trust.
When incidents occur, allow your team to do the proper analysis, and fix the root cause if possible. If not, at least let them take the time to understand the problem, and take any mitigation steps they decide on. Postmortem culture can be a great guide in this particular area.
All of these build ownership, and the more a team feels they understand and control the system they own, the more they can feel responsible for it.
Take fate into your own hands
“When a leader takes too much ownership, there is no ownership left for the team or subordinate leaders to take. So the team loses initiative, they lose momentum, they won't make any decision, they just sit around and wait to be told what to do."
If a team is handed designs, whether they are architectural, user experience, or new features, and they have no say in the matter, they may feel resentment. This is sometimes unavoidable, and can be mitigated by communicating the why and other such techniques, but the more often it happens, the worse it gets.
Ideally, you want the team that will support the system to design the system. Sometimes that’s impractical, but, ideally they have at least a say in the matter.
For example, engineering architecture. Its not uncommon when interviewing engineers to get them to do “whiteboard designs” of systems. Engineers are specialists at engineering, so, let them architect new features.
Sure, let other parties have input, but let the design stay “theirs”. They will be a lot happier to work through faults in their own design, than a design handed to them. They will also understand their design better, and it’s a great opportunity for personal development.
This is something to apply across the board. However, as you move away from the engineering specialty, it makes sense to ease off the ownership proportionally.
Another example is in user experience designs. The engineers will need to own it (they will be on call for it, after all), but the designers are the specialists. So, both should have a say, and, ideally, a compromise will be found. If designers are just kicking designs over the fence to engineering, engineers will struggle to build ownership. If engineers are ignoring the designers’ designs, the designers will struggle to build ownership. Both need to own this, so they both need a say.
Diffusion of responsibility
Last rule of thumb (I promise): if a group of people are responsible for one thing, each of them will assume the others should be dealing with it.
It’s a concept called diffusion of responsibility.This is a great article that shares insights of working in Go take a read, it’s critical to understand when working with inter-team dynamics, as invariably, teams must share ownership.
However, some systems require shared ownership. Whether these are monolithic systems (frontends are often in this boat), or shared systems (common with shared services or libraries), systems that require shared ownership will show up, and these systems will need support and ownership.
There are several ways to manage these systems, however the technique I’ll cover is generally called “custodianship”.
Making a single team the “custodians” of a system can be a way to focus ownership onto a certain team. The custodians are expected to support and uplift “common good” elements of the system, while other teams are expected to contribute towards the system, while respecting the custodians as the owners. It can be helpful to detail a “charter” or similar guide to define these responsibilities clearly, that the teams can refer to when wondering who owns what.
However, as the custodians are expected to own the system, meaning, they will expect control.
This can be a good thing, as control helps manage quality and promote a sense of ownership. It can, however, frustrate other teams if the custodians become a bottleneck. Though stay mindfull of how this affects other teams if the custodians become a bottleneck, this might looks like tracking the sentiment towards the system.
In the worst cases, this can cause the shared service to become avoided or treated as a delivery risk, which can cause issues in other parts of the organization. Thus, it needs to be managed carefully, and sentiment towards the system needs to be tracked.
Shared systems are by far some of the hardest systems to own, and the easiest to dissolve into a mess, given inattention. Keep up communication with your team and discuss the challenges they currently face, and what support they need to combat them.
In summary:
Empower the team to invest in the system
Ensure the team are involved in (or directing) the future state of the system
Manage shared responsibilities clearly and precisely
These techniques are not exhaustive, promoting ownership is a subtle art, and will require a tailored approach for each team and hopefully these points will help you build ownership in your teams armed with these techniques, you can start on the journey, and I promise you: the rewards are worth the effort.