Maintaining a design culture in an embedded team model

Matthew Godfrey

Published in

Ingeniously Simple

8 min readMay 18, 2018

~5 Software Engineers
1 Technical Lead
1 Product Designer

…with an extended team that also includes:

1 Development Lead
1 Product Manager
1 Product Marketing Manager

Typically we work to a ratio of one Product Designer to every five Software Engineers (5:1); which is reflective of the value we place on the role of Design at Redgate.

As an engineering company, we firmly believe that maintaining a good balance of technical smarts, customer empathy and a collaborative design practices is key to our ability to innovate and continue to create products our customers love.

It works for us

We’ve embraced and continue to embrace this model for a number of reasons, however, it’s worth calling out that this may not be the best model for every design organisation. It’s quite common for smaller teams to still operate in a centralised or agency model; effectively project managing design as a resource, producing and handing over artefacts as needed.

As another example, some organisations might have a lone design practitioner who is by default required to wear many hats and service differing design needs day-to-day. These individuals might find themselves frequently having to flex between operating as a centralised, shared resource and something more embed; where they are working hand-in-hand with developers and engineers.

In short, there isn’t a one size fits solution and many organisation are continuing to experiment with different models for how to organise and structure growing design teams. You can read more about this and the evolution of design team structures in Peter Merholz great book ‘Org Design for Design Orgs’.

So why does this embedded model work for us? There are a number of causal factors and a long backstory that eventually brought about our current structure; but if asked to describe why is this right for Redgate, right now, I would in particular highlight the following:

Design is considered an integral part of the product development process (from cradle to grave); such that only being involved at certain, predefined points would compromise Designs’ ability to have impact and influence key product decision.
To complement the above we’ve worked incredibly hard to democratise design; that is, empowering the wider product teams to be involved with and actively contribute to every aspect of the design process.
As a result, embedded designers spend a large percentage of their time facilitating research and design sessions; working closely with their extended products teams to both support and coach them through aspects of strategy and execution.
By being tightly embedded and co-located, designers quickly build trust and rapport with their engineering counterparts. Design is therefore seen and valued as a core team competency, and not as an ancillary service.
We need to deeply understand the customers’ domain and wider problem space, such that we can help the team make better product decisions. Embedding allows designers to assimilate this much-needed product and domain knowledge.
We need to dedicate the time and effort we believe necessary to create great products; this focus allows us to own the end-to-end experience across a given product and think around the bounds of the wider problem-space.

The thread through all of these points is fundamentally one of making better product decisions. Designers, as user advocates, provide a critical role in identifying and uncovering user needs and helping the team to make sound, evidence-based decisions as a result. You can read more about our approach to Evidence-Based Decision Making in my recent blog post.

We believe an embedded approach capitalises on this by bringing product teams ever closer to our customers and using the tools of design, in the context of a cross-functional team setting, to rapidly explore and validate new product ideas.

Trade-offs

Whatever team model you decide is right for the business and your design team, there is inevitably trade-off to be made. You’re essentially faced with the choice of optimising for one set of behaviours, which often comes at the expense of some others.

For example, frequent, high-quality collaboration between design peers vs. frequent, high-quality collaboration between cross-functional product teams.

You can, at least to some extent, have the best of both (which I’ll get onto next) however, when deciding how to structure and whether or not to adopt this particular model consider the following potential trade-offs:

Less frequent design-design collaboration.
Longer loops between design critique and feedback.
Less support immediately on-hand for more junior designers.
Limited perspective on growth and development relative to peers.
Increased risk of divergence and inconsistency.
Increased chances of doubling-up of research and design efforts.

This might sound like a list of some fairly big-ticket items, which would understandably beg the question ‘Why would we adopt this model?’, but we believe we have been able to offset or at least mitigate these trade-offs with the practices, activities and mechanisms we’ve adopted as a design team.

As solutions, these are never perfect, so we continue to experiment with new ways to solve or at the very least adapt to these challenges; and as we scale the team we inevitably discover new types of problems we need to tackle; for example, how we might cater for more remote and distributed work patterns.

Maintaining culture

It goes without saying that creating and maintaining a healthy culture for design is very important to us. As much as we value the embedded nature of our model and the associated benefits discussed above, we also value creating an environment where designers can:

find a ‘safe space’ in which to practice their craft;
continually develop and hone these skills;
gather feedback and constructive critique;
establish best practice and standards;
experiment with new tools and techniques;
and continually evolve our practices and processes.

We believe this commitment to maintaining a strong design culture helps us foster and develop design talent, raises the bar for design across the organisation and helps to set us up for success both now and through future iterations of Redgate’s design organisation.

To help establish and maintain this culture, over time we’ve introduced mechanisms and activities that allow us to operate as a functional peer group; working together outside of the scope of any single product team. This is more analogous to Spotify’s definition of ‘Chapters’ (functional peer groups) that operate as a sub-team, within the context of a cross-functional product team or a ‘Tribes’ model.

Creating the environment

Here are some examples of some of the mechanisms and activities we’ve tried and since adopted, in an attempt to create the right environment for Design and Designers at Redgate:

Design show & tell: This is a standing, weekly slot to which all of the designers are expected to attend and provide a short (5 minute) update, during which they are asked to address the following key questions:

What is the problem you are solving right now?
What are you currently doing to address that problem?
What’s coming up for the week ahead?
Where might you need support?

After the session, each designer is asked to share links to any work in progress (including links to digital boards, slide decks, design files or prototypes) so that others can explore this work in more detail or those unable to attend can recap in their own time.

Design critiques: A regular session that provides designers with an opportunity to run a critique with the rest of the design team (or sub-set of); during which they can go much deeper on a given problem (not afforded by the shorter show & tell updates) to gather more detailed feedback from peers on their work. These sessions are intended to provide a safe environment in which the designer can solicit thoughts, ideas and suggestions to help with better design choices and ultimately drive the quality of our work.

Functional/Design Ops time: Every Friday afternoon all designers congregate in our ‘Creative Space’ (a designed area in the office for collaboration and creative thinking) to work on key, functional initiatives and improve the practices of the wider design function. Recently this has included themes associated with developing our design system (Honeycomb), improving our onboarding process, documenting our Playbook and exploring a strategic toolkit.

Design Guild: As part of the functional time (above) we also operate a ‘Design Guild’ that functions as a broader interest group around the subject of design and anything design related. These smaller sessions are intended to provide a forum for both design and non-design folk to share, learn and practice different aspects of the broader discipline. These sessions include more inclusive activities like video lunches and katas (short, practical activities designed to practice a particular skill or method).

Coaching & Mentoring: We provide all new starters with a range of coaching and mentoring options, based on some initial assessment of skills, capabilities and competencies. These can either be more informal, through a buddying system or ad-hoc coaching or formal; should there be particular gaps that we and the individual recognise. In the absence of immediate design peers on a product team, this setup ensures we can provide an ongoing support network for new starters, as well as our more experienced designers.

‘What does good look like’: This is a reference document that outlines a series of behaviours and attributes we expect of all designers when they join Redgate. It provides us with a baseline for what good and going above and beyond look like; with some practical examples of how designers might reasonably demonstrate these qualities through product work or otherwise. It enables designers and their line managers to reasonably and objectively evaluate their growth and development in the absence of more immediate design peers.

These mechanisms have served us well, providing a structure outside of our product assignments, to help create the environment in which our designers can thrive and continue to grow. We see these efforts as not only benefiting individual practitioners and the function but also in terms of helping to support and enable the wider product teams, to conceive of and ultimately design better products.

In summary…

We have managed what I believe to be a good balance of purpose, value and culture, but it takes time and effort to maintain that; never losing sight of the need to both focus on the more immediate needs of our product teams and the longer-term practice and operational improvements that are the foundations of future success.

In closing, my advice for anyone who is in the process of scaling their design team or considering changing the current structure and model of their design organisation would be:

Choose the model that works for your type of organisation.
In doing so, understand the trade-offs you might have to make.
Offset your trade-offs and experiment with different team mechanisms.
Balance immediate needs with longer-term successes.
Don’t compromise on your culture.