Who’s Responsible For What?

By Christian Kaiser

Imagine everyone in your company or department knowing exactly whom to invite or not to invite to any given meeting. Imagine decisions being made without delay because everybody who needs to be in the room consistently is, and the total number of people in the room is always as small as it can be!

In my experience, there’s no better way to accelerate a project than by being crisp about who’s responsible for what, who needs to be involved when and how, and who doesn’t.

I found that a RACI-like method (applied quite informally) works well. It’s a usually quick and simple exercise, with a very high return on the time spent.

I’ll walk through the steps in the following sections:

Determining Areas of Responsibility

First, you will need to define the “areas of responsibility” you want clarity on.

The areas you use for your exercise can be as coarse or fine-grained as needed though, as long as everybody knows where the areas begin and end. To keep it simple, I like to start with few coarse areas and only split and refine when needed (i.e. if there’s a different assignment of roles needed for a sub-area).

Let’s use an example: Baconwrappr.com is a fictional small startup of a handful people. Everybody’s wearing a number of big hats, and their areas of responsibility are rather coarse: “Sales”, “Finance”, “Engineering”, “Marketing”.

As Baconwrappr.com’s business grows, they hire additional people. They now have James, a sales executive. Mike, one of the founders, still works directly with a few key clients who he has a personal relationship with. In order to reflect that, the group split the “Sales” area into “Sales (client X and Y)” and “Sales (everyone else)”.

The company also hired a great product manager, Sean. Now “Product” becomes a new area of responsibility that is separate from Engineering.

To record things for discussion purposes, I like to put them into rows in a spreadsheet, like so:

NB: Google Apps seems particularly well-suited for this purpose because it allows collaboration between multiple contributors, plus no documents are passed around in email, creating confusion about which one’s the right one and how to merge.

Assigning Roles

Then you need to assign roles for the appropriate people in the team, in each area. Start with putting the names of people on top of columns to the right, like so:

Assigning the roles is quite simple, since there are only a small number of roles to choose from. Here are the ones I use:

Owner

The person in this role drives the whole area of responsibility forward. It could be simply someone who actually does the actual hands-on work, or a delegate like a program manager, team manager etc., if a whole team covers this area. This is the person who drives the decision process and calls the meetings. Please note that ownership means just that, and does not include final decision authority.

There can only be one owner for each area of responsibility. If you find yourself thinking about creating multiple owners for some area, think about whether your should split the area instead.

Stakeholder

A person in this role needs to agree when decisions in this area are made. Owners are also stakeholders by definition. Stakeholders are mandatory attendees to decision making in this area. If they cannot make it, they must send a delegate with decision authority. Or in other words, no decision that affects the area can be made without them.

There should be as few stakeholders as possible to be able to make decisions quickly. Ideally, there’s just one: the owner. But for a variety of reasons, many organizations choose to have more than one pair of eyes on the area.

Before assigning someone stakeholdership or asking for stakeholdership yourself, ask yourself whether the team could instead find ways to trust the owner or other existing stakeholders to make decisions. After all, stakeholdership comes with a commitment of time and focus. For example, the team might decide instead to increase the owner’s level of context by training them, or by bringing them into conversations they’re not part of yet.

Informs decision

People in this role are invited to meetings or are otherwise consulted when decisions need to be made. They are not mandatory attendees at decision meetings and are also not required to agree with a proposal.

To the contrary, if you find that you would like someone to be mandatory attendee to decision making meetings, they should probably be a stakeholder.

None

This is actually a very important role. Someone with this role in a particular area is not involved, e.g. not invited to the decision making meetings, therefore does not need to spend time and can focus fully on other areas. You’ll want to maximize the number of these.

 

In case you’re missing a role along the lines of “informed”: I like to simplify by not calling such a role out separately. In most small to medium size organizations, the default for this role should be “everyone”, at least for opt-in information channels.

Some people may argue that everyone in their organization already knows what each others’ role is, and that might certainly be true in their case. However, I have found it to be false in most cases. Specifically, it is often very difficult to organically disperse this knowledge crisply when new people come on board.

I was often surprised about how many disconnects were exposed after writing things down and discussing it with the people involved. For example, multiple people might think they’re the owner, or, even worse, it turns out that no one thinks they own a particular area.

Responsibilities are expressed as field colors at the intersection of people and areas of responsibilities. Pick your own color scheme! I’m using RED for owner, GREEN for stakeholder and YELLOW for informer.

Here’s baconwrappr.com’s matrix:

You’ll notice that it is not only clear how the roles are distributed in a particular area (horizontal), but also which hats and how many of them everyone wears (vertical).

I’ve seen very productive reality checks come out of this exercise, e.g. when someone realizes they cannot really own two major areas and be stakeholder in three more, or that a certain area has too many stakeholders. It’s often satisfying for the team to mutually agree on “downgrading” someone’s role, e.g. from “stakeholder” to “informs”, or even to “none”, because it likely translates into increased focus for the other (probably no less important) roles, and into faster decision making overall.

In our example, Mike, as a founder, started out wanting to be a stakeholder in all the areas, but then realized that he would be content (and already very busy) with informing Finance and Marketing decisions, and not being involved in Engineering decisions at all.

Communicating It

When the group is satisfied with the result, it’s time to communicate it to whoever needs to know (probably everybody). How you do that is up to you.

Since the semantics do need some explaining to folks who have not been part of the exercise, I’ve found it useful to go over the details with the team and have extensive Q&A rather than just attaching it to an email to all@.

Summary

• There’s often confusion about responsibilities, especially over time and through team changes
• A rather simple and short exercise can provide clarity and focus
• It allows to define the nature of involvement crisply
• The team can agree upon a efficient distribution of responsibilities after careful deliberation

Next Time

You may have noticed that I did not touch on what happens when stakeholders disagree. How can a decision be reached in that case? I will cover best practices around this in my next post.