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

By Clay Parker Jones profile image Clay Parker Jones
Updated on
Org Pattern Language