The Transformative Nature of Ownership in Engineering Orgs

During my career, I’ve had the honor of observing and being part of tens of engineering teams as a consultant, IC and manager.

Obviously, not all of these teams were equally effective at reaching their goals: some worked like perfect machines, others fell apart at every little problem, and most of them were somewhere in between these two extremes.

One would be tempted to explain these performance differences through a mere gap in technical skills — simply put, some people are more skilled than others and get more done, faster. The theory here is that the more highly-skilled engineers you hire, the better your team will perform.

This is certainly true, at least to an extent. However, if you talk to a seasoned manager, you’ll find that they’ve dealt with these two types of engineers at least once during their career:

• A junior engineer who absolutely crushed it not just from a technical perspective, but also in terms of the impact they had on the organization.

• A very senior and skilled engineer who never managed to accomplish anything meaningful, and ultimately moved on or had to be let go.

Technical skill cannot always justify gaps in the performance of individuals or the teams they comprise. There must be a more important underlying factor, one that justifies such dramatic differences in the impact people have on an organization, beyond their direct knowledge of the technologies and tools they work with. When present, this factor leads people to overcome their technical limitations in order to be effective at their job. When absent, it discourages them from pursuing meaningful results, no matter their skill.

Lately, I’ve come to realize the root factor may be ownership.

An Intrinsic Trait with Extrinsic Results

Ownership is an intrinsic trait with extrinsic results: it’s born inside you, but most of the good things it leads to happen outside of you, in your interactions with others.

Intrinsically, ownership is a sense of belonging and pride in one’s efforts that ultimately leads to the pursuit of excellence. People who have ownership genuinely care about everything they do because they have the ability to see the value in it, even when it’s not obvious. Because of this love, they are willing to do the right thing.

Extrinsically, ownership is the collection of traits that give managers peace of mind: people who have ownership are dependable and consistent; they don’t wait for someone to assign work to them, but autonomously pick the thing that will have the most impact; they are in touch with the company’s mission; they work to the best of their abilities; they remove blockers from their way; they are not afraid to roll up their sleeves and fix something that’s broken, even when it’s not supposed to be their concern; they constantly re-evaluate and improve their way of working.

Most importantly, ownership is contagious, and it spreads very quickly: while technical skills take years or even decades to truly master, it only takes a few weeks of working in a team that consistently exhibits ownership for a new person to get up to speed on what’s expected of them. This is probably because we all have a natural sense of ownership and can recognize it and appreciate it in others when we see it.

Ownership and Organization Design

In most mature organizations, there are at least three layers an individual is interacting with at any given time:

1. The craft (the “how”). When I am working, I am connected to the craft I am practicing to produce my work. An example is the relationship between an engineer and the code they write.

2. The team (the “what”). The code I write doesn’t exist in isolation (most likely), but is part of a larger endeavor my team is collectively working on. Together, we work on something bigger than ourselves.

3. The company (the “why”). Ideally, we don’t write code simply out of love for the code, but because we want to solve a problem we care about. Our company connects us all through its mission.

The three layers are also directly connected, and almost equivalent, to the three factors Daniel Pink identified in Drive:

• Ownership towards the craft corresponds to Mastery.

• Ownership towards the team corresponds to Autonomy.

• Ownership towards the company corresponds to Purpose.

In some organizations, ownership is experienced at all three layers: people love their craft, trust their team, and believe in their company. This perfect alignment creates the ideal environment for individuals to do their best work, and such an organization is bound to have an impact.

In other cases, there is a disconnection between these three layers. It’s important to note that, while the layers are connected to each other, the different levels of ownership people feel towards them may be completely independent of one another. Here are some examples:

• An organization whose members are deeply connected to the company’s mission, but completely uninterested in their craft.

• An organization that hires superstar employees by offering extremely generous compensation packages. In this case, employees will own their craft, but most likely not feel connected to the company.

• A dysfunctional organization that happens to have one or two very good teams in it. Their members are bound to feel a strong sense of ownership towards their team, but a very weak one towards their company (in extreme cases, people may favor their team while antagonizing their company).

Another important aspect is that the ways to foster ownership in these three layers are completely different. While ownership should be practiced first and foremost by the CEO, ultimately it’s up to the individuals who comprise the organization to find the best ways to implement ownership in their work.

Because the ways to foster ownership towards the company is largely independent of the type of company, and has been written about extensively already, and fostering ownership towards the craft is not something managers should be concerned with, let’s instead focus on how to foster ownership towards one’s team, especially in the context of an engineering organization.

Ownership and Cycle Time in Engineering Teams

In a team setting, the biggest obstacle to team members’ ownership comes in the form of bottlenecks. Bottlenecks are steps of the work process that require team members to wait for someone before they are able to move forward with their work. By removing responsibility from the person who is producing the work, they discourage that person from “owning” the work all the way to its completion.

In the average engineering team, bottlenecks come in many different shapes:

• Software engineers need to wait for a PM to define the next sprint and assign work to them before they can start working.

• Software engineers need to wait for a QA engineer to test their work before their work is approved for deployment.

• Software engineers need to wait for a release manager to follow a very long and complicated checklist before their work gets deployed.

Every single bottleneck reduces the ownership individual team members feel towards their team: QA engineers find bugs in the features they test, but these bugs are never fixed and the work lingers in a limbo forever; engineers sit on their hands all day because they don’t know what they’re supposed to work on next. This results in a very tangible increase in cycle time.

Unfortunately, engineering teams often don’t know a better way to do things. In fact, many of them will argue that the bottlenecks are necessary: we need the engineers to have their priorities clear before they work, because the priorities change too quickly. We need to do manual QA on our system, because our system is too complex to rely on automated tests alone. We need to handle deployments with care, because the cost of a mistake is too high.

I would agree with all of these objections: there are products where the priorities would change dramatically from one day to the next, there are enterprise systems that are too complex for automated tests to catch all the permutations of interactions and edge cases that would cause a bug, and there are applications where the cost of a bad deployment can be computed by multiplying the minutes of downtime by a factor of one thousand or more.

And yet, I would never ever advise such teams to strip their engineers of their responsibility and ownership to protect the business — not because I think the sacrifice isn’t worth it, but because there is a better way. One that empowers teams and makes them more productive, resulting in more value for the organization and a better use of the engineering budget.

A Practical Framework for Fostering Ownership

There are three activities paramount to building ownership in your team:

• Communicate: by communicating constantly with your team, you create alignment on the business priorities and expectations. Frequent and consistent communication gives your team the information they need to make decisions autonomously.

• Streamline: by streamlining processes, you empower everyone to follow them and make sure their work gets done. Note that streamlining doesn’t necessarily mean automating: while automating a process is the ultimate way to streamline it, proper documentation can also do wonders.

• Trust: ultimately, you need to trust your team to do the right thing. Most teams lack ownership because their managers don’t think their members can do the best interest of the organization without micromanagement. In the long-term, this lack of trust is a recipe for failure.

These three activities will take different shapes depending on the size and conformation of your team, but your end goal should always be to establish a framework for ownership and collaboration within the team. Everyone on your team should know not only what ownership means, but also how to exhibit it in their day-to-day work.

For example, here are some of the practices I have adopted over the years to foster ownership in the engineering teams I led:

• Enforce direct communication: when you’re a team lead, people have a tendency to go to you when they have a question, effectively turning you into a bottleneck and reducing their contact surface with the business. The next time someone approaches you with a question you can’t answer, encourage them to seek the answer by themselves. This may seem like you’re forfeiting responsibility, but what you’re actually doing is removing a bottleneck in the communication process.

• Take “done” to the extreme: most engineering teams don’t even have a definition of “done”, yet alone an extreme one. It should be clear that a feature is only finished once it’s been successfully deployed to production and used without problems by your users. Until then, the developer’s first priority should be to keep the feature moving through the development pipeline so that it gets done  — actually done.

• Turn bottlenecks into leverage: bottlenecks often come in the forms of individuals or teams who are responsible for keeping another team’s work moving forward. I’ve already made a couple of examples when I spoke about QA engineers and release managers. This kind of repetitive work alienates people and doesn’t add any value to your team — in fact, it slows them down. Instead, find ways to turn bottlenecks into leverage: the job of a QA engineer, for instance, should be to document QA processes and build tooling to automate them as much as possible. QA on individual features should be done by the engineer in charge of that feature.

• Make ownership visual: having a highly visual representation of the state of work can be extremely helpful in creating ownership. Most development teams work with Kanban boards, which are great for this sort of exercise: make sure your Kanban board actually has columns for every single step of your development process (e.g. don’t conflate code reviews with QA) and make it clear that it’s an engineer’s responsibility to keep things moving through that board at all costs. Also, make sure people give priority to things on the right (i.e. closer to get done) over things on the left. Having strict rules in place helps fight our tendency to start something new when we feel blocked on in-progress tasks.

• Delegate decision-making: nothing empowers people such as… their manager empowering them. Delegate decision-making as much as possible, even and especially when it feels a little uncomfortable. This doesn’t mean you should leave people to themselves: always be there for your engineers to talk a problem through, but give them the last word if possible. When someone has autonomy, they will honor that autonomy by exhibiting ownership.

As I said, your mileage may vary, but a good starting point is to try these practices in your team, keeping what works and adjusting what doesn’t. People will start taking ownership in ways that surprise you, identifying bottlenecks and creating original solutions to keep the process moving.

Ownership Is a Gateway to Velocity

You have probably heard the term “velocity” before. A lot of articles talk about velocity and the difference between velocity and speed: while speed is just about how quickly you’re moving, velocity is also about where you’re going.

Many teams move crazy fast, but they often lack a clear direction. As a result, they do work that is not truly meaningful for the business, or they have to redo their work over and over again because of defects, incomplete implementations or missed requirements.

Once you and your team start exhibiting ownership, you will realize how connected ownership and velocity truly are: teams that own their work are teams that move both quickly and in the right direction. This connection exists for two reasons:

• Ownership is first and foremost about doing the right thing. Low-ownership environments discourage engineers from thinking about the business value behind their work, but high-ownership teams carefully consider each initiative and its impact from all possible angles. People will start doing things that really move the needle.

• No one wants to own a half-done task. Teams that don’t own their work often do the quickest thing that will allow them to cross an item off their list, whereas teams that exhibit high levels of ownership know that the work doesn’t stop when it’s in production: quick and dirty solutions mean more maintenance work down the line and less time for high-impact initiatives.

As you can see, creating a high-ownership environment is not just the best thing you can do for your team members, but it’s also the best thing you can do for your business: it will increase the volume, quality and business impact of the work produced by your engineering team.

For a lot of managers, it can feel scary to give away control so radically, once you have seen the results, you’ll never want to go back.