What is the liaison model
A liaison is a person who serves as a coordinator with another team or group of teams. They attend relevant meetings, and share context in both directions.
For example, product marketing has a dependency on engineering, product, and design. Product marketing needs to know many things to market to customers:
- When the team will deliver the feature.
- What benefits the feature provides.
- How the team talks about the feature.
- What terms the team is using.
- What the feature will look like.
- How the feature will fit into the existing offering.
The liaison model can be very effective in this situation. You attach a product marketing person to a team or set of teams. They attend meetings and learn the context they need. And they also share that context back with their organization.
When to use this model
A liaison is one of the best coordination models to use when you meet these constraints:
- You are coordinating with another part of the organization.
- That part of the organization comprises a team or set of teams.
- You believe the liaison will be stable. They won’t have to move around between teams.
- Your need for context is more than minimal. If you can replace a liaison with notes from a meeting or an email, you don’t need a liaison. If the meetings aren’t sharing a lot of context, it’s wasteful to have a liaison.
- You won’t exceed the rule of eight. Attaching a liaison adds a person to the meetings they attend. You are adding a cost to the meeting and making it more complex. If the meeting gets too big, you have to restructure the meeting or choose another model. I’ll write a post on scaling these models later — there are patterns you can follow for this.
- There is a natural way in which your people fit into other teams’ meetings. You should have a direct need for context. You are misusing this model if you sprinkle liaisons in many places. If you feel a need for liaisons everywhere, you might have other problems. That can be a sign your company has bad information flow. Look for signs there is something structural at work.
One of the advantages is that it is inexpensive. Using a liaison only requires a few meetings a week for one person.
You can scale liaisons as the organization grows. For example, our product marketing department might assign a liaison per product line. These product lines map to engineering teams or organizations. When the company introduces a new product line, you hire a new product marketing person. This person is then attached to the new engineering group.
When using this model
- Make sure people understand what the liaison is doing. Using our example, many engineers don’t understand product marketing. They will have no idea why a product marketing person is at the meeting. When you add a liaison to a meeting, tell everyone what their needs are. Explain why they are there and what information they need.
- Use the existing hierarchy if you can. When you map your liaisons to other departments, use the existing hierarchy. If you don’t, you make the organization complex. I have seen situations where there are three or four mappings and hierarchies at the same time. Using the existing hierarchy reduces complexity during reorgs.
Liaison versus other coordination models
A liaison is a limited version of the embedded model. When you need deep context, use the embedded model. When it makes sense to work together, prefer the embedded model. If your need for context isn’t significant, use the liaison model instead.
When you want someone to be available, a rotation model can be preferable. Rotations build less context. They also share the burden of being available better.
A collection of liaisons from many places forms a centralized liaison. For example, a group of technical leads might form a technical leadership group. Each team contributes a technical lead. The technical leadership group then shares information and coordinates with each other.
- Use liaisons with product marketing.
- Use the embedded model or liaisons with security.
- For support teams, use liaisons. Embedded support engineers would be a good experiment. For engineering teams, engineering rotations with the support liaison create a natural pair. This pair can triage and sometimes solve customer problems together.
Any important advice I missed? I love feedback.
If you liked this post, subscribe to hear about future posts!
Liaisons are just one of many coordination models. Coordination models give you a menu of choices to choose from when solving your leadership coordination issues.
Comments powered by Talkyard.