Defining Jobs and Roles in an Agile Organization

Traditional jobs and roles suck

Let's face it, most conversations we in have in the workplace about, job positions, roles, accountability, etc tend to be pretty depressing.

One popular topic is whether or not you are meeting someone else expectation of you, another is hold another individual accountable for not doing their job. My favorite one is when we discuss why I cant do something because it's not my role, or I am not senior enough.

Clear Job descriptions, distinct roles and responsibilities, positional expectations are 3all organizational artifacts that are supposed to increase harmony and alignment within an organization. Every get a clear hand book on exactly what is expected of them, and everyone knows what to expect of every one else. Doesn't that sound great?

Not to most people I talk to. Often when I ask people of what they think about their role and position in their organization, I hear a common refrain. Rigidity, constrained, blame, lack of empowerment. Why is this?

Like this post, and want to learn more?

Click the link below to request a free digital copy of my book, Agile Organizational Design.

You are your Job and nothing but your job

In most organization you will get hired into a job description. That Job description is used to describe

• the role you play (typically one role)
• the accountability you have
• the (very specific) boundaries of responsibility you can play in
• how you progress to the next level of your career

Your job description is very likely to be

• Based on functional capability
• largely static, and changed infrequently
• positionally precise, pinned to a level of authority and exact in terms of who you report to and who reports in to you

Let's take an examples:

A business analyst is responsible for working with both business and technology to make sure requirements are clear, accurate, and well understood. The analyst will facilitate various requirements collection works shops, and is accountable for eliciting business needs for all stakeholders. The analyst documents these requirements and reviews them with Developers and testers…

So what's wrong with this picture? Well for one the focus here is on individual effort rather than than the interactions across individuals. The description starts and ends with an individual's functional performance, rather than accomplishing an end result. People rarely step outside of their job to achieve outcomes, and have a reduced opportunity to learn. Job descriptions like these seems to be perpetually out of date, with their obsolescence matching the exactness of the job spec. You are guaranteed your job title is never in synch with what what is required to deliver value

So to sum it up the traditional approach to roles and jobs don't serve Agile Organizations well because

• Roles are coarse grained, and tightly coupled to rigid job descriptions
• They are used to restrict individuals to very specific accountability and responsibility
• Written based on functional expertise rather than outcomes
• Are largely static, change infrequently, and are always out of date
• Are also used to define levels of authority and reporting structure

Do we even need role and job descriptions defined for an agile organization?

There are some out there that would say no. Some companies like Valve, have no official job titles for anyone who works at the company. You get hired, you choose your team, and you work with them to be successful. The role thing takes care of itself. How could this work? Valve would tell you their secret is to hire well, hire really really well.

While I certainly admire Valve's culture, and find it hard to argue with their success, here are also good example of Agile Organizations that have taken a more structured approach. Morningstar, a tomato processing company is one such example of a company that makes use of defined roles in a way that promotes rather than undermines self organization. Employees in Morningstar take the time to define roles so that people in the organization can frame a collective understanding of the jobs required to be done to enable their success.

I am of the opinion that you can define roles in a way increases clarity without undermining self organization. The benefits to doing so include helping individuals build a career path, making it easier for teams to identify jobs to be done including any gaps, as well as providing opportunities for people to form communities of practice and coach common skills and practices. But doing this mean we need to throw out the existing rule book and look at jobs and role form a different perspective

The Sports Team: A Good metaphor for thinking about roles and job functions in the age of uncertainty

6 year old soccer

Who out there has watched their kids play a team sport at a young age. It is certainly a sight to behold, and its alot of fun. Some other truths..

• No one knows how/when to participate
• No one is taking accountability outside of coaches and referees
• Everyone is interfering with each other
• Teams do score! (eventually)

How many of us have felt like we were working in an organizational six year old soccer game? Some evidence you are in a 6 year old soccer game include:

• everyone shows up to every meeting
• everyone is consulted on every decision
• people come and go at random
• lots of overlapping and conflicting effort
• no ownership of outcomes

Table Top

Who out there worked for an organization where management got serious about putting some rigour back into the organization? Likely you ended up with...

• Individuals ending up with very specific job functions accountable to a very specific task
• Lots of documented processes, that no one really understands,or follows
• No one is taking ownership of the end goal, outside of the most senior leaders
• jobs and roles are hard coded, no one changes their role
• The puck is constantly getting stuck in the corner, metaphorically got between the space of peoples job description, so overburdened leaders have to pick it up

How many of us have felt like we were working in an organization where we felt like a table top piece*?* Some evidence you are in a tabletop game include:

• you are told not do do something because it is someone else's job
• no one takes initiative to improve things, because it is the responsibility of some other department
• you get things done by flying under the radar, and begging for forgiveness rather than asking for permission
• lots of departmental protectionism

True Team

Watching a professional team, or even a team of committed amateurs is an entirely different experience.

• Team members have positions, but position changed based on the play
• The team outcomes trumps any concept of role or position
• Interactions between team members trump individual accountability

Most of us actually have solid experience working in this type of organization, even if it's an organization that is outside the workspace. Some evidence you are on a True Team include:

• you dont check if something is in your job description before helping
• you focus on getting to the outcome, not creating deliverables
• Specialists and specialization exists, but specialists train and mentor others on the team and level them up
• Leaders step in to help when required and get out of the way the rest of the time

Jobs and roles done well

Let's assume we are aiming for the True Team model. Let's start by disassemble the traditional job / role spec, and build something new using a few different design principles:

• Define a small number of overarching jobs descriptions made up of lots of narrow and overlapping roles and behaviors
• Flatten the official reporting hierarchy
• Describe roles in terms of interactions with other roles
• Develop people to become T-skilled

A new mental model for jobs and roles

Let's start by by having a less job specifications, alot less. Taken to its extreme we have one Job spec, let's call it employee, in effect this is what an organization like Valve does wen they state they hav no official job or roles defined. A gentler approach would be 3,4, or max 5 different job specification. Each job specification will include many fined grained roles that overlap with each other in terms of behavior. We will try to focus our team behavior as much as we can on team dynamics and interactions with others. Finally we will empower teams to define and refine the roles and behaviors required as needed to meet the context of the team. Dynamism will trump consistency.

So let's take a look at our Analyst example again and see if we can describe the job a little bit differently. First of all we will change the Job title to something a lot more broad, lets call the job Business Specialist.

A business specialist brings structured thinking, facilitation, communication, and a focus on business objectives to the team. The business specialist collaborates with business stakeholders to validate that the work of the team is accomplishing business objectives. the business specialist will work closely with other team members to clarify and validate work meets business needs. The business specialist will often engage closely with real users to gather insight and feedback.

The business specialist can play the role of an analyst (documenting required functionality) , tester (validating functionality), domain subject matter expert (providing expertise on functionality) or product owner (deciding on required functionality), as befits their experience and knowledge. Depending on their aptitude and interest a specialist may start to focus on user experience or facilitating customer insight as a design thinker. The entire team is expected to collaborate with the specialist collectively determine the roles specialist can take on that will best serves the team's goal’s.

Again there are a few concrete things that make this description more useful to an Agile Organization

• Jobs are containers for many fined grained roles that a person has the option to play
• Jobs and role descriptions provide ideas for ways people can collaborate and interact with each other
• Focused on team outcomes
• Are dynamic, and expected to change based on the make up and need of the team

A more comprehensive example using a typical tech product organization

Many readers will be familiar with the following example. A large organization who primarily delivers value through the use of providing software enabled solutions to their end users. This could be a bank, an online retailer, or an organization that ships software to end users. Given that context matters this is an illustrative example only, and not some normative solution that is assumed to "correct" for your technology business.

Three jobs

Let's start by having three jobs max.

• Engineering people that perform the creation and operations of our technology solutions.
• Product people focused on achieving market success with our technology solutions.
• Delivery people that assist and facilitate the delivery of our technology software.

That's it. Every one fits into those three jobs. Every possible permutation of what people can do to create value is slotted into one or more of these jobs. We empower people to flesh out the details in terms of level, behaviours, roles, etc. But official job titles are limited to these three. Many product focused organizations would be more comfortable with only two jobs, product and engineering, with delivery responsibilities being allocated across these two jobs. There is no right answer. Having a delivery "job" can bring some focus for organizations that need it, and is an unnecessary extra category for other organizations that don't need it.

Many Behaviors and Roles

All of the different things people can do are captured as behaviors. Behaviors are identified by people in teams, and required behavior can and will change based on the emerging needs of the team. It is also true that there are common behaviors that can be shared organizationally, at least across a context boundary. I have had good experience in using share definitions of behavior to help create a common understanding of how members of different jobs can achieve team goals. This clarity can be enhanced by loosely packaging behaviors into roles. It's important to note that roles must be used to articulate opportunities for people to create value as part of a team, roles are not used to mandate static boundaries of responsibility.

Here are a set of candidate roles that could serve as a reasonable starting point for our hypothetical example.

Working across a number of clients I have had good experiences using this type of model to get some consensus on what roles could be valuable for member of various members to play across team. We also found some value in sharing a very conceptual model in terms of allocating jobs across for teams to help get team staffing up an running.

I do have to emphasize that allocating team members is rarely done successfully when managed by at the center or top of the organization. That is why deferring exact the definition and allocation of roles and behaviors to the teams is critical.

Also remember these jobs hold a large number of potential roles, roles that can be potentially played by anyone across the team.

Role Personas

One thing I have done with several clients is working with them to elaborate on roles through the creation of Role Personas. When designing these personas we were careful to represent them as stories. Stories of how an individual could decide on when to become this role. Stories of how this role could help others, specifically others in their team, to create value. Stories of how an individual could play different roles. These personas served as a good dialogue tool between people. Here is a template of a role persona, if you find the idea helpful, consider working with your organization / team to come up with your own template.

Here is an example Role Persona I worked on with a client team. It contains some pretty specific behaviors grounded in Kanban and lean thinking. This made sense for their context and what that team wanted to do, again your needs will be different.

A couple of important points. There is almost nothing in this that describes what the role does as an independent individual. Almost all behavior is described in terms of collaborations with others. This is important. If we can't describe jobs and roles in terms of working with others, than we should not write them in the first place.

Also take note of the role navigation. we want many people to play many roles! Taking the time to describe a role does not mean we want one person play that role. So if you are going to describe a role take the time to describe how people can step out into other roles. Again is meant to inspire not dictate.

I worked with one client to map possible ways individuals could navigate roles, this served as an interesting artifact to help people understand the possible path(s) they wanted their careers to take. My experiecen with type of artifact is some people find it helpful, while others find it causes confusion. My advice is try to use this map to help people explore other roles, if it's not helpful than don't spend effort on maintaining this type of artifact.

*Check out the Appendix if you want to explore the remaining role persona cards

Exploring behavioral adjancy across roles

The concept of a role having a set of foundational behaviors, and then a set of adjacent behaviors that are shared across roles is something that i have explored with more than one team. This type of thinking can be valuable if you are in an organization that is in the beginning of exploring how to embrace agile thinking and practice. In this context teams are likely staffed by people who have very hard coded roles / jobs. Individual and management willingness to adopt a model where teams self select roles is likely low.

A safe way to move the ball forward in these circumstances is to encourage team members to refine their job and role description in terms of what behaviors are core to their job (what they are accountable for), and what behaviors are adjacent to others. Try to move as many behaviors as you can into the adjacent bucket. Keep revisiting until the team becomes more comfortable into letting the "play determine the role".

Above all any approach we use to clarifying roles and jobs needs to be done to encourage people to play more roles not less!

Flatten Reporting Hierarchies

Now that we have gone over a good deal of material on roles and jobs. Let's take a few moments to discuss reporting structure. You probably would not be surprised when I tell you I think reporting structure is pretty broken.

In the old world bosses sent coarse instructions to leads who decomposed those and sent them to their senior people, who further decomposed those instructions to more junior folks. A more enlightened view would be to say that more senior people empowered more junior people and delegated work to them. In both cases the principle of work being allocated through the functional hierarchy remains the same.

Performance, recognition of expertise and seniority in the organization are all expressed through the number of people allocated to senior person. This leads to internal protectionism, in fighting, an inability to move people to where the value is, siloing, people not ready for managers in the role..

Use ladders instead of reporting hierarchies

The concept of seniority does not go away in Agile Organizations. Rather the reporting structure attached to seniority does. Think of seniority as a ladder of expertise and competence. The top of the ladder is responsible for capability, community and competence within a functional discipline. Everyone else is placed on the ladder according to experience, expertise and contribution. But everyone in the ladder reports to the top of the ladder, there is no other reporting structure! An even more nlightened version of the ladder is there is no reporting structure at all in the ladder, just levels of experience.

Since I have only read about this I will stick with the version I am familiar with, a ladder with a single reporting structure.

It is important to emphasize that the ladder is not used dole out tasks or assign work!

Work allocation is managed by placing people into teams and asking those teams to self organize. Note that self organization does not imply anarchy or even democracy!

Within a team we expect more junior people to seek the advice of more senior people. Senior people will make the call where agreement can’t be reached. Of course if senior people are constantly overriding more junior people than we know we have a deeper problem to resolve.

People with seniority may be placed in positions where they support more than one team, ie a mission or portfolio, but this is not tied to a level in the organizational hierarchy.

The important idea here is that we have replaced one monolithic and formal hierarchy with many small informal ones. In this environment authority comes from capability and is only loosely coupled to position.

Title can still be used to reflect seniority

I think alot people confuse a lack of reporting structure with an absence of positional seniority. People fear that organizational anarchy will result, with juniors not listening to seniors. My experience is you can remove most/all reporting structure and create a culture of advice / respect where more junior people can and will seek the advice of more senior people. My experience at Deloitte, a large and established consultancy was that the ladder approach can be very effective. Title was still be used to reflect seniority, but senior people did not have anyone officially reporting to them with the exception of partners that ran entire service lines. Reporting structure wasn't needed, there was a culture in place instead. Were there issues? Yes, and paradoxically not enough of them. The issue we struggled with was senior people's opinion still carried to much weight, and we had to really watch how we steam rolled over the opinion people newer to the firm with less experience.

Decouple seniority from role and job

If your organization uses a ladder, avoid having a different ladder for every role / job in your organization. If you can get away with it, come up with one. Use generic descriptions of scope, expertise, and numbers of hats a person can play to provide a common understanding of what it means to advance. Here is an example of one client's work in describing the levels in their organizational ladder.

While some roles can be perceived as being more senior than others, avoid pinning role to levels, providing only a loose association between the two concepts if required when working with an organization just beginning the move to greater agility. Agan an example from a client where I was personally surprised that team members actually wanted to understand how different roles mapped to seniority within the organization.

A Note On T-Skilled People

A big emphasis on this type of approach is we want to grow cross functional individuals inside of our cross functional teams. We want people who can play more than one role, playing to score rather than just playing to a position. This concept applies to more than just the roles they play but the expertise they acquire. People often mistake this for thinking that everyone needs to be a complete generalist to be in a cross functional team. The reality is that people can and should dedicate most of their expertise to some form of specialized knowledge.

The trick is that as people become more senior we want them to gain deep knowledge in one or two areas while at the same time expanding their area of expertise at an introductory / intermediate level across a number of other knowledge areas. We want domain experts to get cursory knowledge outside their core domain of expertise. We want delivery professionals such as a tester or an analysts to gain experience across the entire life cycle. We an developers to be able to contribute code across the full stack. We want product people to work in operations, and operational folks to learn how to create product features.

In other words, we want to encourage the development of T-Shaped People. Your knowledge literally expands deep and wide, like a T. Perhaps a better description is helicopter shaped people. We want people to go wide in a number of directions. Your depth of expertise still matters, it is the platform for you to teach others on your mission the fundamentals of what you do. To help others get enough knowledge to at least pitch in and help when necessary. But the value of an individual's depth is severely curtailed if it is not being used to pair and teach others.

I have worked with teams to inventory the skills they needed to be successful along a number of "helicopter blades". Each blade represented a different dimension of expertise, blased were divided into segments. each segment was a particular skill the team needed. Team members self assessed their expertise to determine where they could expand their skill sets.

An interesting offshoot of this idea is when the team agrees that experts are not allowed to do work they are experts at, they must pair with other members of the team who do not have knowledge in that area instead. This is an idea I borrowed from Jabe Bloom, who introduced the idea to me. You encourage teams to reduce the number single-specialists bottlenecks with this approach.

Are you looking to make your enterprise agile?

Our services—leading-edge organizational design, first-class change consulting and immersive training and coaching—will ensure that your agile transformation is a successful one. Click the link below to request a free consultation..