Photo via https://unsplash.com/photos/ugm-yDj9Hi4

Consider these two schools of thought for how a product company might structure its teams:

#1 — Project Teams

In a project organization, individuals from different departments are assigned temporarily to projects (shocker!).

Project members contribute temporarily until the project is completed, usually at a pre-determined deadline. Individuals may work on multiple projects at a time and may rely on others in their department to produce their share of the work.

#2 — Product Teams

In a product-based organization, designers are distributed into product teams. These teams — sometimes “pods”, “squads” or “scrum teams” — support a particular product or product area indefinitely.

They exist independently of organizational silos and have minimal dependencies on others from outside of the team. Product teams tend to be more conceptually aligned with agile practices.

Reality doesn’t always break down cleanly into one of these two categories, but it’s still a useful dichotomy to consider.

Now, let’s say that you’re a designer in an organization that already has partial product teams.

Engineers, QA, and Business/Product leaders are organized into dedicated teams that are aligned to certain product areas.

However!

Designers aren’t totally committed to those teams— they aren’t embedded. Instead, they still follow something closer to a “project” model. Teams request design help when they need it, designers are dispatched, and then when they’ve finished a set piece of work their allocations are renegotiated across the teams. The design team proudly boasts that it operates “like an internal agency”.

I suspect this is a pretty realistic scenario! UX groups and practitioners often seem to be hesitant to fully get on board with an embedded model.

But is that a mistake?

I’d argue that it is.

Product teams are already overwhelmingly the norm — especially in startups and tech companies. So I think it makes some sense to examine the value a designer could expect to achieve by fully becoming a part of them.

What exactly does it mean to be embedded?

If you’re having trouble picturing what being embedded might actually look like, here are some things you might expect to see:

• Designers attend most or all of the core meetings or ceremonies of the team. This includes things like retrospectives, daily stand-ups, and review or planning sessions — even if the core focus of those meetings are not solely related to design.
• Designers spend the majority of every day working alongside the other members of the product team and are physically or virtually co-located. Interaction between team members is not limited to discreet meetings, handoffs, or checkpoints, and most communication is direct — without the use of any intermediary person or process.
• Designers share responsibility and accountability for all aspects of the team’s collective output, not just design.
• Designers are generally not required to check back with anyone in their organization for approvals or permission. The only people who need to be aligned around a solution are those within the product team.
• Designers might only support a single team, and they do so indefinitely. They tend not to be shuffled around too often.

So if you can’t easily list the names of every engineer on your team, only go to the meetings that focus on your own work, and need to get approval on all of your designs from your manager before showing it to others…

…you’re probably not working as an embedded designer.

What are the advantages of the embedded approach for designers?

You gain a deeper understanding of the problem domain

Do you love joining a team, shipping some work, and then immediately moving on to the next thing before you’ve fully understood how well your solution succeeded or failed?

I sure don’t.

I prefer having the space to learn from my decisions and the time to iterate based on the things I’ve learned. Without that space, you’ll never actually know if you’re getting any better at what you do.

When you’re part of a team indefinitely, things like user research and experimentation become even more valuable. Individual insights compound over time because each thing you learn can be continually referenced and built upon in the future.

You aren’t rediscovering the same things that have already been discovered over and over by designers that came before you but instead pushing deeper into more specific and nuanced aspects of the problem domain.

Your ability to work with the team increases exponentially

Working with people can be hard. The longer you work with the same people, the easier it gets.

Having time to understand your coworkers can make it much easier to build consensus, collectively evolve your process, and figure out how to get things done together. An embedded model offers the space and stability needed for interpersonal relationships to flourish.

Otherwise — if team members know they’re only going to be together temporarily — they may not invest as much effort into improving the relationships, processes, and dynamics within the team.

Being embedded also helps others to think of you as actually being a part of the team in the first place. This mindset shift helps to avoid the “us vs them” mentality between different departments that are all too common in corporate environments.

You get more access to other parts of the software development process

Increased closeness to engineering also affords more input and awareness when it comes to things like architectural decisions, technical constraints, or implementation details — which all ultimately have a huge effect on user experience.

This increased access also opens up the ability to contribute to other areas of the product that might have previously been harder to get at. You may find you have more opportunity to be involved in things like UX-writing, quality assurance, or data science.

While this kind of collaboration and flexibility can happen in a centralized design team, it will likely be more limited — occurring at discrete points like meetings or review sessions instead of continuously and all the time.

The rest of the team gets more access to the design process

The flip side of getting more access to the expertise of others is that you can bring others deeper into understanding your own work.

When you sit on the team as a designer, other team members get more exposure to user-centered thinking and practices. Things like usability best practices, results from user testing, and detailed design rationale get much more visibility.

Over time, as you prove the value of your work, you’ll create stronger advocates for that value. Engineers, testers, and product people with more UX knowledge will be in a better place to contribute towards desirable user outcomes.

Better alignment enables better productivity

If you’ve worked for a while in a centralized model you’ve probably experienced a time when a person or group complained about “not being brought in early enough”.

To fix this, everyone probably agreed that in the future they should be involved at a certain point more consistently. But this is only a half measure that avoids really fixing the problem — a systemic lack of alignment.

With an embedded team, you don’t have to spend any time thinking about when to include certain people. Everyone that’s necessary for doing the work is “in” all the time.

This means less time selling, looping people in, and getting approvals and more time getting things done.

Your department can spend more time on the things that matter

If you support the same team indefinitely, then you significantly reduce the friction that comes along with any type of intake process. Teams don’t need to petition you for every individual ask since you’re already aligned to them.

Managers can spend less time checking in with people about their capacity and shuffling them from project to project. The effort previously spent on logistics and project management can be realigned to enabling and empowering individual designers.

Addressing common concerns

These are some legitimate and a few not-so-legitimate concerns that one might have with an embedded model, but even the legitimate ones can usually be mitigated.

What if we don’t have enough designers to support all of the teams?

1. Splitting a single designer across multiple teams indefinitely doesn’t totally count as embedding but it’s still probably a lot better than shuffling them around all the time.
2. You don’t have to embed all at once. You can start with one team and see if you get better outcomes. If you do, then you have a strong case for hiring more designers for the other teams!

What if the teams don’t have enough work for a full time designer?

If UX design is only a very occasional need and rarely a blocking dependency then you may not need an embedded designer, but I think this is pretty rare for most product teams.

If it happens frequently then it may be a clue that the teams were not properly built around supporting full stack features or products in the first place.

More often, you’ll hear this concern expressed when there is a significant amount of UX work that actually would be a blocking dependency, but there is skepticism that the work will really take up 100% of someone’s time.

Even supposing that the workload hasn’t been underestimated, these arguments still don’t hold up.

A designer with more “down time” has the bandwidth to do things like explore a broader set of options, do additional research, or look further into the future.

They can make more robust prototypes. They can lean in to other types of work like backlog management, process improvement, or product strategy.

They can use the extra time to contribute beyond their immediate team (like contributing to a design system, running a training, or critiquing someone else’s designs).

And if they end up with a little extra free time even after all that then.. so what? Shouldn’t we be optimizing for alignment and better outcomes instead of just trying to make sure everyone is maximally busy 100% of the time?

What if designers don’t know how to work in an embedded way?

Some designers may have trouble adapting to the more agile way of working that product teams necessitate. The question of how to integrate design work into an agile cadence is distinct from the question of how to embed designers and is out of the scope of this article — but I plan to write more about that soon.

What if our product teams aren’t quite there yet?

It may be completely possible that your organization’s product teams are missing elements they need to be effective. Maybe they aren’t truly empowered, they aren’t funded indefinitely, or they have low Agile maturity in some other way.

These are certainly large problems, but how will they ever “get there” without help? They certainly can’t ever be cross-functional if designers can’t commit to joining them! Agility isn’t all-or-nothing so much as a spectrum where there’s always room for improvement.

Does the design department lose the ability to enforce consistency across different areas?

The good news is that a design system team (structured like any other product team) is by now a pretty established solution to the problem of cross-team consistency.

Sometimes this concern is less about actual consistency though and more about the political power of the design organization.

In reality, the increased effectiveness of design should grant the department more clout, but even if this wasn’t the case wouldn’t a decrease in political power still be the right move if it resulted in better outcomes for users?

Won’t designers be lonely? 😔

When you’re a sole designer within a product team, you can sometimes feel a little isolated or disconnected from your practice. One huge step towards addressing this is to have at least 2 people per team with a design skillset, but in lieu of that a “community of practice” can help.

Designers should be able to seek feedback easily and have a place to return to for a discussion of their craft, but this doesn’t need to be tightly coupled with their day-to-day product work.

Final takeaways

Whether you’re involved in organizational leadership or working at an individual contributor level, understanding the benefits of an embedded model is probably going to help you be more effective in your role — even if you don’t fully agree with me that it’s 100% way to go.

If you do agree, then know that not everything needs to happen all at once. You can still take a look at how you’re operating and ask if there’s anything you can do to move in the right direction.

Maybe designers could be spending more time with engineers? Maybe they could be aligned to fewer projects for longer periods of time? Can you find ways to reduce their dependencies on others outside of the team?

While transitioning overnight may be a challenge, taking a few small steps in the right direction is always a possibility.