While today I’m mostly talking about ownership in software development, I believe that ownership can be of use to you regardless of what industry you are part of. If you are in a position to foster a culture of ownership in your organization, you can benefit from it.

Why do I even need ownership in my organization?

I can’t proceed without explaining the term ownership more precisely.

What is ownership?

Ownership is not an easily defined term. If I had to give it a go, I would say that it is a real and perceived sense of responsibility and belonging to a project, team, product, or organization. Your employee feels like an owner when:

• they feel like they can grow as individuals and professionals at your organization,
• have a sense of purpose and real influence on the current and future state of affairs,
• care about the success of your organization, and believe they have a stake in it.

Tom Kwiatkowski, CTO of Pet Media Group, a major network of pet marketplaces and one of our most trusted partners, shared his thoughts on ownership during our get-together at the CTO Craft Bytes discussion panel “Growing a Culture of Empowerment Through Ownership”, moderated by Emma Hopkinson-Spark. He pointed out that ownership, when coupled with empowerment, provides more freedom in everyday work. And if this empowerment provides people with some level of “control” over their environment and actions, responsibility and even accountability can apply. As long as they are properly prepared for the challenge, ownership can give them fulfillment.  I’m talking about it extensively in the context of developers in my piece on Developer Experience.

Ownership goes a lot deeper than Product Ownership (PO) in Agile development, or code ownership. While all they share some similarities in fostering the team’s responsibility for a project, quality (including code quality), ownership also involves caring about the success of the whole organization and each and every team member (not just software developers).

Members of an organization with a strong sense of ownership are always ready to help each other because they instinctively understand that their individual goals align and lead to the very same company-level objective.

Taking ownership of a project can also go a long way to improving Product Ownership, including processes such as continuous deployment. The available research from ScienceDirect shows that large companies inadvertently create a lot of obstacles to sharing feedback and suggesting improvements in the Agile processes due to the sheer complexity of planning in multi-team organizations. In the following sections, I’m going to talk about various aspects of a well-developed ownership culture that can help remove these challenges, in particular:

• forward-thinking leaders,
• interdisciplinary cooperation,
• and shared responsibility.

When ownership turns into hardship

While ownership sounds great on paper, it only works in practice when your team is ready for it. Giving them more power, when they aren’t prepared will only create more chaos if they are not. Only competent and motivated team members will benefit from a sense of ownership.

The good news is that when you foster the ownership culture properly, you will make your team more competent and motivated in the process.

During the panel, Emma talked about the difference between autonomy and anarchy. Naturally, the goal here is to achieve the former, while skillfully avoiding the latter.

Let’s do just that, starting with a team.

Empowering your team – ownership and team building

Introducing more ownership on a team level in a sustainable way requires effort in a couple of areas.

Keeping them informed

Information is the key when it comes to ownership.

Suppose you limit the flow of information only to what’s necessary for an individual to accomplish their low-level tasks. In that case, they’re not going to develop a strong sense of belonging to the organization. To keep your team properly informed, let them know about:

• the long-term objectives of the company,
• the business background of a project or product, even if the information is not essential to delivering tasks,
• and your feelings and opinions regarding the project or product.

Just about anything can be relevant. To know what information you should provide, create proper space to talk to your team about it. I will tell you more about that in the Tools & Processes section.

Building trust

According to Tom, building trust on a team level is all about moving from telling your team WHAT they should do towards WHY we need a given solution, leaving the HOW to them. When you put yourself as a leader in a situation where you need to pitch the project to your own teammates, the relationship between you and them changes. This isn’t really optional. Creating software in an Agile environment calls for it. Without explaining the purpose behind their work, the feedback loop you can achieve by working on a sprint-to-sprint basis will turn into a laundry list of features to be implemented, shipped, and forgotten.

Building competencies

The last point may make you wonder if it is so clear that all team members have the competencies to suggest improvements and pivots to the project in every sprint, regardless of whether they are provided with all the information or not.

Tom’s answer to this issue is that stable, long-living engineering teams that focus on particular products are a great way to solve this. The team members not only know each other very well but also gain a chance to really understand the product, customer needs, and behavior.  Creating such software engineering teams is not easy and calls for skillful tactics aimed at acquiring new talents and retaining the best ones you got. It also requires patience with your juniors – they are the most affordable source of future tech leads. Of course, it’s much easier said than done. Creating such teams, often referred to as durable teams, is a topic for another article.

Building the future together

As you can see, all the aspects of empowering your team through ownership have to do with having them see the bigger picture. Should you fail at that, you will get into a lot of trouble. I witnessed it first-hand a long time ago. A team I was a part of was so focused on delivering one sprint after another rather than building a good product that we didn’t even notice when the product didn’t meet the needs of its intended audience. Much of the work had to be scrapped. Tom had some great ideas about making your team focused on high-level objectives. I’m going to talk more about them later.

Fostering ownership culture

Empowering your team to ownership will not work if the organization itself lacks the spirit and culture of ownership. How to inject it? In my opinion, the culture of ownership is the end product of various cultures.

The culture of accountability

The assertion that your team members must be competent before your team can be empowered through ownership made me think of other preconditions needed for ownership to flourish. During the panel, Tom and I agreed that most such preconditions exist on a company level.

According to Tom, one of the primary factors is the culture of accountability. There is no switch to turn it on and off in his view. Establishing a culture like this is a journey. To set out on this one, as a leader, you need to have the ability to give high-level directions and motivate your employees to participate in establishing them on the team level as well. Teams can only be accountable for something if they have been provided with all the necessary data, been a fundamental part of their goal creation, and control their environment. Who would be up for being accountable without first being given some level of influence/control over their environment and actions? 

How exactly can you do it? At Pet Media Group, a big part of this is Product Discovery. As part of the process, they refine their products through prototyping and testing, considering real user problems. Everyone takes part in Product Discovery, acquiring a much deeper understanding of each product’s background and context. The more they know about the product, the more they care about it. Much like you can move from WHAT to WHY you can also have your team move from WHAT to HOW. When you have them talk about real user problems as part of Product Discovery, they will automatically think of how to best turn solutions to these problems into actual new features and products. 

It’s not a surprise to me that Product Discovery helps promote accountability. From my experience, very few things make team members more scared than lack of knowledge. Product Discovery arms them with knowledge and thus empowers them to care and take responsibility.

Individual accountability vs. collective accountability

There is no doubt that informed accountability is a good thing. However, another issue is where you should place the bulk of accountability in your organization – on every employee individually or on the team instead?

To me, it’s clear that accountability should be primarily seen as the quality of the team. First, the team is ultimately responsible for delivering the product, not each and every team member individually. In addition, my experience tells me that the team works more efficiently when the competencies of individuals intertwine. For example, at TSH developers increasingly participate in testing and operations. The more they do it, the more naturally it comes to them (another good argument for durable teams). To make it work, everyone needs to be on the same page and understand each other’s contribution to the project at least on a high level. Collective accountability plays right into that.

The culture of failure

Nobody wants to fail, but it is vital to admit that failures are a natural part of business and product development. Unfortunately, many leaders are still too afraid of making and admitting to making even the smallest of mistakes. They have the same attitude towards their employees, punishing them for unsuccessful ideas, missed deadlines, etc. As a result, team members often try to play it safe and stick to approved tasks. This culture is terrible for software development.

All team members should be free to suggest new improvements and participate in gathering feedback and testing. When individuals are allowed to take risks, they will inevitably and willingly get involved in various stages of a company’s activity.

The culture of “we”

Because of the collective accountability and culture of failure, we all lose and fail together – as a team. The exciting thing about this approach is that despite its collective nature, It makes it easier for individuals to try all kinds of individual initiatives since they are less likely to be punished for them as individuals. 

The combination of accountability, safe-to-fail attitude, and teamwork is really powerful, provided all the individual activities take place within a commonly shared framework of what, how, and why should be accomplished.

How to create a framework like this? Using the tool and processes described below is the way to go.

The tools & processes that drive ownership culture

All kinds of tools and processes can help you make positive changes both on the team and organizational levels.

The OKR framework

This framework is widely used at Pet Media Group to account for the drawbacks of the sprint-to-sprint workflow. The Objectives and Key Results (OKR) framework calls for defining main objectives and a group of measurable results (typically 3-5) you need to complete to reach the objective. OKRs can be defined on an individual, team, or company level. You should take advantage of them all. OKRs make it easy for individuals to see how their everyday activities (results) help achieve high-level objectives.

The feedback loop

In addition to OKRs, Pet Media Group promotes the culture of ownership through the build – measure – learn loop. It’s a variant of the trial and error approach and can be used both on an individual and team level. It plays right into the idea of continuous improvement and Agile methodology. Once a new initiative (e.g. new feature, design, or pivot) is recommended, it is tested through user feedback. The new initiative is accepted, abandoned, or modified depending on the results.

Speaking of the feedback loop, I can recall an interesting team-level example of this technique. A couple of years ago, I wanted to persuade my developers to take on some QA duties in a project. They didn’t like the idea at first. Then, we reached a compromise. The devs took over only some of the QA work I initially suggested. They were to provide feedback every couple of weeks. Every time they did, we made modifications regarding the volume and nature of their QA duties. Eventually, they came to like this part of their job. Of course, such an approach requires a long-term commitment to team building, showing the importance of durable teams.

The Retrospective

According to the Agile methodology, this meeting is to be held at the end of an iteration. It allows the team to talk about everything that has happened up until this point and identify actions for improvement.

A good Retrospective has the potential to alter and improve the product and processes strongly. However, it requires a proactive approach from all team members. It is a good test of how far ownership has come in your team and organization. 

The interdisciplinary meeting

In addition to team-level meetings, it is a good idea to hold interdisciplinary meetings.

As a leader, you can participate in them, but don’t overdo it. As Emma pointed out, the active observance has a way of distracting the observed. Besides, as I mentioned before, a big part of promoting the culture of ownership is restraining yourself from micromanaging.

Where do we go from here?

The topic of ownership in an organization is as deep and broad as it gets since it touches upon just about every aspect of the organization. However, I think that this article does provide the gist of it.

Equipped with all that advice, you might be wondering when your team and organization will reach the level of maturity necessary for ownership to succeed. Well, the truth is that this is not easily measurable. You’re probably going to have to take a risk at some point. When you feel it might work, don’t hesitate. Give them the benefit of the doubt and let go of the wheel a little. Sometimes, you just have to trust and believe in your team.

IT is a bumpy road. Failures are inevitable. But through ownership, you allow your employees to choose roads for themselves, freeing their full potential in the process. Whether you like this style of management or not, you can’t complain that it doesn’t work unless you do it properly, can you?

*** Bonus: a further read ***

If you want to learn even more about ownership, there are some amazing books and resources out there. Tom is a big fan of Empowered by Marty Cagan and Chris Jones, the Phoenix Project, and the Unicorn Project, as well as Jez Humble’s Accelerate.

As for me, I can definitely recommend Team Topologies as a way to learn more about empowering teams to sustainable and continuous delivery.