A problem that seems to come up a lot within small to medium size product companies is whether you'll get more value out of your Product Design team being embedded within your different teams, or a centralised team, where work is centrally managed and designers can be 'contracted' out to projects or teams.

The problem is, neither solution is La Roux-level bulletproof, but there are a bunch of reasons why you might swing towards either system, even if it is as a short-term solution.

Embedding in teams

It feels like every company goes through a phase of reading the 'Scaling Agile @ Spotify' whitepaper and holding it up like Moses on the mountain as the One True Way of operating. That is, cross-functional squads, with each function also having a tribe. We did the same at Memrise in 2017, and they still do a modified model of it today. In saying that, not even Spotify still follow this model by the book.

Personally, I really like the embedded model. Having, at the very least, Product Managers, Product Designers and engineers on a single team, with a single purpose and a high level of autonomy, works really well for empowering your people to get good work done and focus hard on where they need to go. Output tends to be higher quality, design tends to have equal power alongside product and engineering, and development is speedier and more iterative.

Embedded teams make your designers feel less 'guns for hire', who get design briefs punted across the fence for them to go and deliver, and also helps get around an 'us vs them' culture between design and the rest of the business. Similarly, if you can still maintain some Design Team-wide rituals, like critiques, stand-ups, demos, retros etc, you can have a strong, unified design culture within the company, even if the designers don't work day-to-day on the same areas of the product.

This sounds like a glorious, wonderful scenario, and for the most part, it works. But there are downsides, and there are ways this model can break down. First off, the downsides across the board. The squad level autonomy makes it easy for design and product decisions to start diverging across the board, and more effort needs to be put in to avoiding inconsistencies, duplications and differing levels of experience quality. Another problem I've seen is that the squads can start getting some insane tunnel-vision, as you tend to be focussed on a single problem for long periods of time. This can impact the quality of your output, as your ability to see the woods for the trees is diminished.

Now for some scenario-specific downsides. This model works best when you have at least one, ideally two, designers per squad, and everyone is a strong T-shaped designer (ie. strong generalist, with strengths in particular areas). Ideally you'd have at least one senior on each squad, who has the experience and depth of knowledge to make strong product decisions. If you have more than 2 squads, that's a fair chunk of headcount.

Next, you need to be on the same level as the other squad leaders (ie. the Product Manager and the Engineering Manager/Lead). If you don't see eye to eye; if there's a power mismatch; if you don't all have the same expectations, you can end up in a shitty situation where you are miserable and achieving anything feels like pulling teeth.

So, in summary:

PROS

  • Designers (plus Product and Engineering) are empowered, engaged and feel responsible for the success of the product
  • The quality of the work tends to be higher, and work is done in a speedy, iterative fashion, due to depth of knowledge and comfort
  • Everyone feels included in the process and heard

CONS

  • Experience quality across the board can suffer, with inconsistencies and duplications due to lack of communication between squads
  • Tunnel-vision can cause a bit of a 'can't see the woods for the trees' scenario, where teams can't effectively solve the problem because they don't have the distance needed
  • Works most ideally when you have headcount for at least one empowered senior designer on each squad, who has a depth of knowledge and is trusted
  • Needs team cohesion and everyone on the same page

ADVICE IF YOU'RE GOING TO GO EMBEDDED

First off, make sure you have enough team members to go across squads. We made this mistake at first, with one designer serving 2-3 squads at a time. The squads weren't happy because they didn't have enough love or attention, and the designers weren't happy because they didn't have time to go deep enough into anything.

Second, a senior on each squad will make everyone's jobs easier, and make sure there aren't any weird power imbalances happening on key decisions. This will only rear its head after a while, and you will likely end up in a situation where a junior designer is constantly being told what to do by a Product Manager, which results in the worst of both worlds.

Finally, if management don't want to grant actual autonomy to the squads, the Pros list halves. On the flipside, it means that the squads need to be fully aware of the accountability they now carry as a team. If they don't deliver, they need to expect diminishing levels of autonomy until they regain trust.

Centralising your Design Team

Centralising a Product Design team gets a bad rap. Sure, there are elements that don't work, and there are reasons that the embedded model is the new cool, but there are definitely situations where a centralised Product Design team makes sense. First off, what do I mean by 'centralising'? This means that all the Product Designers sit within a single team, and works best when you have someone dedicated to doing Design Program Management, which could be the Head of Design, or a dedicated person. The team effectively works like an agency, with internal stakeholders (usually PMs) sending through a brief, spec or product requirements doc. It's then up to the team to accept or reject the project, prioritise and resource it.

One big advantage of this model is that you will almost always have a strong design culture, as you sit and work together day-to-day. Another is that it allows for flexible resourcing depending on the project, which can be a boon when something juicy comes along. It's also a lot easier to keep the consistency and quality of the experience up, as you've all got max visibility on all the projects going on at one time. The model can work really well when you have strong product leadership, and are in a situation where the design team is very junior-heavy. This way, more of the product strategy and definition can happen at the product level before being briefed into designers.

Downsides? Straight up, this isn't a sustainable model for attracting or keeping talent. The main reason is that this also causes the designers to feel disempowered and lacking in autonomy. This is the flipside of that final advantage, as no matter what, a lot of the product decisions end up happening up the funnel, and by the time the designers get to it, it's often a 'Shut Up and Colour In' job. This way also promotes more of an us vs them mentality within the company, and the teams can end up feeling really siloed. Finally, because designer jump around on different parts of the product, it takes a long time to build up deep product knowledge in a particular area, which can mean that this model is great for optimisations, but really rubbish for anything dealing in innovation.

PROS

  • Promotes a strong design culture, because the designers all work day-to-day with each other
  • Easier to maintain consistency and quality across the product
  • Designers won't get bored easily
  • Allows for clearly defined specs, briefs and workload, which is good if you have a particularly junior team

CONS

  • Designers can feel disempowered and lacking in autonomy
  • Design can end up feeling like a 'Shut Up and Colour In' function
  • Can foster an us vs them mentality between design and other functions
  • Can lead to no one

ADVICE IF YOU'RE GOING TO GO CENTRALISED

For me, centralised makes sense as a stepping stone to building a strong embedded team. It makes sense if you have a small team, and need to service a lot of needs, but is not solving the underlying problem of not having enough resource. It makes sense if you have a lack of empowered senior Product Designers or design leaders within the team, but is not solving the underlying problem of not having the right kind of resource to have design function as it should. Basically, centralised teams are a good 'for now' solution.

But, if you feel like you need to go centralised despite these things, my big piece of advice is to invest in strong Design Program Management. This allows somebody to dedicate their time to making sure projects are properly specced, prioritised and resourced, that the team is delivering what they set out to deliver and that the wider company is happy. If you don't do this, it will be down to the team to cover this off, which will take up 40-50% of their time.

Where can I find out more?

That was more Federalist Papers and less TED Talk, but if you're still aching to read more, I highly recommend Peter Merholz and Kristin Skinner's Org Design for Design Orgs as a first port of call. Without knowing it, I've been under the influence of this book for years (thanks to previous bosses being more well-read than me). In a similar vein, but slightly different, Om Suthar's The Natural Evolution for Design Leadership is a good breakdown of the pitfalls of the embedded model. I linked it up above, but Courtney Kaplan's What's a Design Program Manager and How Can My Team Get One? is a good primer on Design Program Management.

‍

‍