Roles transformation is one of the hardest aspects of Agile transformation. It’s easier to introduce new meetings or metrics, but roles modifications make people feel uncertain and can trigger fear reaction and resistance. People invest in skills, relations and especially knowledge of how to operate in the company environment. Significant role change could be challenging for them.

In this article I’m presenting a few principles of roles transformation, followed by the proven framework which you can take and use in your organization, but let me start with a story.

The story

In 2018 I have been working for Intel. At that time we have proven that new, redefined roles model (tested in a group of three teams) worked well. Organization leaders decided to use this model for the whole organization. All managers were involved in this activity. They started with a long list of responsibilities and activities which each and every role must follow. I have joined them three months after the first meeting and they haven’t had covered all roles yet. Observing them, I have found that it’s hard to define roles in such detailed way. They have been struggling with the wording, details level and different opinions. The energy dropped to the level, where everybody wanted just to finish this exercise. It’s hard to address the complexity of the roles in such precise list of responsibilities and activities, especially in a large group of people.

Problems

Let me summarize problems related to the way the roles and responsibilities are typically defined.

It’s hard to address complexity
Each person is different, each project is different, each team is different, so if the role definition is too rigid (too detailed), people cannot use it as a guideline in daily situations. You can’t predict everything that can happen. 

It’s easy to say “that’s not my job”
It’s especially painful in case of unusual situations. Nobody takes responsibility for such tasks or issues, because “it’s not on my responsibilities list, sorry”.

It does not address roles cooperation and grey area of responsibilities.
Real issues and conflicts rise on the edge of two or more roles. Separate roles definition give no guidelines how to establish cooperation between roles and how to operate in the grey area of responsibility. See roles contracts described later on in this article.

It’s too long and detailed.
The longer and more detailed the list is, the weaker it becomes. A few simple rules are stronger. 

Principles

My roles definition framework is based on the following principles:

1. Role must be explained by a strong purpose statement.
2. Address complexity, by focusing on role limitations (boundaries) and leave the space for self-organization.
3. Roles shouldn’t be defined by a single person. It should be a group process.
4. Keep it simple.
5. Face to face communication is the best way to discuss and understand roles.

I like “principles over rules” approach, because principles are guidelines focused on what is crucial. Rules are important, but rules without principles can be easily misused and distorted. I’ll use those four points later on describing the framework.

Framework

Principles are important, but do not explain how to make things happen. It’s like 12 Agile Principles vs Scrum framework. 6th principle says “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation”. In Scrum framework we have very specific examples of addressing this principle like Daily Scrum meeting, so people can follow Daily Standup rule to live according to 6th Agile Principle.

Roles Definition Framework is designed to help you to organize role definition activities in your organization. It’s divided into three activities:

1. Preparation
2. Role definition workshop 
3. Roles contracts

Preparation

Many roles redefinitions are motivated by Agile transformation, but often you cannot just remove old roles and introduce new (e.g. Scrum) roles. There are multiple reasons for incremental changes of roles. One reason is leadership. Imagine that you have architects in your organization who hold strong technical leadership. If you just remove that role overnight, you can have a significant problem if your teams are not ready to step in. Another reasons are skills and knowledge. If business analytics are the only ones to have some unique expertise in your company, it wouldn’t be wise to get rid of them. 

Agile frameworks define some roles, but often your organization requires specific parts for some specific needs and you need to define them. If you need somebody to eat honey, maybe you need to define “Winnie the Pooh” role. 

That’s why you need to know the rationale for the change. You need to explain that motivation to the people in your organization. This have to be defined during the preparation phase. The good example could look like this:

“I want to address issues with lack of ownership of the product (problem statement), by introducing Product Owner role. Product Owner role should lead to better prioritization and faster decision making regarding the product. As a consequence of the new role, team manager role needs to be redefined, because their responsibility for the product will change.”

If you go out to the people with the new role definition without explanation “why” first, they will fill this “why” with their own ideas.

Roles definition workshop

If you know why you need to redefine the roles, now it’s time for the roles definition workshop. Event should be planned for 6-8h depending on the number of roles and level of resistance for the change. 

Why this should be a workshop with representatives of all parts? Role definition should emerge from face to face conversation, deep understanding of the purpose and impact on other roles. Workshop gives a space for people to discuss, build common understanding, reduce the fear and to get the buy in. Invite people who are in those roles or will be assigned to newly defined ones. Prepare one flipchart per role. 

 Role Purpose

Definition should be strong, but simple and short. That’s why at the beginning of the workshop people need to find a good purpose for that role. This should be powerful and crisp, like a slogan on a t-shirt. You can ask questions like:

1. What would happen if this role would disappear from the company?
2. What value brings this role to the organization?
3. Why do organization needs this role?

Encourage the people to search the internet and other places with specific role description to find inspiration and discuss common understanding of the role.

Role Constraints

When a good rationale is ready, it’s time to define role boundaries. In this framework, roles will be driven by strong purpose and clear boundaries, rather than detailed list of responsibilities. It’s a kind of inverse definition. Let me explain it a little bit.

Dave Snowden introduces two concepts for rules definition: governing constraints and enabling constraints. The first is a recipe approach, which leads to traditional “what to do” and “how to do” roles definition. Second approach (enabling constraints) focuses on limitations (constraints) around the freedom of self-organization. This is a conceptual pivot which hit my brain when I have started thinking about it. It radically changes people’s responsibility, autonomy and clarifies limitations for each role. Those two aspects are crucial:

Autonomy with strong awareness of specific context.
Products vary, people’s personalities are different, people maturity in roles are not the same. People should have a freedom to operate in the role and self-organize. The same Product Owner shouldn’t behave exactly the same with different teams. She or he has to take into consideration team maturity and empowerment level. 

Clear boundaries of the role.
Self-organization must be limited by clear boundaries. In typical “roles responsibility list” approach they are not clearly defined. Imagine that you are introducing Product Owner role and you need to redefine manager role (who used to be responsible for the product). You want your managers to focus on people. If you only define what managers should do (and some of them still want to make decisions about the product) it could be unclear to what degree they can interfere with the Product Owner responsibilities. If you clearly define the borders (limitations) like “managers must not modify product backlog without PO approval” or “managers do not actively participate in the planning sessions” you will have much clearer situation. In case of conflicts, people can use such definition to resolve them. That’s why purpose + boundaries are key drivers for roles definition in this framework. 

To be more precise, roles definitions should also contain focus areas to show where people should be focused on. For Product Owner it could be:

1. Development teams
2. Customers
3. Market trends and competitions
4. Business stakeholders
5. Product Owners community of practice

Focus areas can be extended by expected impact of the role in those areas. You can also add required skills if necessary, but keep everything simple. 

During the workshop ensure all roles have a flipchart. Role definition should fit on the single flip chart sheet. Below you can see Scrum Master definition created during one of the workshops.

Often such definition need to be supported by good practices or recommendations (see attached A4 sheets stuck to the flipchart). It’s a good idea only if it’s not a part of the role definition. Assumption here is that everyone can replace it with their own practices.

This is a rough plan of the workshop:

After the workshop you can clean up and polish results to get the nice, crisp and easy to understand descriptions. Make them transparent and agree on how to modify them in the future. If someone feels a need to change it, you don’t need to start from scratch. You can focus on specific issues and aspects of the role, but remember about role definition principles, which I mentioned earlier in this article.

Now it’s time to take newly defined roles and do the daily job.

Contract between roles

Reality is not so simple. You need one more element – contracts between roles. Roles definitions discussed during the workshop are necessary to align on the concept level, but you need a simple and powerful tool which works on the edge of the roles. If the role definition is the abstract visualization of the car, roles contract is the engine. 

Roles contracts concept have been inspired by the Morning Star Case Study by HBR. Morning Star is a company where employees define work agreement between each other using “Colleague Letter of Understanding”. 

Contract is a way to encourage two individuals (or person and team) with different roles, who need to collaborate to start with an agreement on how they want to work together. There are two questions which constitutes the discussion:

1. What do you need from me to successfully fulfill your role? (needs expression in both directions)
2. How are we going to collaborate? (collaboration rules)

First question gives people a safe space to express their needs. If they both understand others needs it’s much easier to agree on collaboration rules. Those rules could cover things like:

1. Meetings
2. Information flow and tools for communication
3. Ways of providing feedback
4. Conflict resolution
5. Metrics
6. Frameworks

Such contract is a living document. It could be modified whenever someone feels a need to add, remove or change it. 

Summary

Going back to my Intel story, managers finally defined the roles in a way described in this article and we have been experimenting with the roles contracts. Later on I have inspired a few other companies to define roles using this framework and they were happy with the results.

This model is inspired by Agile transformations which I have been involved in, but it’s not limited to this specific case. It can be used in any organization (if the culture allows for this approach). I intentionally separate principles (you can build your own method on top of that) from model/framework. I will soon publish PDF templates for role definitions and contract. Follow me to stay tuned for upcoming updates.