As an organizational leader, you’ll be faced with many situations where the solution will be to improve the way people work together.

Today, I’ll list some coordination models you can use to address these situations. These models 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.

In future blog posts, I’ll go much deeper on each of these models, so you can develop a sense of when to apply each model. Any of the links you see already have blog posts that describe this pattern. Let me know if you have any you’d like to see sooner than others — I don’t have to go in order.

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. Track numbers to drive particular outcomes, add observability, or force attention to an area.
6. Centralized/decentralized prioritization. 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. A role that runs programs (projects containing projects) and coordinates efforts across teams.
2. Integrator. A role that solicits information from a broad variety of sources and synthesizes them into prioritization and plans.
3. Controller. A role that has explicit authority to demand behavior in a particular arena.
4. Standard definer. 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.
2. Self-service. A team offers its work product without requiring other teams to collaborate with them.
3. 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.
4. Liaison. An individual serves as a communication channel with a team or group of teams.
5. 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.
6. Single-threaded-owner. A team where all the cross-functional contributors (most commonly engineering, product, and design) all report to the same manager.
7. Centralized liaison. A variation of the Liaison model, where you have representatives from a number of teams form a working group.
8. Merged group (aka DevOps pattern). Two groups that previously passed work between each other are merged.
9. Task force. Temporarily create a merged team that focuses on a particular outcome, maximizing short-term collaboration.
10. Objective expert. An expert or group of experts produce measurements or reports that help visualize problems, to drive behavioral changes.
11. Cousin team. Change the management hierarchy so teams that need to collaborate have the same Director.
12. Community of practice. Support specialists across cross-functional teams by creating a group that shares information and practices, and often defines standards.

More detail coming soon

I realize this doesn’t include much detail on any of the patterns. I’ll be sharing more detailed posts on most of the above patterns. Please let me know if you see any patterns I’ve missed, or would like to hear more about any of these patterns.

I’d encourage you to subscribe (using the link in the upper right) if you’d like to be notified as I post more information on each of these patterns.

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 Gus 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.

Image by Pexels from Pixabay