The design of design teams
By: Matthew Godfrey
Tags: Product Design, User Experience, Product Management, Organizational Culture, Product Development

As a base model for how we organise designers and teams, this has in large part worked very well for us, where over time we’ve observed the following benefits:

Designers can develop deeper expertise/knowledge in a given product domain.

Design is more tightly integrated as part of the overall development process.

Designers build rapport and trust with their cross-functional colleagues.

Designers can focus the time and effort necessary to create well-designed products.

An embedded model optimises for individual teams with local missions. It biases towards design being tightly integrated as part of the end-to-end development process. It removes any inter-disciplinary silos that may have in the past led to the need for explicit handoffs between functions; reducing the communication overhead and improving the flow of product work and decision-making.

However, as our portfolio evolves to serve the needs of different types of customers, we also recognise that the way we operate as a design practice (inclusive of research) also has to evolve. A model that is organised around disparate and self-contained products may not serve us well where we seek to design more comprehensive offerings, conceived to tackle larger organisational challenges.

Group Model

In an attempt to recognise this shift from designing simple, standalone products to more complex, cohesive experiences, we saw it fit to experiment with an alternative grouping model. Here, designers operate in small pods that are assigned to a group of products (or capabilities), as opposed to strictly embedding 1:1 in a single product team. Whilst still available to support the needs of individual teams their focus shifted towards the meta concept of a solution.

Illustration of group/pod design model.

This model was trialled across two of our Product Groups. These are areas of the portfolio that comprise multiple teams with ownership of individual products/capabilities, but where those products/capabilities are often packaged and sold as part of larger propositions.

With this new model running as an experiment we began to observe the following benefits:

Regular design-to-design collaboration and more coherent design decisions.

More fluidity in our ability to allocate the right skills to the right work.

Stronger cohesion as a design group and improved designer satisfaction.

Better coordination of research and design effort across the group.

Sounds great right? So why not stop there?

Well, in reality, what we’d created were smaller pockets of what began to feel and behave like more centralized and service-oriented teams. In the process of trying to optimise for design collaboration and break away from a more siloed approach, we’d inadvertently introduced a number of unforeseen problems that would start to compromise the structures, processes and relationships we worked to establish; including:

Compromised the cohesion of our cross-functional team units.

Introduced an operational overhead of coordinating design efforts relative to the teams.

Started to decouple research and design from everyday teams activities.

A perceived sense of misalignment as between strategy, design and delivery.

It was clear that a bias towards horizontal, as opposed to vertical structures led to better functional collaboration but at the cost of making good, project-level design decisions and infusing design into the development process (AKA design as a team sport).

Hybrid Model

Recognising the virtues of each of these models, like any good agile, iterative process we’re now attempting to take the best of both and evolve this into more of a hybrid approach. As a result, we’ve decided to fundamentally realign with our principles of having empowered, autonomous, cross-functional teams; requiring the designers in those groups to once again embed and establish that as their primary team.

However, what’s different this time around is we have introduced lead designers (Lead Product Designers to be specific) who have been appointed to drive collaboration, take a broader purview of the end-to-end experience and ensure decisions support the vision of the group as a whole. They operate exclusively at the group-level, working alongside equivalent peers in Product Management and Engineering.

Illustration of hybrid/collaborative design model.

Alongside the leads being responsible for that whole programme of design work, they have set up secondary structures (in the form of communities) that seek to enable regular communication and collaboration across the designers in that group. Designers (with the exception of the leads) are still embedded, but this does not preclude them working together on broader themes and supporting each other with cross-cutting design challenges.

In this model, we optimise both for local and global design needs. The designers feel connected to the product teams day-to-day, whilst still being able to draw upon a like-minded community of design peers to support, guide and align their individual efforts. The lead enables wider collaboration, supports product in communicating the overall vision and helps coordinate and prioritise activities across the group.

This remains a fairly new setup for us, where we’re trying to proactively mitigate against the risks of siloed design considerations; fixating on local design concerns without an understanding of the direction of travel or the desired end state. However, our current thinking is that this kind of hybrid setup could allow us to leverage the relative benefits of both of these horizontal and vertical organizational concepts.

The lessons of org design

In the act of exploring these different structures, it’s safe to say we have learnt a lot along the way about the impact of organisational decisions and the challenges of change management. In hindsight, there are definitely things we/I could have done better and will approach more mindfully wherever we explore new models or iterations of those we currently have in place.

Be mindful of wider the system

One of the first things to point out is the complexity of organisations. Like a system of organisms that cohabit a given environment, one seemingly innocuous change can have an impact on other parts of the system. Much like any aspect of design, it’s important to also think about the unforeseen consequences of your design decisions. These may not be immediately obvious but will have an impact on your audience — in this case, your internal customers.

For example, a decision to co-locate the designers (when that was physically possible) and reign in on the attendance of various teams ceremonies slowly starts to erode that sense of cross-functional cohesion and creates a service mindset; even if that was never the intention. Decisions that may on the face of it seem simple and inconsequential will likely have an impact elsewhere, be those positive or negative, perceived or actual.

Every organisation is different

While you may draw insight from others — and it’s great practice to look outside of your organisation for inspiration — use those as examples, as inputs into a broader set of decisions, rather than as an outright blueprint for success. Quite often you’ll hear about what’s worked and less about what got broken along the way. So, approach these success stories with caution as what works for one may not translate for another!

Context can differ radically and cultures can be very different beasts. What is needed in one organisation at a given point of time is unlikely to map directly across to your situation and particular circumstances. Use this learning to develop your thinking, but be very cautious when trying to replicate. Draw your own conclusions about what parts of that model might work for you and where such a change might have unintended consequences.

One size may not fit all

As with our example, one model may not fit every scenario. We now persist aspects of both an embedded and hybrid model within our design organisation, due to the nature of our portfolio (a blend of standalone offerings, larger products and overarching solutions) and current team structures. We recognise that these teams and groups have different challenges and with that differing needs of research and design. As such, we now consciously recognise these two models, while respecting a core principle of cross-functional teams.

On the one hand, you might need to support local, self-contained product experiences. On the other, you might need to operate across existing team boundaries to support wider experiences or serve the entirety of a customer’s Job-to-be-Done. The governing question should always be: What are you trying to optimise for at any given time? Are you trying to drive collaboration and decisions to support these overarching experiences or optimise for a local and discrete set of customer needs?

Practice proper change management

With any kind of structural or organisational change, particularly something that is yet to be proven in your particular context, my advice would be to run it as an experiment with proper consideration for change management. Don’t make organisational decisions lightly, reduce the scope if at all possible and make sure you set out clear success criteria and review points from the get-go. It’s easy to sleepwalk into problems down the road unless you apply some rigour to how you manage and evaluate the impact of change.

To that end, think clearly about the outcomes you hope to realise as a result of the change, the early signals of progress, the smells of problems that could be introduced as a result and at what point you’d consider the endeavour a success. Have a rough plan for how to move forward (what are your first steps?), how you’ll communicate the change, who are the key stakeholders you need to engage with and what is your contingency or roll-back if you need to stop or pivot.