Subscribe! It's free.

Join >690 folks who use these tools and ideas (everything here requires registration; it’s your call if you want a newsletter about it).

Subscribe
Role-Based Team Structure
By Clay Parker Jones profile image Clay Parker Jones
6 min read

Role-Based Team Structure

Role-Based Team Structure is the best way to articulate expectations for your team. It provides durability, flexibility, and clarity. It builds a playbook for running your team. But perhaps most importantly, it helps divvy up the work in a more equitable, sane way.

Why use this?

Role-Based Team Structure is the best way to articulate expectations for folks on your team. It provides durability and flexibility in equal measure, spells out the basic building blocks of a playbook for how your team operates, and gives real clarity that goes beyond whatever your job description said two years ago. It's fast and fun, and will highlight any gaps that need filling. But perhaps most importantly, it helps divvy up the work in a more equitable, sane way.

What is Role-Based Team Structure?

It's a way to turn the work the team has to do – whatever that work might be – into a set of defined Roles (rather than projects, workstreams, or department names like "legal" or "finance" or "creative"). This gets done in a couple different meetings or sessions. 

It's important to emphasize that this is a way to do this. It's not a recommendation for a particular structure of a team. Instead, it's a recommendation for how you get to that structure, and a particular way to express (write down!) that structure.

Alternatives

The boss just tells their direct reports what to do. On some teams, this happens daily, through a standup and assigning tasks. On others, it happens monthly or slower, through the assignment of projects. With a phenomenal "boss" (in quotes here because the Real Boss isn't always the person with positional authority, but could be someone like a Project Manager, Product Owner, or Scrum Master), this can work well for many people, but it's designed around a single point of failure. When the organization needs to grow, or the boss needs to focus on something different, all of the knowledge is locked in one person's brain. When organizations talk about growing pains, they're usually talking about this.

No structure at all. We're all just individual folks, showing up from different departments, hoping for this project to love us. Who has say over what is largely determined by tradition, political pull, historic/structural biases, or whoever's feeling particularly confident/bold on the given day. This might work in the best possible conditions, but, it's pretty obvious how this breaks down: without a mutually agreed structure, we're probably going to end up prioritizing those that have been in power in the past.

RACI. When done well, RACIs cover key, sticky activities and decisions (not everything that a team does) and identify who actually is Responsible for making the call. I've never seen a team actually use one in practice. Somebody please reach out if you have.

Downloadable Templates

Explainer

Step 1: Get clear on the mission for the team

This works best if you have a clear, consequential mission or purpose for the team. Especially in larger organizations, teams don't have permission to write their own mission or purpose, so doing this prep may require going to the next level of authority in the organization above the team, and asking them for clarity on mission. A few things to ask the next level of authority, or to interrogate for yourself as a leader:

  • Given the department’s overall purpose, what outcomes is this team accountable for? 
  • If we are successful, what will happen?
  • What outcomes are we trying to achieve?
  • How does the work support the broader mission of the organization?
  • How are we measured, and how does this team contribute to those measures?

Step 2: Capture the work to be done

Write down all of the work that the team needs to do (not just what it’s doing today) in order to achieve the mission. Try to break down the work to a task level. As an example, "Scheduling flights for vendor assessment" is better than "Travel," and "Selecting which content gets presented to execs" is better than "Exec decks."

When you do this right, you're going to have a lot of tasks. The best tool we have for capturing a team's full scope of work is a spreadsheet – not post-its or Miro boards. You're looking for ease of manipulation – clustering things, tagging things, adding richer data to a bunch of tasks at once – and spreadsheets make this dead-simple. My preference is a Google Sheet, but a Notion Database, or Airtable...table will work well. Ideally, assign this prep work to each individual person on the team, and have them put all of their individual work in a single document. It's easier to cover all the ground on this task when you have a bit of space to think by yourself.

Especially for the corporate teams out there, there are a handful of "kinds of tasks" that you don't want to forget. Use these as prompts when you're capturing work:

  • What do we do to serve our customers?
  • What work is required to guide other teams or direct reports?
  • What goes into our team's partnership with other firms?
  • How do we surface data to leadership?

Step 3: Group the work into roles

If you're working in a spreadsheet, the fastest way to do this is to go row-by-row and tag them all with a brief handle. This is where you can start using broader terms like "Travel" or "Exec Decks". When you're done tagging, do a quick alphabetical sort based on the row that contains all the tags. Patterns should emerge.

If you want to do this as an in-person workshop, transpose everything from the shared spreadsheet onto post-it notes, and as the group to cluster related work. Consider clustering based on customer type, functional category, or required expertise. Patterns should emerge.

After you've tagged or clustered, you need to name each group. Once you name these clusters, you've got your starting set of roles. Naming roles is probably worth breaking down in a separate guide – semantics are important! – but to start, try using a pattern that begins with [Function/Capability/Workstream] and ends with [Style or Involvement]; Finance Guide; Strategy Adviser; Partner Liase-er; etc.

Step 4: Add meaningful definition to the roles

To start, just rewrite the rows in the spreadsheet to follow a common format, where each row begins with a verb. These form the starter set of expectations for the roles you just named.

Some of the expectations will begin with a very special verb: deciding. Look out for these – they can form the backbone of clear decision-rights on the team. When you assign one of these expectations to a role, try actually letting that role make the call for a short while, rather than trying to involve everyone on the team.

Step 5: Assign people to the roles

Allow multiple people to fill a single role, and allow individual people to fill a variety of roles. This makes each individual role, and each individual expectation, a little less important, and a little more collective. This is good up to a point: it encourages a more robust discussion of what's Actually Important for the team, but can lead to If It's Everyone's Job, It's Nobody's Job-Itis. When you notice the latter creeping in, take that as an invitation to break down a role a bit further to get more specific about authority and accountability.

On a traditional team, where there's a clear team lead, this is the moment for the leader to step forward and use their positional authority to do the assigning of people roles. It can be helpful to set a reasonable time-limit to these assignments. Try quarterly time-limits to start.

On a more collective team, without a clear leader, try the Election process.

Examples

Just a handful of examples from a real project
By Clay Parker Jones profile image Clay Parker Jones
Updated on
Org Pattern Language