Working together is the best -- the guide to happy embedding

What is the embedded model?

Companies need specialists. And specialists often do their work with people outside their department. For example, all these specialties work with software engineers:

• Designers
• Product managers
• Site reliability engineers (SREs)
• Quality engineers (QA)
• Application security engineers
• and Architects

Specialists often apply the most leverage when they work next to engineers. For example, an SRE might help a team improve their monitoring. They might help even more if they help the team to understand how to do monitoring themselves. A designer might work side by side with an engineering team. They design future features, and collaborate on current features.

One way to structure this relationship is by embedding these experts on teams. They still report back to a home team of specialists, but spend almost all their time on another team. This is the Embedded Model of coordination.

Sometimes you might embed an expert on several teams. Or you might embed them in an organization. For example, you can embed a QA engineer with a Director. This director will have several teams they support. The QA engineer can then help improve quality across this organization. When doing so, they might focus on the top priority project. Or they might rotate between teams.

When to embed

• Embedding can be one of the best coordination models to use. It is appropriate when you want specialists to collaborate within a team. I like embedding designers, product managers, sometimes SREs, sometimes architects, and sometimes QA.

Embedding can be the easiest way to add specialist skills. In some organizations, you are not “allowed” to hire specialists into your organization. For example, an engineering leader can’t hire a designer into their team. Embedding allows you to get around this. See later in this post for a discussion on this.

• The embedded person’s work should be mostly aligned with the existing team. It only makes sense to use embedding if you need collaboration. Embedding increases context, collaboration, and relationships within the team.
• You can only embed up until a maximum team size. If the team already has eight or nine people on it, you need to split the team, or not embed. This count includes other embedded people.

The embedded model scales well with the growth in teams. Each new team gets a new member. It does reduce the maximum team size by one. A rule of thumb is that the specialist team member should add more value than a generalist would.

• You are tying company investment to be proportional to the growth of these teams. That can be good, or bad. Many supporting organizations should grow slower than the growth of teams. They need to become more efficient over time. Other specialists should grow at exactly the same rate as engineering. Embedding makes the most sense when the growth should be at the same rate. Embedding makes these growth plans part of the structure of the organization. If you know every product team needs a product designer, then that is a good thing. You know that the plan will account for those hires.

Sometimes specialist teams should grow slower. For example, a security team should grow slower than a proportion to engineering. They won’t achieve this goal with embedding, so other approaches might make better sense. You can still use embedding, but it should be temporary.

Hints to embedding well

• You may need a central team. It’s common to need a centralized team even while embedding. This team is usually small.

For example, a design organization might embed, but have a central team or two. This central team can work on a design system, or design research.

An SRE organization might have a central SRE team as well. This team can work on standardized tooling, and provide reliability information. (See my upcoming post on objective experts). This works together with embedding.

This sort of pairing is natural. You may or may not need it to start. But you usually end up needing both.

• Support the home team too. Embeds maintain split allegiances. Embeds need support on both teams. Some people tend to make stronger attachments on their work team. Other people tend to make stronger attachments with their home team.

Encourage embeds to view their work team as their primary team. But don’t neglect the home team. Home teams can share practices and information among specialists. They act as a Community of Practice that can spread expertise throughout the company.

• Don’t shift people around too frequently. Part of the value of these long-term pairings is you build relationships and context. It is expensive to move people because it breaks these connections. Most embedded organizations tend to move people more than they should. It can be frustrating to have embeds on your team if you can’t rely on them to stay. Yet it is tempting for the embed’s manager to move people around. They want to react to changing needs, and sometimes there aren’t enough people to go around. This can be a source of friction.
• Negotiate how it works and take care onboarding. A new embedded person has a more complex situation than new employees do. They have another manager, and things outside your team they may be paying attention to. Kick off the relationship with explicit conversations. Spend twice the care you would with onboarding a generalist employee.

Gus Shaffer offers this advice: “One thing that I found helpful when embedding staff engineers was to conduct a standard Kick-off process with a Statement of Work as output. Early on I learned the hard way that leaving success criteria loose leads to lingering engagements / disappointment / confusion.”

• Be clear who directs their work. When negotiating an embedded situation, decide who directs their work. It can cause problems if both the home and work team managers assign work. This makes their output less predictable. Even worse than that, it causes surprises because it seems predictable until it isn’t. This can make it hard to depend on the embedded person.
• Clarify what type of work they’ll be doing. Another thing to be specific about is the type of work you’re expecting them to do. For example, is the SRE joining the team to do operational work? Or are they there to help the team get better at operational work?

Many companies focus on cross training and T-shaped people. They do this to create more flexible teams. And they see value in spreading that skillset within the team. If you can, make it explicit that the specialist won’t do all the work. The goal is for them to help the team get better at that type of work. This won’t always make sense. Team members can’t internalize every specialty.

• Good role definition can help clarify expectations. Develop role definitions. Review expectations when they join the team. This will help both them and the team know what to expect.
• Maintain good communication between managers. If you’re the manager of the embedded person, check in with the manager of the team your person works with. Set up a regular cadence for checking in. It’s good customer service, and it’s also vital so you can offer good feedback and coaching to your direct report.

For the embedded person, they are living in a sort of matrix-managed world. Although they don’t have two managers, in practice it can feel that way. They attend two sets of meetings. And their manager isn’t seeing their work.

As a manager of an embedded team, make sure you have a way to assess your team members’ work and coach them. They need career development and support like any other employee.

• Be careful of meeting load. Embeds will often have a higher meeting burden than other individual contributors. The easiest way to handle this is to keep their home commitments light.
• Watch out for embedding with multiple teams. Embeds with multiple teams have an even more complex situation. They have three or more teams they’re a part of, and they have a lot of relationships and complexity to navigate. It’s usually best to pair them with the organization’s leader. That way, the org leader can direct their work. This can help simplify some of the complexity they’re dealing with.

When you don’t align an embed with an org leader, it can get complicated. When a reorg occurs, you’ll have to do your own reorganization. Even if less optimal, keep your organizational design aligned with the embed’s organization. I’ve seen reorganizations with three separate hierarchies. It was a complete mess.

Embedded versus other coordination models

Single threaded owner: why embed when you could hire that skill directly on to the team?

One way to handle embedding is to take it even further and actually put the embedded person on the team. This has a lot of advantages, and some disadvantages as well. I wrote up an experience report on this model inThe Single Threaded Owner model. See it for more details. It’s arguably a better approach. You should combine it with a strong Community of Practice (post forthcoming). You also need good role definition and career ladders.

Usually, you won’t have the latitude to do this. The designers will need to be on the design team. If they aren’t serving you well, you may consider hiring a designer onto your team. A sneaky way to handle this is to hire an engineer who has a design background or who is design-focused. Doing this as an organization can be difficult, so it’s often a one-off approach.

Merged group: let’s do DevOps!

You can combine departments that historically passed work between each other. The classic version of this is to combine developers and operators. Eliminating the departments and having them on the same team improves flow. This approach is like the Single Threaded Owner model, but less extreme. You’re not doing it for every specialty, but one.

This has similar tradeoffs, so read the STO model post for details.

Service provider: have them come to you instead?

I generally prefer embedding to a service provider approach. Most service providers lack the context and relationships to collaborate with teams.

Prefer the Service provider model when you want to scale your organization slower than the organization you’re serving. It’s also preferable if you offer a service where you don’t need much context from the team you’re serving.

Liaison: I don’t need to actually WORK with them, just want to spy on them

If you’re just gaining context from them, you don’t need a full blown embedding regime. Just use a liaison, and attend their meetings. Make your home team your main team.

Rotation: when context is less important, or you want to share the burden

If context is less important, a rotation may be preferable. This doesn’t build as deep of connections between people, or ease communication as much. But it does share the burden, so it can be useful if parts of where you serve are really hard work or are uninteresting. Some teams may also enjoy the variety of a rotation. Stay tuned for a post on this.

Objective expert: give the central team leverage!

When pairing the embedded model with a small centralized team, it can be useful to have the central team use the Objective expert approach. A reliability organization might have a central SRE group that is in charge of reporting on reliability for the organization, broken down by team. This can drive a lot of work in other teams. I love this approach, and will write more on it soon.

Coordination models

Embedded is just one of many coordination models. Coordination models give you a menu of choices to choose from when solving your inter-team coordination issues.

Feedback

See anything I missed? Disagree with this? Please let me know your thoughts!

Also, I blog about these topics at https://www.rubick.com

Thank you

Gus Shaffer provided a lot of feedback on an earlier version of this post, and had some good suggestions on how to embed effectively.

Image by PublicDomainPictures from Pixabay