Units and silos
‘Always design a thing by considering it in its next larger context — a chair in a room, a room in a house, a house in an environment, an environment in a city plan.’
— Eliel Saarinen
Over recent years, I’ve consciously moved back and forth between design management roles and what Americans call an ‘individual contributor’. Wanting to stay close enough to making things; or creating the space as a manager for designers and teams to make things in the right way.
Right now, I’m all about working hands-on in a delivery team, doing the day to day work of a designer.
Being back on a delivery team has had me thinking once more about how we build delivery teams and how we make the user-centred design unit within them function really well.
Planning teams like these played a big part of previous roles, particularly at Co-op Digital and especially a spell where I was charged with recruiting, managing, and assigning designers, user researchers and content designers to delivery teams.
Here’s some things that have stuck with me from helping teams to form.
Good design needs good research. And vice versa. Good design feeds better insight; good research provides the material to design with.
Good design needs good content. And vice versa. Design serves the content. Design and content serve the user need.
Relationships matter. It’s not a given that every combination of user researcher, content design and designer will work well together, have complementary skill sets or basically get on with each other. Without this, it’s really difficult to generate the cadence, energy and alignment you want these partnerships to have, and the positive effect it can have on the wider team.
Partnerships that work are gold. Keeping people who do work well together makes sense for lots of reasons. It reduces the time a team spends forming, when relationships and understanding of how others work are already in place. But more importantly, I think it works for the individuals too: we’re often as motivated by who we are working with as what we’re working on.
Better planning reduces reliance on ‘seniors’. Agile’s emphasis on autonomy and collaboration can lead to teams relying on very experienced individuals in their respective disciplines. That reliance can inadvertently become a weakness. It can lead to professions becoming top heavy and expensive. It can make it more difficult to find opportunities to support interns and juniors without a delivery team feeling like they are ‘carrying’ a member of the team, making it hard to bring through new talent. But it shouldn’t have to feel like that. More conscious thinking about these combinations on teams can help — allowing you to, for example, pair a more junior designer with an experienced, broad-skilled researcher capable of providing some light-touch mentoring.
As design and research have matured and teams have scaled, so has the management around them. Where once there was once a solitary ‘head of user experience’, often there’s now respective management teams for design, user research and content design professions. That’s been for the good — helping to build teams with deeper skills; more structured career progression; better work, better outcomes. But it’s essential, I think, that the management of these disciplines collaborate really closely.
In larger organisations, I worry that this isn’t working as well at the management level as it is in delivery teams.
I don’t see enough thoughtful assembling of teams — designing a thing by considering it in its next larger context — and thinking too narrowly about individual professions rather than the wider design and research practice. The risk here is user-centred design units that aren’t aligned around a problem space, or how to tackle it, together. The overlap between these roles should be a real strength: creating a culture of collaboration, critique that benefits the product and its users.
I have a few thoughts on how we might do this better.
Recruit together. One of the best things design and research roles can do is to play an active role in supporting each other’s recruitment, to help think about the potential recruit in terms of _the next larger context_: the professions they’ll work with not just the delivery team they’ll work in.
Don’t recruit to the delivery team. This sounds easy but is often hard in practice, when the need originates from a delivery team losing a designer. Better to keep the focus on the long-term balance of the wider professions and their needs, rather than the shorter-term interests of a delivery team. Even if that means finding other ways to resource that particular delivery team.
Plan together. At Co-op Digital, one of the most painful but worthwhile meetings we had was a regular review and prioritisation of our work: looking at where all our delivery teams were at, making sure we were focused on the right things, kicking off new work. It took a lot of time and patience, but it meant we didn’t just fill a seat — we assembled teams (or at least tried to) — and it created a good habit for us, as a leadership team, of collectively checking in on how our existing delivery teams were working together and performing.
Forming a team takes time. Moving people between teams can be a drama. It’s better to get it right than do it quickly. I don’t think I always got this right, but talking to people individually, showing your working, explaining your thinking openly always helped. Allowing them to say ‘no’ to a move is critical though. Few things demotivate people more than being treated like an interchangeable resource.
Always re-visit objectives before asking someone to join a team. I found it really helpful to remind myself what an individual was aiming to try and achieve over the course of the year, and to think about how joining a particularly delivery team might contribute to that. One of your fundamental responsibilities as a manager is to support and create opportunities for your team to meet their own objectives. Sometimes it’s obvious — to gain experience of working on a Discovery, getting more exposure to service design — sometimes it’s not. But it helps to see a prospective delivery team through the lens of those objectives and what motivates an individual.
Review how it’s going. It can be easy to see planning teams as a fire fighting exercise: a task to be completed, a fire to be fought. Not all delivery teams are an easy sell, not every project feels worth being part of. If we’re asking people to do something politically tricky, emotionally complex, we need to support them through that. We’re not done when the team is formed.
Watch the team in action. Aside from all the usual reasons, show and tells can be a real measure of team confidence. An insight into how relationships within a team are playing out: what’s working, what’s not. The kind of research work they choose to prioritise; whether design is contributing beyond just the user interface; how professions collaborate; and how strong the connection is between research and design decision-making. Don’t just rely on a 1-to-1, observe the whole team in action.
We’ve made real progress in user-centred design in building understanding and appreciation of the professions within it — interaction design, user research, content design and more. There’s a sense, in the sectors I work in at least, of an improved understanding of career paths and what it takes to move from junior to senior practitioner. But we can’t think of our professions, or the development of individuals in isolation. Our responsibility is broader than just our direct team. That user-centred design unit can be so powerful, so it’s vital that design, user research and content design leadership shares a collective sense of the values they are trying to instill, recruit for, and better still, demonstrate them at leadership levels.
—
My thanks to Matthew Solle, Gavin Wye and Simon Whatley for their thoughts and improvements to this post.
‘Units and silos’ was originally published on my own website.
