Coordination models - tools for getting groups to work well together

As an organizational leader, you’ll face situations where you need to improve the way people work together.

This is a list of coordination models — approaches you can take to coordinate the way people work together. They are very much like tools in a toolbox. You want to have a lot of familiarity with the tools you can use, and which tools make sense in what situation.

I am writing longer posts on each of these coordination models. The links below are to those posts, and to drafts for future posts.

How to use these coordination models

I’ve put these models into three categories:

1. Use centralized coordination models for problems that are global in scope, and have to do with alignment and the ability to coordinate the entire system.
2. Use role-based coordination models for the limited cases they apply.
3. Otherwise, use team coordination models.

Centralized coordination models

As we discussed in my last post, you should centralize coordination and goal-setting. These patterns are appropriate for achieving better global coordination and alignment.

1. Product strategy. A written strategy which outlines the environment and way forward.
2. Standards. Rules that define guardrails in team behavior and force conversations about non-standard choices.
3. Tenets. Mental shortcuts to help people globally make tradeoff decisions.
4. Goal frameworks. A way to set goals that attempt to be coherent across the organization, and translate across the functions to coordinate work.
5. Metrics — early draft. Track numbers to drive particular outcomes, add observability, or force attention to an area.
6. Product council. Cut through cross-team projects gridlock by providing prioritization for critical projects and a way to break ties in prioritizations between decentralized teams.

Role based coordination models

These coordination models are limited in scope, so use them when appropriate but don’t overuse them. I’ll write more on applicability as I write deep dives.

1. Program manager — draft. A role that runs programs (projects containing projects) and coordinates efforts across teams.
2. Integrator — early draft. A role that solicits information from a broad variety of sources and synthesizes them into prioritization and plans.
3. Controller — early draft. A role that has explicit authority to demand behavior in a particular arena.
4. Standard definer — draft. A role that defines guidelines and guardrails that constrain behavior that can be done without discussion.

Team coordination models

Team coordination models are the models you turn to most regularly. Familiarize yourself with all the different models, as each is a tool you can use for particular situations.

1. Service provider. A team has a valuable skill or service they provide to other teams (and those other teams depend on them to succeed).
2. Consultant — early draft. A consultant is available to help guide other teams to make better decisions or learn faster. They are never a hard dependency for other teams’ work.
3. Self-service. A team offers its work product without requiring other teams to collaborate with them.
4. Independent executor. A team produces customer value without collaboration with other teams. They may make requests of other teams, but they don’t rely on those requests being completed.
5. Liaison. An individual serves as a communication channel with a team or group of teams.
6. Embedded. An individual has a source team, but spends the majority of their time working in another team and is treated like a part of that team. A variation of this is when the individual is associated with multiple teams or an organization, and they do work for those teams, or move between them.
7. Single-threaded-owner. A team where all the cross-functional contributors (most commonly engineering, product, and design) all report to the same manager.
8. Rotation — draft. A variation on the Liasion model, where a person from a team (or set of teams) takes on a role for a defined period of time.
9. Centralized liaison — draft. A variation of the Liaison model, where you have representatives from a number of teams form a working group.
10. Merged group — early draft (aka DevOps pattern). Two groups that previously passed work between each other are merged.
11. Task force — draft. Temporarily create a merged team that focuses on a particular outcome, maximizing short-term collaboration.
12. Away team — draft. Part or all of a team does work in another team’s area. Lasts for the duration of a project.
13. Tiger team — early draft. A long-lived team that does work in other team’s territories (and that’s how they are defined, as a boundary-less team).
14. Objective expert. An expert or group of experts produce measurements or reports that help visualize problems, to drive behavioral changes.
15. Work demander — early draft. A team demands work of other teams, and they have to do the work.
16. Cousin team — early draft. Change the management hierarchy so teams that need to collaborate have the same Director.
17. Community of practice — draft. Support specialists across cross-functional teams by creating a group that shares information and practices, and often defines standards.

More detail coming soon

The linked in posts include more detail on each of these patterns. The posts with “draft” or “early draft” next to them are links to the Google Docs where I’m working on my writeups for those patterns. Please comment on those drafts if you’d like to see more detail — that helps me see the demand for it, and also see where things are missing. I define “draft” as not done but possibly useful. I defined “early draft” as likely not useful.

Also please subscribe to get notified as I post final versions of these coordination models!

Thank you

Early versions of this blog post were becoming a full-on book. I’d like to thank all the people who contributed their thoughtful feedback: Brent Miller and Robert DiFalco had excellent critique of the structure of this post. Due to their help, I ended up writing a lot of content that will be broken out into a lot of different posts, so it might be difficult to thank everyone correctly for the parts they contributed to. I’d like to thank Matthew Finlayson for pointing out the need to clarify how to use tenets, Seth Falcon for pointing out areas where my language use wasn’t clear, and Keizan Shaffer for pointing out the costs and challenges of doing a Community of Practice well, and sharing helpful advice for doing self-service and embedded models well. Thank you Michael Stahnke for suggesting I include more detail on how to think about tradeoffs between the patterns. Finally, I’d like to thank Jim Shore for introducing me to many of these models, especially the Product Council and Self-Service models. Thank you to Gustavo Aguiar for pointing out some awkward language. Finally, I’d like to thank Charity Majors for amplifying this post. I get so much pleasure from people finding these posts useful, and she’s brought a lot more attention to these topics.

Image by Pexels from Pixabay