Design groups at Redgate — How has it been so far?
As the lead product designer within the SQL Monitor design group (the other design group being DB DevOps) I’d like to share how things have been going so far. I’ll cover some of the benefits of this new approach, the challenges we’ve encountered and outline what’s next for the group. Before I do that, let’s look at why the design groups were formed at Redgate in the first place.
Why introduce design groups?
The word “synergy” has become somewhat of a cliché, which is a shame because it’s a powerful and compelling concept. The idea that the combined power of a group working together is greater than the total power achieved working separately. My favourite example of synergy is when the Mighty Morphin Power Rangers join forces to create the mighty Megazord, a giant fighting robot (shown below). Only by working together as a team, rather than as individuals can they defeat their foes. It’s a valuable lesson and one which lies at the heart of the move to introduce design groups at Redgate. Not to defeat giant mutant lobsters threatening to destroy Cambridge, but to better unlock the potential that design can deliver within Redgate, to better support designers at Redgate, and to better support our move to designing for enterprise customers.
Redgate has for a long time had product designers embedded within product teams. This embedded or de-centralised approach has lots of benefits, but also a few downsides. Whilst it means that designers will invariably work very closely with development teams, they tend to work much less frequently with other designers. Believe me, life as the only designer in a product team can be a lonely one.
Embedded designers can not only be isolated, they have to singlehandedly juggle all the demands of a team, and less experienced designers can struggle to receive the support they need to learn and grow. With embedded designers working semi-independently user experiences can become fragmented and user research is driven by the needs of a single team, rather than the wider organisation. There are also inefficiencies as efforts are inevitably duplicated. For example, rather than utilising existing design patterns, components and user journeys, new ones are often created.
As we increasingly move to designing for enterprise customers, to designing solutions, rather than individual tools, it’s clear that having embedded designers isn’t right for every team. By introducing small design groups (see diagram below) that can work across multiple development teams we want to unleash the synergy that comes from collaboration and teamwork, whilst continuing to work extremely closely with development teams.
As Matt Godfrey, head of design at Redgate outlined in his Designing for the Enterprise post last year:
“In the groups model, we’re attempting to break the silos and are experimenting with abstracting designers to create a team that operates across the entire solution. Their focus is strongly around collaboration and collectively supporting the teams that comprise the solution; identifying where they can have the greatest impact and designing a more holistic customer experience.”
How has it been so far?
The SQL Monitor design group is made up of myself (as the lead product designer) and the awesome Callum Brown and equally awesome Elena Lockyer. We’ve only been together for about 2 months, so it’s still early days, but indications so far are that the design groups model is a step in the right direction. Sure, there have been some challenges (more about these in a bit) but overall things are working well.
As a design group we had our first retrospective a few weeks ago. We discussed what we felt went well, what we would like to change and ideas for things to try out. The good news is that the team were over whelming positive. When everyone was asked to rate their level of satisfaction from 1 to 5, with 5 being the best team in the world, and 1 being unhappy and dissatisfied, it was a case of 4 out of 5 all round (well, there’s always room for improvement).
What’s working well?
A few clear themes came out of the retrospective. It was felt that the design group better supports collaboration and co-ordination between designers (at least within the group) along with better support for knowledge sharing, mentoring and learning and development in general. Having multiple designers allows research and design work to be shared across the team, providing more flexibility. Work can be better allocated based on skillset, experience, knowledge and areas of interest and development.
All of our products will require research and design work for the now, along with work to help shape the future of that product. It’s already clear that a group is better placed to do that. Unlike a single designer having to continually juggle the two, a group can have parallel streams of work. The here and now can be worked on, at the same time as the future.
Lastly, and perhaps most importantly it’s clear that a design group provides a better framework for day-to-day collaboration and interaction, such as working on a design as a pair, or reviewing a design as a group. It’s no surprise that better collaboration typically leads to better designs. Indeed, when InVision looked at what were the ingredients are for a successful design team, unsurprisingly working day-to-day with other designers was high on the list. As they put it:
“What we almost never saw in this cohort of successful companies? A single designer on a team outnumbered by engineers.”
What has been challenging?
Significantly changing work practices and structures will always have its challenges, leading the newly formed SQL Monitor design group has certainly thrown up a few. Firstly, it’s meant some extra overheads have had to be introduced for co-ordinating, planning and generally managing the design group. We’ve tried to minimise these by keeping our own team meetings short and sweet and by introducing a rota system to ensure that only one designer has to attend each development team’s stand-up and planning meeting. We’ve also been very open with the teams about only attending meetings that require a designer to be present. If we attended every team meeting and ceremony, there simply wouldn’t be any time to do any design and research work!
No longer being truly embedded within development teams has inevitably led to some small bottlenecks and an increased need to co-ordinate. We don’t want development teams being blocked because designs haven’t been created, but then teams don’t always need a design to progress their work. We’re working to better upskill developers across the SQL Monitor teams so that they’re able to take on more of the low-level UI design work (with designers playing a support role). We’ll also shortly be experimenting with a dual track approach (more about this later) so that we can better focus our efforts on the more critical design and research work.
Finally, it’s been a real challenge to support multiple development teams at the same time. To help address this we’ve set-up a weekly planning meeting, a Github project board to share the design group’s backlog and work in progress, and have scheduled our own stand-up to be after the teams so that we can discuss the priorities for the day once we know what the teams will be working on.
What’s next?
Following our retrospective and on the back of some workshops with the SQL Monitor development teams we’re planning to experiment with a research sprint and with taking a dual-track approach to how we tackle product design and research work.
Research sprint
Inspired by Google venture’s design sprints the design group are planning to dedicate a 2-week sprint to exploring how SQL Monitor can better support customers with larger and more complex estates (more servers to monitor, and a mixture of servers in the cloud, and on premises). This is to allow the team to fully focus on rapidly exploring the problem, creating some concepts and getting feedback on these from our customers. Given that we’re now all working from home we’re looking at how we can do this remotely. I’ll let you know how we get on.
Dual-track approach
A dual track approach has been advocated by design teams at companies such as Autodesk and by Agile design thought leaders such as Jeff Patton. The basic idea is to have two tracks of product work. A discovery track to rapidly explore and research ideas prior to a team taking them into a sprint, and a development track to develop and deliver those ideas.
This allows ideas to be rapidly researched and concepted prior to a team taking them into a sprint. It helps to avoid the design bottleneck problem, whereby development teams are blocked through a lack of designs, and helps to ensure that we’re not only building things right, but that we’re building the right thing in the first place.
When an idea is picked up (such as from the product roadmap) we’ll look at how critical design is for that idea to be a success (i.e. how much design effort is required) and how much we know about it (i.e. how much research effort is required). For example, a new configuration feature is unlikely to require a lot of design work, whereas a key user journey will.
The criticality of design to the success of an idea, together with how much is known will drive the approach taken (see above), and ultimately the amount of design and research effort we think we need to throw at it.
We’re planning to review ideas on a quarterly to monthly basis to help determine the approach to take. A dual-track approach will be another first for Redgate. I’ll be sure to keep you posted as to how we get on. If you want to find out more about taking a dual-track approach I recommend reading Jeff Patton’s Dual Track Development is not Dual Track blog post.
