Can This Ownership Exercise Improve Your Collaboration Habits

When you’re working in a group, you need to know how to coordinate. Coordination requires a shared understanding of how everyone will work together. Most human groups define Roles. Roles help clarify boundaries and expectations for people working together.

For example, in sports, these roles are called Positions. To play well, you need all the positions to understand how to work with each other. And you need everyone to focus on their position. It would be ridiculous in football (aka soccer) to have everyone try and be the goalkeeper.

People often fail to work well with each other, because they lack that shared understanding of the Roles each person plays.

Over the years, I’ve come up with a simple way to align people on roles. It’s way simpler than alternatives like RACI charts (but we’ll describe those too). You can use this exercise when it isn’t clear who is responsible for what. You can also use it for teams to define boundaries of team ownership.

Getting set up for the ownership exercise

I’m going to assume we’re using this exercise between an Engineering Manager and a Product Manager. But you can use it for any roles.

You’ll first need a whiteboard. If you’re not in person, you can do it with Google Doc, Miro, Notion, or Trello. Really most tools will work.

Start out by creating three columns on the whiteboard:

1. Write “Clearly Engineering Manager” as the first column, on the left.
2. Write “Clearly Product Manager” as the third column, on the right.
3. In between the two, write “Unclear”

Doing the ownership exercise

Next, you have the people involved write down stickies for all their responsibilities. One per sticky. Why stickies? You want to easily be able to move things between columns. If you’re using a tool like Trello, you should be able to drag between columns, so that works as well.

You can do this two ways:

1. Have each person create a bunch of stickies, and then talk through each as you put them up.
2. Or, you can have people put them up as they create them. Then review to make sure everyone agrees they are where you think they should be.

I usually use the second approach, as it is a little more time-efficient. Basically anything you have ANY disagreement or want to discuss should be moved to the middle column.

Here’s a messy version of how it might look after adding some responsibilities. In this example, both the Engineering Manager and Product Manager think they should be doing project reporting. And they’ve both worked in places before where their role was responsible for defining user stories for the team.

Just doing this initial exercise has already been valuable. You’ve aligned on a lot about your roles, and you’ve made it explicit what conversations you still need to have. If you did this on a whiteboard, take a picture. You’ll need it later.

Discuss the unclear parts of your roles

Next, you want to go through each of the items in the unclear column.

You may not cover all of them within this first meeting. That’s fine. Spend the rest of the time you have figuring out as many as you can. Here’s what to do:

1. Figure out the tradeoffs. For each responsibility, ask yourselves: what’s the best argument for the Engineering Manager being responsible for this? And what’s the best argument for the Product Manager owning this?
2. Discuss the tradeoffs. Talk through any concerns or tradeoffs you see.
3. Make a decision, even a temporary one. If you can’t come to an agreement, flip a coin and agree to discuss how it’s working after two weeks.

Get through as many Unclear items as you can, and schedule followup meetings to finish up anything remaining.

Document what you’ve learned

You’ve now done the work defining the roles. One of you now needs to write down what you’ve agreed to. Simply list the roles, and the areas of responsibility under each.

You can also categorize things, if you’ve had a discussion where you’ve come up with some larger themes. For example, you might say the Engineering Manager is responsible for People, Process, Projects. But it’s always useful to include examples. The larger themes are optional.

This is also handy when teams go through mitosis

You can follow this exact same approach when a team gets large enough that it splits in half. (Splitting a team in half is a great way to form new teams).

The team will have a lot of existing things it owns: parts of the codebase, and interactions with other parts of the organization. Run these through the exercise, and you’ll have a list of things that are clearly owned.

With teams, you’ll often have some sticky items in the Unclear column. Some of them might require technical work or projects to untangle. For example, you might have a piece of code that both new teams will rely on.

Document what you agree upon, and agree on some short-term ways you’ll move forward on the Unclear items. And make sure you have real plans in place to figure out what to do with the Unclear items.

Write roles and team descriptions down in a canonical location

Let’s say you’re a Product Manager, and you’ve just gone through this exercise with your Engineering Manager counterpart.

A question you should ask yourself is, “does anything like this exist for everyone else?“. If you don’t have role definition written up, then the artifact you came up with might be generally useful.

If that’s the case, share it or put it in a place where it can act as the canonical definition for your roles.

For teams, you also want the responsibilities to be put in their canonical location. For code, you might put it in the CODEOWNERS file, so it’s clearly marked in the codebase. For support responsibilities, you should outline how support should interact with each team. Make sure the clarity you’ve produced is put into a place where it can be used by others, if that makes sense.

People aren’t fungible, so roles need some flexibility

Roles shouldn’t be rigid. Every person is different, and every pair of people will have different strengths, backgrounds, and ways of working together.

It should be a valid option to identify that one role owns an area of responsibility but delegates that responsibility to the other role. For example, Engineering can be responsible for projects but be totally buried in other work. So you can agree to have the Product Manager run the projects for a period of time.

Also, if you have standard role definitions and want to change the lines between you, you should if it produces better outcomes. I find having the roles written up allows you to have more explicit conversations about these things. “Hey, it looks like you’re responsible for project reporting. How would you feel about me doing the reporting, or helping you with it?”

Some people like RACI charts

You will find a lot of managers that love for this same purpose. I find them inscrutable — they take a lot of attention (for me) to understand.

What is useful about RACI charts is that they define responsibilities in a more nuanced way. So, for example, they make it clear who needs to be informed about certain types of changes.I generally find them to be more effective when you’re dealing with a lot of parties. Stakeholders and multiple people, all doing similar work. The ownership exercise I share here is simpler, faster, and easier when you have fewer parties involved.

If you are in favor of RACI charts, please be aware that not everyone understands them intuitively. It can be useful to walk through them.

Let me know what you think!

I find this exercise to be a quick way to get clarity and alignment around roles. Try it and let me know what you think!

Thank you

Image courtesy of . Licensed under the Creative Commons 2.0 license. The image was cropped.

If you liked this post, to my newsletter course on engineering leadership, or my .

---

Also Published