The following article was written by Eric Brooke, Technology & Product Executive.

 

This post is part of a series on Scaling Small and Medium Technology companies. I will start with a hypothesis for each of the topics I explore in this series. This post will present why I think it is a valid hypothesis. This does not mean that the hypothesis is correct. This post and my understanding will evolve over time.

Summary

Talking about ownership is really important to do at your organization. The journey is more important than a destination and this will help your organization find its approach to ownership.

Where you can, consider sharing ownership when you can and if it’s critical to your business build a team around it.

Ownership is organic, it will grow and contract. The people will change. See change as an opportunity and not a thing to fear.

There is real power in giving ownership to ICs as well as Managers (devolution or delegation is a good thing!) sometimes called empowerment.

 

Hypothesis of Ownership

“A positive approach to Ownership will help you balance scaling of the business, operations, product and engineering.”

I hypothesize that if you break the work of an organization into areas of ownership, where:

1. 1. 1. • the boundaries are clear (understand what it is and what it is not)
         • the ownership is shared (more than one person)
         • the owners have both the authority, responsibility, and accountability
         • it is devolved/delegated to the appropriate level – not everything should be at the exec level
         • it is considered organic (i.e. will grow and decay), and ownership will change hands
         • the information about the thing owned is accessible e.g. documented and not in one person’s head
         • the journey is as important as the destination (shared conversations of Ownership will help both the individuals and the Organization understand the right approach for this “community”)

Then the organization will be able to adapt and be more resilient to change, both from scaling or from shrinking.

This first blog post will focus on the What and Why of Ownership, and a later post will focus on the How and When.

 

What is Ownership?

“the state of having, owning, or controlling something”

What is a “thing”

The owners are responsible for a “thing”. The thing could be a business, Domain (per Domain Driven Design), a System or Tech Stack or Product, a Goal, a Key Performance Indicator (KPI), Objectives and Key Results (OKR), or a process, etc. Either way, all your people should be able to understand from a business or a customer perspective what the thing is. If this thing is critical to the organization, consider it as a thing for your onboarding education for all staff.

Who are the Owners?

Owners can be anyone in your organization who is given both authority and responsibility over a thing. I personally believe this can be managers and individual contributors. When I think about ownership, broadly I’m considering how to turn all followers into leaders so that they truly have ownership over something and can add value to both the individual (i.e. leadership development) and the organization (in creating a trusted person or team that the org can rely on) and the organization can be much more responsive to changes both internal and external.

Broadly the “Owners” have to feel it and know it

The owners should have the space (or slack) to make decisions, without others telling them what to do (this is different from hearing perspectives from others). Put another way, they should have some level of Autonomy.

Owners should learn from Users, the wisdom of others and will adjust their leadership approach depending on the context. They should have the opportunity to maintain and improve the area (i.e. Domain, stack, system, etc.) and have the skills and the systems to support the area. They will be able to plan a future and have accountability and authority (note: it’s always better to lead with inspiration vs authority).

What does a great Owner look like?

Great owners tend to have a proactive and self-starter attitude, possess autonomy, are more likely to “think outside the box”, actively seek feedback from stakeholders, and are able to look ahead without being paralyzed by it. They love to educate others through face-to-face, video, or documentation. When things go wrong they are able to own it and facilitate the building of solutions.

It has to be a cultural concept for the whole organization

You cannot have some employees who have bought into the concept and others who have not.

Leadership by example is important. For example, does the CEO own their mistakes? The Executive? The customer service agent?

Everyone’s actions and behavior will determine success.

Every person regardless of level should demonstrate ownership with both successes and failures. Failure discussion should be focused on the root cause and learning from it – not blame.

Ownership constantly changes

I often think about the “things” owned as organic, they will grow or decay. If you believe a thing/domain is critical or unique to your business, you need to keep evolving it and helping it become better because nothing remains static, and if you don’t maintain it, it will decay.

People change jobs, have kids, and live their lives, all of this will impact who owns something and how they own it. It’s much better to have a growth mindset about what you own, as it will change and each ownership will teach you something both the good and the not-so-good.

At times people will want to hand over ownership, whether through choice or not. A good handover is important, the more that is documented the better for both parties.

Ownership is not just convenient

Ownership should exist through the good to the bad, the easy to the difficult, and not just when it’s convenient. Ownership comes with a bunch of work and not just status. What you own will evolve or shrink. Boundaries are likely to shift as the complexity increases or decreases. The shared language will change just like any word in the dictionary, they evolve in meaning and context.

If you see a problem, own it. Or at least share it with the person who needs to own it. There are no innocent bystanders.

The organization is still always responsible and does not get to pass the buck

Delegation does not mean you are now accountable for everything, the boss is still accountable for delivery – thus consider how you will keep them informed as appropriate. With everything there is a level of risk management, not every owner of a thing will be comfortable and the higher level of discomfort should not be forgotten – I often write notes to myself about “how bad the situation” when I delegate a thing and its ownership so that I can refer to it at a later stage. Here are a couple questions I ask myself:

1. 1. • Do the owners have the capabilities, the background, the context, and the time to own the thing?
      • What is the organization doing (or what am I doing) to support the owners’ growth?
      • How clear are the expectations in the Goals, OKRs, KPIs?
      • How does the organization onboard, evaluate and help expand horizons?
      • How does the organization respond to failure both implicitly and explicitly?
      • How honest or transparent is the organization?
      • Does the organization have enough people to actually own something well?
      • Can people say no?
      • What are my overall thoughts about success?
      • What can I do to improve the level of success behind the scenes?

For many small organizations, the reality is that the answer to these questions is often no. So consider your plan to improve it, and if you cannot – consider whether the organization is trying to own too many things. Can the organization say no or do you have years of roadmaps already booked? Prioritization becomes key. Something that often helps here is having ratios, e.g. each manager should have no more than 8 reports (i.e. 1:8). This allows you to understand when you may need to add extra people.

The structure can have a big impact on whether autonomy or ownership will be successful. For example, “Stay in your Lane” could be an ego or structure problem.

Ownership is affected by the rest of the world

There is always the temptation to focus just on what is happening in your organization. Social Issues (e.g. killing of George Floyd), Health Issues (e.g. COVID-19), Political Issues (e.g. upcoming election), Global Economics, Market Economics, National Economics, Technology Advancement (e.g. ChatGPT), Competition Advancement and many more things can change the complexity of ownership, what is ownership and how owners feel whether it be for a day, month or years.

Devolved Ownership helps an organization be more responsive

Moving the power down to the people who are building or creating or servicing often leads to a faster response, and to some degree mitigates the cost of hierarchy (i.e. slow decision-making), the growth of many leaders, and encourages people to stay in the organization longer.

 

Owner responsibility

With leadership for a thing comes responsibility. Your role is to manage expectations and deliver on what is expected for the thing and if you cannot that you effectively communicate and define the plan for what is next. Ownership should not be taken lightly, it is serious and people and the Organization will be depending on you.

The mindset of an Owner is key, that you will be able to verbalize, (sometimes at a moment’s notice) the sum total of this thing, that you will be truly open and proactively seek feedback, and will cross “traditional” boundaries to support the betterment of the thing. That you will also give it up when asked. In the end, we are all accountable to someone.

You also own how you make people feel when they interact with you in the area of ownership. This feeling will also be a barrier or lubricant for feedback. Which will very likely determine how long you own the thing.

Here is a list of things you are responsible for as the owner:

1. 1. • Boundaries – You know the boundaries or you figure it out. Also, the owner is open to changes in boundaries when it makes sense. The right Boundaries can help focus, and can reduce complexity, in the beginning, they will likely change often until you find a good sweet spot. Don’t let assumptions guide this, talk with the right people and build a shared understanding between you and them
      • Delivery – Deliver on what was agreed and communicate when that’s not possible as soon as it’s understood. How good is the process?
      • Changes – Responsible for communicating changes and what they mean. Own the communications, the good and the bad – no surprises.
      • SWOT – Understand the internal Strengths and Weaknesses, as well as the external Threats and Opportunities for the thing. What new types of technology could kill this thing you own? And how far away are they from commercialization?
      • Metrics – What are you measuring and why? What are your leading and lagging metrics? Understand the metrics to show success or not. How much does the system cost to run? What relationship exists between these metrics to the Enterprise Metrics and Financial Metrics for the organization? Do you understand the Return on Investment?
      • Observation – How do people experience and understand what you own? Transparency into how you do observation, quality, or process – shows you have nothing to hide. Do you have a Dashboard for metrics? Good documentation? Clear change log that is accessible to those that need it? Document major design decisions?
      • Not a Dictatorship – Open to input from others and proactively seeks feedback and input. Looks to grow others i.e. education in their understanding of the system. Great Owners welcome curious questions are mostly not defensive, and maybe even have a regular Net promoter survey(NPS) to check in on their users. The counterbalance is not a democracy either, the owner should still make the decisions, even if they share this.
      • Shared Understanding – Technical documents are not always accessible to all, so it is important that all stakeholders can read and understand. Examples could include great documentation and visuals to help others understand it and understand who it is written for. e.g. great API documentation or process flows or business rules, etc
      • Outside of working hours – If required, having On-Call rotation for the whole team that owns the “thing” i.e. Incidents, and good Runbooks (Runbook development) to support On-Call.
      • Quality – What is in place to improve the quality of the service or product released? How do new people learn? How do you stop defects before they are released and do you test post-release? What happens when the system fails in front of customers?
      • Security – Who understands this? How often is it checked e.g. penetration testing? Who stays up to date? How does fraud appear? Does revenue always beat security or privacy concerns in debates or decisions?
      • The data – How is it cleaned? What is the cascade from product to Business Analytics to Data Science from updates to the Data base? How easy is it to see data lineage? What reporting and dashboard do you have in place to support the company metrics and understanding of your thing? What privacy laws are you acting under?
      • Onboarding – How do people learn about this “thing”? How do new people learn, how do people with different technical backgrounds learn? How do people learn how to use this “thing”?

This might seem like a lot, because it is. Therefore, I believe it needs to be shared e.g. in a department, team, or partnership.

 

Effective Collaboration

If one person owns a thing alone, it could lead to burnout or bottleneck (single point of failure), or else a dictatorship or pain when a person leaves – through the loss of tribal knowledge (any unwritten knowledge within a company that is not widely known) – sharing is both good for the person and the organization. It is better to have a team with the necessary capabilities or at least a peer to support the owner.

1. 1. • It should be Shared
        • Better for diversity of thought – more ideas and solutions
        • Protect people from burnout and have vacations
        • Better estimations on delivery
        • Protects the business if people leave
        • Has to be at all levels e.g. CEO to Individual Contributors
        • Open to influence from others to evolve to the next level e.g. No dictators
        • On Call should be shared

With shared things, it is good to have a philosophy behind how you will share the ownership. You should talk about this and define your collective approach. Whether it be one looks after the what, when and why vs the how or the RACI model (responsible, accountable, consulted, and informed).

An example could be a Product engineering team owns integrations:

1. 1. • Product Manager (PM) – owns the why and what
      • Engineering Manager (EM) – owns the how, or maybe shares that with a Tech Lead
      • Together the PM and EM agree on the When i.e. the priority and Delivery
      • In good teams, the software engineers (frontend, backend, and Quality/Test would also be giving their perspectives)
      • If you have an Agile Facilitator or Scrum Master, they would support the How and When

Shared ownership does not mean ownership by committee, which can lead to a very slow and risk-averse culture if not carefully facilitated – as this can lead to everyone and no one being an owner.

I often think of this approach as load balancing for uncertainty and is often needed in Startups and scaling companies.

The sole owner approach

Big Tech and Large companies often face problems related to who Owns something – it can get confusing when you have a problem that crosses many boundaries of both hardware and software. Some time ago Apple revealed an approach to Ownership “Directly Responsible Individual” (DRI). This person owns the success or failure of a project or a product. Without a doubt, this strategy works but often has some interesting side effects, it can be Heroes, it can allow the organization to pass the buck for non-prioritized projects and it assumes that people will stay in the organization for a long time and the organization is safe in terms of existence which is certainly more likely in BIG Tech than the average startup.

GitLab has a great page on this topic and for complex cross-cutting work, it is worth seriously considering.

 

Why Ownership?

How does it benefit us? As an individual, a leader, or from the organization’s perspective?

 

Individual perspective

The opportunity to own something meaningful is the opportunity to become an expert, do something valuable, and even show good leadership. To have some level of Autonomy is powerful. Great owners influence rather than dictate and seek expert and user feedback.

When you think of ownership don’t just think of Managers think of Individual Contributors as well. The opportunity to devolve ownership throughout your whole organization is a powerful one, it helps people step up and maybe even become leaders themselves.

An incredibly important aspect here is how the Organization responds to failure – does it focus on root cause vs blame? If it is a blame culture, then fewer people will want to own anything. It’s also worth noting the logic track of the organization do people more often assume than ask?

Ownership can support the growth of an individual

1. 1. • Feeding Autonomy, Mastery, Purpose (Drive – Daniel Pink – Book, Video)
      • Giving Clarity (if the boundaries are clear) and open-mindedness as the boundaries change
      • Encourage more Grassroots ideas, will lead others to speak up
      • Increase Diversity of thought if shared – learn from others
      • More Psychological safety – Candor – Empathy
      • Constancy in who is the leader of a Domain

This type of ownership could encourage Individuals to grow in other forms of leadership, and more proactively think about the needs of the organization.

I would suggest successful ownership of something will open doors for promotion for individuals and are likely to be seen as more valuable in multiple situations including layoffs. It will allow someone to also understand leadership to a much higher level, whilst gaining knowledge from many others.

 

Leadership perspective

Delegation is a good thing and allows your leaders to scale. The discussion of ownership can lead to much clearer expectations for both individuals and leaders alike. If there are clear owners, aspects of their role may become much easier for Leaders, allowing them to look further ahead and wider. It can lead to new leaders emerging in the organization. With mentoring behind the scenes, it allows the person that is currently the owner of the thing to stay the owner (i.e. not have it damaged by drive-by from the Executive) of the thing and they are still able to get good advice without the shame that may come with receiving it in public. Ownership will hopefully guide leaders (even those using Command and Control leadership style i.e. micromanagers) to a mindset of growth and using multiple leadership styles depending on the context

1. 1. • Expectations can be clearer
      • Allows leaders and managers to scale
      • Lets others step up
      • Creates Space for learning and learn to lead
      • Mentoring behind the scenes, to allow people to grow – without the shame of drive bus or failing in front of people
      • Opportunities for leadership development will encourage more people to talk about leadership and help all to grow as leaders
      • Likely improves retention throughout the company, so leaders can spend more time on leadership vs recruitment
      • More candidates for wanting to go into leadership and management – also keeping knowledge in the organization who may understand the market

As a practice, I often see how people do with a mundane area to own, before I would give them a critical area. It gives them an opportunity to get familiar with Ownership and failure plus learn from the failure. Hopefully setting them up for success when they have something critical.

 

Organization perspective

The opportunity for ownership to be shared beyond the Executive and other leaders is a powerful one. It shares the workload, and the ability to influence and gives space for new leaders to appear. It can give opportunities for others to present to the Executive, the Board, or the whole organization – for some, this is motivating, for others it can be great to hear their work presented by others. It can create stronger belonging throughout the organization, and it can show that other voices matter. It gives a stronger opportunity for more people to emerge as leaders, and this can lead to more promotions and better retention. If people have ownership of a thing they will also be likely to respond faster to issues, than for decisions to travel the hierarchy. If the Executive “over manages”, this could lead to slow responses and bottleneck of always waiting for the Executive.

1. 1. • Multiple People owning a space, reduces the risk of losing knowledge when people leave
      • People understand and feel their value – a strong motivator
      • Space is left for Leaders to grow, leading to more internal promotions possible
      • Move from an organization of Followers to an organization of Leaders– See Turn the Ship around!
      • Shared ownership gives the ability for flexibility for people in their lives, and more resilience for the organization when people leave
      • Drives the connection between the Org and the individual 
      • Owners in the organization also have some financial ownership of the organization i.e. options or shares. Thus they are true owners of the organization
      • List of things the org will not do i.e. a No List for the Organization can help the Org and all its leaders focus

 

A Way to Explore How Effective Ownership is at a Tech Company

There are many ways to do this, but I find this is easy and allows you to compare organizations, especially for companies’ post-market fit.

Look at Incidents and their reviews e.g. Site Down. For the people involved, they may represent the “worst” thing and time, that can happen to a team or an owner or to someone else supporting this event and not always at the best of times e.g. 3am

1. 1. • Who responds to incidents?
      • Are there rotations? What happens during vacations for primary owner(s)?
      • Are the post-mortem blameless?
      • Who learns from post-mortem?
      • Who helps out?
      • Who does not and why?
      • How good is the observation?
      • Are there Runbooks? How good are they?

If you have yet to have a perspective on this, read The DevOps Handbook, this will set you up for success

What’s Next on this Topic

1. 1. 1. Additional blog post – Ownership how it can go wrong – Part 2

 

---

Alpha Testers

Thank you to the following people for chatting through their perspectives on Ownership

Jen Cooper, Shane Moore, Greg Hubbard, Ieshe Washington, Zach Gallup, Attila Domokos, Danila Ulyanov, CTO Toronto, Derek Wyatt, Geoffrey Hunter, Lakshmi Baskaran