AT THE ROOT of most team drama is fear. We’ve all seen it in others, and we’ve all felt it in ourselves. Will we have rewarding work to do? Will we have the chance to make a truly positive difference? Will we be recognized for our contributions? Will our relationships with teammates be disrupted? Will we get pigeonholed or denied an opportunity for growth?
Fear is all about protecting what we have—or could have. It keeps us from learning from each other’s perspectives and skills, and keeps us from growing as much as we could. Ironically, it’s often the thing that keeps us from the success we think we’re defending. It isolates and confines us. Fear always shoots itself in the foot.
And when it’s time to define roles on design team—especially when skills and functions overlap—fear often rears its head, ready to ruin what we’re building.
GOOD LEADERS KNOW that successful teams need a mix of strengths and specialties working together toward a shared vision — with interdependent but unmistakably distinct responsibilities. It’s one of the earliest challenges leaders face, and it can be surprisingly sensitive. To some, defining their role can feel like their one chance to stamp their name on something, and make sure no one else steps in the way of their growth. To others, it can feel like a signal of whose skills and strengths are really valued—and whether they’re in or out.
At the root of most team drama is fear.
Define too broadly, and people don’t know who to depend on for what, communication is strained, and resentment takes root. Define too narrowly, and teammates become demoralized as new property lines limit their sphere of influence or turn their career path into a dead-end. Sometimes a project’s founding members worry they’ll lose what made the work inspiring in the beginning, and begin to pine for the good old days where the team was mostly held together by informal passion or even friendship, while new teammates worry about whether they’ll really have the opportunity to make a substantial contribution. And even if people trust each other’s intentions, lack of clarity in overlapping roles can quickly lead to chaos.
So how can leaders help the team define their roles in a way that gets the right work done and helps each teammate become who they want to be next? How do we make sure that everyone is relied upon for what they do best, but able to grow beyond their core skills? How do we match the right work with the right people (especially when skills overlap) without the drama?
There are a variety of approaches to defining roles—maybe you’ve tried some of these:
- Define by product feature or phase: onboarding, payment feature, notifications, etc.
- Define by practice: content strategy, visual design, UX architecture, etc.
- Define by platform: iOS, Android, web, etc.
There are pros and cons to each of these approaches, but I think they all suffer from the same flaw: they’re defined by activity one does, rather than what the future needs to be like to be successful. A good set of design principles, a journey map, well-defined customer needs, and other similar tools can help, but especially as the team grows, these approaches are all susceptible to that subtle fear—the old temptation to protect your territory.
In wrestling through these challenges, I’ve learned a different and foundational approach to defining roles that has helped me and my teams, one that can be summed up with my understanding of an effectively defined role:
Your role is the outcome you’re most directly responsible to ensure.
Here’s what I mean.
Not the outputs (things you make), or the activities (things you do), or the methods (the way you do things) but rather the thing(s) that should occur if the product and team is successful. In other words, the intended result—for the people your product serves, and your company.
…you’re most directly responsible…
There will always be some role overlap (that’s a good thing, almost nobody fits into the cookie-cutter designer roles we might lay out in a job posting—teams are unique combinations of humans, not just embodied task lists), but there should still be something each person has distinctive experience, knowledge, and good judgment to be primarily accountable for. Overlap is expected, as long as everyone knows who is ultimately responsible for the outcome, and who is considered the “expert” to defer to in case of disagreement.
Healthy “ownership” isn’t about the thing you keep to yourself; it’s about the thing you are responsible to make a reality. Sometimes that means you do it yourself. Sometimes it might mean you teach others how to do it. Sometimes you might hire someone to do it. Sometimes you might create a system or tool to automate it or make sure it keeps happening when you shift roles.
The main thing is that it happens; that’s the job. In most cases there will be one person as the driving force behind that outcome, but if you’re that person, you’re responsible for ensuring simply that it occurs by some legitimate means, not that you’re always the one to do it.
I think this is better for a few reasons.
- It’s a great starting point for partnership. Chances are, good product managers and engineers care about the outcomes you’re primarily responsible for; they’re just primarily responsible for different ones (such as developing competitive business advantages, saving costs through technical efficiency, inspiring confidence with business partners, or creating sustainable infrastructure for the future). It sends a strong message to a partner that nobody on the design team is just there to “do design”, but to achieve clear outcomes that they agree to, by the most demonstrably effective means. It’s a great way to translate what designers care about into something everybody cares about.
- It lowers your guard. If what you ultimately care about is an outcome, not a method or activity, then you’re much more open to receiving feedback and much less prone to defensiveness. The nature of the conversation shifts from “do I like it?” to “is this solution effective at achieving the outcome we agreed to?”
- It gives people room for creativity and growth. If you’re ultimately responsible for an outcome—by any effective and honest means—then you’re empowered to explore better ways to achieve that outcome, and to grow your responsibility by relying on others (whether training someone, delegating, or hiring).
So what might it look like in practice?
Here’s an example.
How might a typical designer might describe their responsibility? Some might put it something like this: “I’m responsible for visual design on iOS — color, typography, design systems, typography, etc.” Or maybe, “I’m the iOS UI Designer.” Fair enough, but what happens if someone with different expertise questions their decisions or wants to contribute in “their” area? What happens if the team adds more interaction or iOS designers? There’s that territorial temptation again, and it’s easy to lose sight of the point of it all. Notice how the role definition plays into it: there are specific activities and skills that “belong” to them. Even if nobody intends it, it’s all too easily rooted in territory and ownership.
So let’s reframe it.
What if they described their role more like this?
“I’m responsible for ensuring every detail of the product experience is beautiful, internally-consistent, platform-appropriate, and intuitive.”
“I’m responsible to ensure that our customers clearly understand their cashflow so they can make confident spending decisions—wherever applicable.”
Can you see the difference? If their job is not to just to be the one to perform certain activities, but to ensure an outcome occurs, then they have a higher purpose for their specific skills (a purpose that everyone on the team cares about too), and the flexibility to experiment and grow. That designer, working to achieve that outcome, can grow by getting really good at their individual contributions or by teaching others on the team, or delegating to someone more junior (with a subset of those responsibilities).
Is that person still a highly-specialized craftsperson? Yes, but now it’s a means to an end, and it’s about finding the best ways to realize that purpose rather than wasting time and talent defending territory.
For a product design leader, their primary outcome might be:
“I’m responsible for ensuring each part of the product experience and team makes a coherent whole that meets our users’ true needs and furthers our business advantages.”
“I’m responsible for ensuring a healthy design team that reliably delivers an effective product experience.”
To break it down a bit further, a few sample “sub-outcomes” might be:
- Communication: ensuring everyone on the team has the information they need to make effective design decisions at the right time (via the creation/adoption of appropriate channels and tools)
- Product strategy: ensuring the definition and expression of a product vision (and every resulting feature decision) is grounded in well-defined human needs (in ways that contribute to the broader business strategy)
- Hiring & staffing: ensuring the team has the right mix of perspectives and skills to design a great product experience, with a reasonable distribution of workload
- Team health & maturity: ensuring a healthy and growing culture of respect, humility, collaboration, exploration, curiosity, risk-taking, etc. (by any effective activities, rituals, co-creation exercises, tools, etc.), and ensuring each teammate has a clear and credible growth path
For a design researcher, outcomes could center on ensuring that the team has valid, insightful (giving us a vision for the difference we could make and an advantage in a market that hasn’t yet discovered those needs), and actionable evidence to guide and defend user-focused design decisions. Of course, this would often look like:
- making research plans
- conducting in-home research
- leading synthesis
- creating decks to share findings
- moderating a usability study,
But because the ultimate goal is evidence, mission, and guidance, it might also look like training the team on how to conduct research, or even outsourcing it on occasion. And of course, the team would defer to the research lead to know what was really discovered about what users really need, or whether the evidence backs up the direction.
ORIENTING ROLES THIS WAY shifts the mindset; it’s about mission and results, not tasks and territory. It leaves space for generosity, and reduces the fear that can easily divide teammates. It helps us move from an emphasis on activities, outputs, and territory to purpose, growth, and effectiveness.
Hope this helps you build a more effective team.