Overview
Design leaders require well-organized and effectively structured teams, and that is why a topic dear to any manager is how best to organize their resources. While there are various organizational structures to consider, the lessons I have learned leading and managing designers show that there are three primary models for organizing a design squad. I will review the pros and cons of each.
Centralized model
When I worked at Saatchi & Saatchi in New York City, we used a centralized team structure. In this model, all designers, researchers, and related design staff function together as a whole. They are not divided into individual teams assigned to particular silos. When someone outside the organization needs work, they ask the team manager, who then allocates personnel from the centralized design team. Furthermore, all the designers work in a central location, which fosters close cooperation. The design team benefits from direct communication, as all teammates sit side by side.
There are some obvious benefits to this approach. Naturally, designers sitting side by side receive frequent feedback from their peers. This makes the work tighter and helps individual designers learn and grow. From a product point of view, there is a benefit to be had as well. With a centralized design squad that oversees all of the different components and workstreams, it is easier to ensure product consistency and other larger product goals, such as adherence to a design system and other company-wide standards.
Decentralized model
A great strategy to build bridges across departments is a decentralized model, or an embedded design organization. In this approach, cross-functional teams are created with representatives from each major discipline: engineering, product, and design (EPD). This trio is sometimes referred to as the three-legged stool.
The benefit of this approach is that designers work in close collaboration with their non-design counterparts. When designers better understand their colleagues' needs and vice versa, design decisions can be reached that meet product demands and are more economically and efficiently realized.
However, be careful with this model, because problems arise since there are far fewer designers to share among cross-functional teams than engineers or other specialties. The following designer-to-developer ratio table shows how understaffed most companies are with designers.
Designer to developer ratios over time
| Company | Earlier year | Earlier ratio | 2017 ratio |
|---|---|---|---|
| Atlassian | 2012 | 1:25 | 1:9 |
| Dropbox | 2013 | 1:10 | 1:6 |
| Intercom | 1:5 | ||
| 2010 | 1:11 | 1:8 | |
| Uber | 1:8 | ||
| IBM | 2012 | 1:72 | 1:18 |
While the trend has been improving, designers continue to be dramatically understaffed compared to software developers.[1]
As a result, a decentralized staffing model sometimes results in a situation where a designer works alone without another design colleague, which is isolating. To overcome this challenge, find a balance that allows for close interaction between the designer and their design and non-design colleagues. One way to reconnect an embedded designer is to pair them with another designer on the same decentralized team. Working side by side, the two can meet each other's needs for design cross-fertilization while still being part of the larger EPD team.
Hybrid approach
The most prevalent design resourcing model is a hybrid approach. In this strategy, designers have ongoing assignments with cross-functional teams on specific projects. They also frequently return to the centralized design team for gatherings such as design reviews, stand-ups, and group crits. Some of those occur daily, while others typically have a biweekly cadence. At my design studio, we hold daily design team stand-ups in the morning and team design reviews several times a week for all designers to review each other's work.
This staffing approach also works well for short-lived projects. The designer temporarily embeds with a cross-functional team and then returns to their centralized unit after the assignment wraps. The benefit is fostering close collaboration between designers, developers, and product managers while also ensuring that the designer continues to draw inspiration from their colleagues and receives the merit of close cooperation with them.
Summary
The design team organization you choose profoundly impacts your team's day-to-day operations and the quality of the work they produce. When selecting the approach that best suits your needs, consider how your designers can work closely with their fellow designers while collaborating with non-design peers. One question to ask yourself is, do you have enough designers to embed on all of your different teams? If not, it might be necessary to follow a centralized approach until you meet your design staffing needs.
If you have enough design resources, it will make sense to follow the decentralized approach, provided you also have a robust design culture. Recall that it is no fun for one designer to be alone on a team composed of many times the number of engineering and product teammates. It is essential to spark that person's creative juices with time and design activities with other designers. Hold off on this approach if you do not have that system.
Finally, it is also helpful to consider that organizations are dynamic, and it always makes sense to adapt your team structure to your company's current state. These staffing models are equally fruitful and ripe for experimentation. Many design studios like mine provide interim design resources to bump up your designer numbers, which can solve some of those pesky decentralization problems. Reach out if I can help. I also love to host design workshops to strengthen your design culture, but more about that another time.