Category: teams

“Agile” product practices, whether, Scrum, SAFe, squads, etc., encourage the formation of independent, self-sustaining teams. As the importance of design has become more broadly understood, these ‘user-facing’ product teams often feature an embedded designer, working with a product manager (or product owner), and some number of engineers, as depicted in this diagram:

Diagram depicting product teams, with one designer, one PM, and n number of engineers per team

When you embed this designer, you’re now asking that individual to deliver across a daunting range of capabilities:

Diagram showing the designer in the center, and their responsibility for visual design, interaction desing, copywriting, user research, strategic thinking, information architecture, communication skills, leadership, and planning

The plight of the Junior/Entry-level Designer

Any junior designer thrown into this situation struggles, as they don’t have the experience and expertise to handle this. Often, the Product Manager is a mid-career contributor, who doesn’t know how to coach up designers. So, the junior designer ends up acting as a production artist, serving at the behest of the Product Manager. I hear a lot about Design organizations that are seen primarily as production shops, and it’s almost always for this reason—the designers aren’t true peers to product and engineering, and are just expected to do what they’re told.

Given this, a common refrain I hear from design leaders is that they cannot hire junior designers, because they need to bring people on who can slot into this context and hold their own. This is exacerbated by the design leaders often being spread too thin, so they don’t have any capacity for mentorship.

So, junior designers are caught between a rock and a hard place:

  • they’re hired into an untenable situation, and struggle to do anything more than be a production artist (and wonder why they bothered getting that fancy design degree if they can only practice 20% of what they learned)
  • they keep hearing about how “there are not enough designers,” but they can’t get anyone to even talk to them about a job

Everyone suffers when we don’t make space for junior designers

This ends up creating additional stresses within design teams and the broader design industry. Within design teams, there’s a constant struggle to find senior talent, as these teams have no internal pipeline in which to mature designers, and senior designers are highly sought after in the recruiting market. Also, because there aren’t junior designers in the design team, the senior designers end up doing a lot of production-level work, which takes time away from more impactful, bigger-picture work, and which limits the strategic contribution that the design team is able to make within the organization. So then these senior designers get frustrated and burned out, and leave in order to find opportunities that are more fulfilling.

Within the broader design industry, there’s a recognition of a severe lack of talent to meet demand, but we end up getting in our own way as we continue to forsake training up junior designers. 

A way forward: organize design around teams, not individuals

This challenge with junior designers is one of many reasons why I advocate thinking of building design orgs at the level of team, not the individual. 

Diagram showing how designers can work in a team, across a set of product teams

In this model, instead of embedding designers within product teams, designers are pulled out into their own team, working across set of product teams addressing some contiguous aspect of the user experience. Instead of needing each designer to be an identical unicorn, a team of designers can have a range of experience and a variety of skill sets. The “S” designers are Senior designers who maintain the relationship with Product Managers across two product teams. They engage that Product Manager as a true peer, not as someone who just tells them what to do. The “D” designers are junior and mid-level designers who can float to where they are needed. They don’t work on their own, but always with the guidance of a senior designer or the Team Lead (TL). This is how they develop their practice. (Unrelated, but worth calling out: Since we’re operating as a team, team members can have distinct skill depths. So, here, we have a Content Designer (“CD”) who can bring expertise in writing and information architecture to the work being done.)

Through a model such as this, we have made room to bring in junior designers, situate them in a way that they can learn and grow, enable more Senior designers to focus on higher order challenges, and have created an internal pipeline to develop team members so they become our next generation of senior designers as we need them. 

“Agile” orthodoxy is harmful to the practice of design

To simply follow standard practices for “Agile” development (I’m putting “Agile” in quotes because I recognize that these practices often conflict with the original intent of the Agile movement), is to sell short the future of design as a function and a practice. We need design leaders to advocate for organizational structures and processes that enable design to deliver on its potential, or we will continue to see designers treated as subservient to other functions, order takers with little agency in their work.

Many design leaders who have inherited a team have a story of being told, by their new boss, something to the effect of, “Yeah, so, you should know, there are a couple of people on your team who are underperforming, and you’ll probably need to manage them out.”

This sets immediate alarm bells, not about the designers, but about an organization that couldn’t handle its own mess. Thing is, nearly every time I’ve been in that situation, I’ve found that the reason the designers were underperforming had little to do with the designers’ themselves, and everything to do with the context in which that designer was operating (little guidance given around the problem being addressed, unreasonable expectations for executing within a certain time frame, constraints due to technical debt, etc.). 

Oh, and, typically, the designer had never been told directly that they were seen as underperformers. Ruinous Empathy (™ Kim Scott, Radical Candor) had lead their colleagues to provide anodyne feedback, while they talked behind their back, and to their boss, about how so-and-so “just doesn’t seem to be working out.”

So when I helped that designer improve their context, their performance improved as well.

I’m thinking about this as I read Patrick Lencioni’s The Advantage, which I’m finding to be an excellent read on team building and leadership. It contains ideas from his other books, notably The Five Dysfunctions of a Team, and one of those Dysfunctions is not holding people accountable. I highlighted this passage:

Some [leaders] will tell me that since they aren’t afraid to fire people, they must not have an accountability problem. Of course, this is misguided. Firing someone is not necessarily a sign of accountability, but is often the last act of cowardice for a leader who doesn’t know how or isn’t willing to hold people accountable. 

Holding colleagues accountable (whether peers or people in your organization) is one of the hardest thing for leaders to do, because it requires one-on-one, typically face-to-face communication, and where you will tell someone how they are not measuring up. But, done well, it’s the best thing you can do for that colleague, as it is through constructive feedback that they grow. Not being forthright with someone about their performance, or hiding behind performance review and PIP processes, is not being kind; it’s being selfish. 

Over the past couple of years, I have become obsessed with the dynamics of work teams, reading such seminal texts as Teaming, The Wisdom of Teams, The Five Dysfunctions of a Team, Team of Teams. It is from works such as these that we learn the importance of psychological safety, trust and accountability, and the distinct and evolving role of leaders. 

And while each advocates for small, cross-functional teams as the heart of how work gets done, I’ve yet to find someone address what I consider to be among the biggest barriers to collaboration within these teams—the distinct cultural values of each function. 

The function/discipline I can speak most for is design (including UX research and content design). I have conducted numerous sessions with design teams to identify the values they hold most dear, and inevitably among them are compassionate concerns such as: (all are drawn from actual team charters I facilitated):

  • Empathy (more on that in a moment) 
  • Humility
  • Caring
  • Inclusivity
  • Supportiveness
  • Approachability

Though I have not conducted similar exercises for other functional teams, having worked with product managers, engineers, marketers, sales people, etc., I do not believe these values would rank. I’m not saying other function are heartless—I’m just saying that design teams wear their hearts on their sleeves. 

And the point I want to make is less about compassion specifically, and more generally that every function has its own culture, values, intellectual foundation, and norms, and those fundamental characteristics lead to distinct ideals and differing behaviors. 

Related sidebar about empathy.

In literally every team charter exercise I facilitate, when we identify the values of the design team, “empathy” emerges as core.

Every time, I implore the team to reconsider, as “empathy” has become clichéd. And every time, the team, while acknowledging this, says that they need to keep the value, as no other function in their organization demonstrates the value, and so it is key to their identity in relationship to others.

Sidebar to the sidebar:
I think that’s kind of fucked.

And when we create cross-functional teams, we typically just throw people together from all these different backgrounds, and do nothing to help them find common ground. Given that, we should be surprised when teams perform well, instead of disappointed when they do not.

I’m realizing there are a number of different directions this line of thought could lead me:

  • How designers are marginalized because the compassionate values core to their identity are marginalized within businesses
  • Rituals for establishing teams that enable common ground that engenders trusting relationships
  • The schizophrenia/cognitive dissonance we ask of folks to be a good ‘team player,’ which requires some degree of sacrifice and compromise that isn’t every acknowledged

In later posts, I may pursue some of these threads. At this point, I simply want to shine a light on the very real and impactful influence of distinct cultures within teams, and how those must be acknowledged and addressed if we want cross-functional teams to thrive. 

This year, I’ve helped 5 design teams draft their charter. At the outset of this work is a series of 4 2-hour group sessions (it used to be a one-day workshop in a conference room) to define different aspects of the team. Having done it a bunch now, I’ve developed a fairly strong agenda for conducting these sessions, which I’m now sharing publicly. Feel free to use it for your team!

Agenda for Group Sessions to Build a Design Team Charter

Embedded in that agenda are links to a series of public Miro boards for capturing the group work. I think (?) you should be able to copy the boards to your own account, and if not, they’re pretty easy to recreate.

Why draft a charter?

As design teams grow, they often realize that there’s a set of assumptions about they work they do, assumptions put on them by people outside design. These assumptions end up constraining the potential of the design team, and they find themselves focused on production when there is so much more they could offer.

I believe these charter projects have proven popular because they provide a platform for a design team to define itself, to set its own course and agenda. They help teams build confidence taking control of the kind of work they do, and how they do it. This empowerment, in turn, makes the teams more effective, as they feel greater connection to their work.

“If Design Were A Person” Activity

Most of the activities are fairly straightforward group work to arrive at some common understanding, with a divergent phase (generate a lot of ideas), grouping and organizing, and then a convergent phase (voting) to arrive at a result.

These activities tend toward the logical, verbal, rational. Working with design teams, I wanted to tap into the creative, pictorial, visceral. When I conducted these group sessions in a conference room, I would use the Design The Box activity to get people in that generative, lateral thinking mode, hoping to tap into stuff that’s subconscious. I tried bringing that into a remote session, but I find that drawing tools just aren’t sufficient in these platforms, and were getting in the way of creation.

So I changed it to a “If The Design Team Were a Person,” with the idea that we still have imagery, and there’s something subconscious that goes into the identification of that person, with a post hoc rationalization of the qualities of that person and how they apply to the Design Team.

That said, I’m not thrilled with the exercise. It works, and I’ve gotten good stuff from it, but I suspect it could be better. I’d love to hear from folks on generative, creative activities that they’ve facilitated remotely.

The Sessions Are Only The Beginning

The group sessions account for about a half to a third of the total effort in charter building. The sessions are great for getting ideas out of people’s heads, and the voting and discussion that happens places focus on the specific areas that are most resonant to the team. After the sessions are complete, then someone (or a small group) needs to take what’s been generated as input into the drafting of a charter, which is a process of distillation, wordsmithing, refinement, a lot of dead-ends, and occasional epiphanies—much like any writing work.

I’ve very much enjoyed facilitating these discussions, and if you’d like me to do so for your team, you can reach me through my website.