This post is based on chapter 4 of the book “Org Design for Design Orgs: Building and Managing In-House Teams,” by Peter Merholz and Kristin Skinner. Overall, that book is one I’d highly recommend to anyone who leads design, or anyone looking to be a design lead. This is just my interpretation of a small piece of it. 

The book covers everything from design organization best practices, to team roles, to recruiting, to professional growth, and more.

Where should design go?

As companies come to understand the value of design, more are adding and growing their in-house design teams. However, companies are not always clear on how to gain the most value from these design teams. Where should these teams sit in comparison to the rest of the company? How should they be organized?

Merholz and Skinner have explained two common models, and recommended a model that seems to combine the best of both worlds. 

Common Design Team Models

Historically, there have been two common models for how design teams were organized within a broader organization:

Centralized internal services

and

Decentralized embedded designers

While centralized internal services used to be the most common model, they have mostly fallen out of favor in recent years as Agile methodology has become more popular. 

Pros of centralized internal services:

• Internal design community, culture, and lines of authority
• Designers get to work on a variety of projects
• Designers work together to ensure a consistent user experience, which also creates efficiencies

Cons of centralized internal services:

• Disempowered designers, who are frequently brought in too late just to ‘color in’ what’s already been built
• Can create ‘us’ vs ‘them’ mentality, i.e. designers vs everyone else
• Priority of work may be unclear; departments requesting design assistance may be frustrated with lack of response

Decentralized embedded design teams have become more popular alongside the rise of Agile. This is also a more feasible model for smaller companies, or companies with only one or two designers.

Pros of decentralized embedded:

• Designers are able to better collaborate and cooperate with devs at speed, which is particularly critical in Agile
• Designers are more engaged as full team members throughout project lifecycle
• Improved designs, as designers have more room to focus on a single product and its users

Cons of decentralized embedded:

• Designers are disconnected from one another, with little design culture or community, and feel they ‘stagnate’ on only one project
• User experience differs between projects
• Efforts are duplicated between teams

Merholz and Skinner have proposed a new model: 

Centralized Partnership

This maps a little more closely to the way agencies frequently handle projects: they include all of the individuals and specialties needed for a given project, and those resources are dedicated to the specific project full-time. Other specialties who are not needed full-time can move in and out of the project as needed. 

What’s most important here, compared to the centralized internal services model, is that there is a team lead with a direct connection to a set of product owners. There is also often a dedicated senior designer who is connected to a specific product owner.

Example of how this model might look at companies with distinct product teams:

There may be multiple team leads and multiple teams, depending on the size of the organization and the number of projects.

The idea is to have the best of both worlds: the community and efficiencies of the centralized model, while also realizing the increased engagement, speed, and focus of the decentralized embedded model. 

The team lead ensures that designers on different projects stay aligned and re-use information and design where possible.  

For more details, check out the original source – the book “Org Design for Design Orgs: Building and Managing In-House Teams,” by Peter Merholz and Kristin Skinner. 

Additional information can be found on their site: https://orgdesignfordesignorgs.com/blog/