Author: Peter Merholz

Design as an executive function is new, so Heads of Design are typically lonelier than their peer leadership positions. Your boss may have never had a truly senior Design leader report to them, and doesn’t really understand all that a Design team can deliver. You’re only Design leader on executive team, whereas there are multiple Product Management and Engineering leads.

This means that there’s no one to turn to internally as you try to figure out how to best lead your Design organization.

This is where I come in. I support executive Heads of Design in a mode I call “Thought Partnership.” I work with design leaders to accelerate thinking through their trickiest challenges, leveraging my experience (20+ years leading design teams; 5 years as a management consultant across all kinds of design organizations) to identify paths forward, enabling Heads of Design to make important, impactful decisions with confidence. Recent work with design leaders addressed such matters as:

  • Scaling from 30 to 100 team members
  • What their job actually is, where they should focus (and what they need to delegate)
  • Building career architectures and leveling frameworks
  • Improving recruiting and hiring practices
  • Establishing Design Operations
  • Elevating Design’s impact in the company
  • Evolving product development practices to better incorporate design throughout the process
  • Articulate a strategic vision to align product efforts

I’ve done this work ad hoc, in response to design leaders reaching out to see if I could support them. It has been some of my favorite work, capitalizing on my distinct vantage point to help leaders go from uncertain to confident, and see real impact in short time frames. 

As such, I’m now setting aside more time for this kind of work, and, well, telling the world that this is a service I’m happy to offer. 

It’s a small investment of time: the work is typically structured as one or two 1-hour sessions a month. In each session the Design Leader shares with me their topmost challenge, and we work together to figure out the best way forward. 

If this is something you’d like to take part in, please reach out through email, and we can then set up follow-up discussions.

On a recent episode of Finding Our Way, Jesse and I spoke with Tim Kieschnick. I worked with Tim for about a year, and learned a ton from our collaboration. He’s an interesting cat—he worked at Kaiser Permanente for 30 years (until retirement), and in that time helped establish their web presence, UX as a practice, service design, and HCD/Design Thinking/Design Sprints. He’s a reflective practitioner, and through his experience developed two frameworks which I have in turn used in my thought partnership practice with design leaders. I was eager for him to share his wisdom on our podcast.

The 3Ps of the Leadership Ceiling

A little over a year ago, at my urging (so I could refer to it without feeling like I was plagiarizing), Tim posted an introduction to The Leadership Ceiling. (some of what I write here will repeat what’s over there, but in my words.) At heart, it’s a simple construct: Leaders create a conceptual ceiling above which their organization cannot rise. Tim identifies three ceilings:

Purpose

Why does this organization exist? How is that purpose articulated? Are we driving toward output, or outcomes? How does our purpose inspire, connecting people with their higher, better selves?

People

Who is in this organization? What is the caliber of contributor? And, are we creating a truly people-centered organization that enables those folks to deliver at their best? 

Process

How is the work getting done? Does our process bog us down, or lift us up? How are we coordinating across functions? Are people spread too thin, across too many initiatives, or are they able to maintain focus and commitment? Are teams empowered to practice a process that is ‘fit for purpose,’ or is there an imposed standard way of doing things that cannot be deviated from?

(This is reminiscent of what Daniel Pink identified in Drive, in terms of what it takes to motivate people: provide them Autonomy (process), Mastery (people), and Purpose.)

In my experience, I don’t see three ceilings, rather one ceiling that is a product of how these three factors intersect. In my work with design leaders, looking at the intersection has proven helpful, because it illuminates why there’s cognitive dissonance between the message they’re getting from their leadership, and why the work doesn’t meet their expectations. 

The diagram to the right shows my take on this aspect, which is that the Leadership Ceiling is set by which ever factor is lowest. 

For instance, I’ve supported a number of banks and insurance services firms. And nearly all of them have high-minded aspirations for their business, with mission statements about empowering people’s financial wellbeing, or improving the health of all Americans. And these firms will also have committed to providing a much more conscientious work environment that encourages bringing your whole self, and stresses values of psychological safety and vulnerability.

But these large legacy organizations are bogged down in process, for reasons including bureaucracy, poor organization design, unwillingness to truly empower teams, people spread too thin across too many workstreams, etc. 

And so, the Leadership Ceiling is established by that lowest factor. And the design leaders I work with, who may have been sold on a company’s vision and culture, then struggle when they realize that for all that high-and-mighty talk, their ability to deliver is severely hamstrung by a lack of attention to process. 

The ABC’s of The Leadership Ceiling

Once you understand the height of a Leadership Ceiling, then you have to figure out your relationship to it. Tim uses an ABC mnemonic to think through what you can do:

 

Diagram of the ABC of The Leadership Ceiling from Tim’s website.

You can try to work Above the ceiling

This approach is pretty common for designers, particularly new to an organization, who see their job as to ‘fix’ whatever came before, or to realize a bold new innovative vision. And they may see their leader’s Ceiling, and perhaps engaged in some effort where they bumped their head on the ceiling, and then see their job as the innovative iconoclast to work above the ceiling, to show to the rest of the org just how great it can be. 

This never works. You might get some time to play in that rarefied air, but inevitably the leader’s Ceiling does its thing, often in the form of the Leader being frustrated that the designer isn’t doing what was expected of them, instead pursuing some quixotic endeavor that was bound to go nowhere.

So, most of us end up working Below the ceiling

We realize that we are constrained by the leader’s ceiling, and focus our efforts there. The dream is to have a leader with a high ceiling across all 3Ps, providing all kinds of headroom to innovate and grow. But most of us find ourselves below a ceiling lower than our liking, and so we have to make a choice:

We can Bail. We may believe that we’ll never reach our potential, or that work will be endlessly frustrating, and given our limited time on this planet, we want to focus our energies elsewhere. (This has been what I do. This model has helped me realize that I have little tolerance for working under a low, or even medium-height, ceiling.)

We can Bide our time. We make the best of the situation in front of us, delivering excellence within the leader’s constraints. Biding may sound defeatist, but it shouldn’t be perceived as settling. It can be a smart and pragmatic strategy of getting things ready for when the time comes and either our leader raises the ceiling, or is replaced by someone with a higher ceiling. In the podcast, we talked to Tim about telehealth, which Kaiser Permanente had been pursuing for 25 years. And if you were passionate about telehealth, you were likely frustrated, because it never caught on the way you felt it should—the organization wouldn’t invest in it and the membership didn’t seem to appreciate the convenience. 
And then 2020 happens, the world goes on lockdown, and that causes the Ceiling to be raised on telehealth. And all those folks who had been biding their time, waiting for the moment, are now center-stage.

Some bold souls may seek to Change the ceiling

As Tim puts it, this “is not for the faint of heart.” But if you are frustrated by the height of the ceiling, and you’re not content working Below it, and you’re committed to the organizational cause and so you won’t just Bail, you can try to change the ceiling. This requires diagnosing just what is depressing the ceiling, developing an argument and a plan for raising the ceiling, and then doing the hard work of education and evangelism to persuade leaders to change the ceiling. This is particularly tricky, because those leaders, over their career, have received a lot of confirming feedback about the rightness of their decisions, and now someone within their org is going to tell them that they’ve got it wrong? So, it requires delicate, incisive, and persistent communication to figure out what stories resonate with the leader and encourage them to evolve their view. 

I’m so grateful Tim spoke with us, and driving broader awareness of this framework. I’ve found it quite useful in my work helping design leaders succeed, and I’d love to hear (or read) how it works for you. 

“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.

Every design manager knows there’s an intense war for talent.  It’s been going on for the past 15 years, and has definitely ratcheted up in the past 12-18 months. 

Last year, I supported one team that grew from 14 in March to over 40 by the end of the year. This wasn’t some sexy tech company—it was enterprise SaaS supporting HR. I point this out because, even in with all the competition, it’s quite possible to scale an organization. The issue, which I’ve seen over and over again for years, is that most design orgs are just bad at recruiting and hiring, getting in their own ways. Here are the top mistakes that I’ve seen. 

Hiring Managers don’t devote the necessary time

Hiring Managers are busy people. Their attention is pulled in many directions. They are expected to lead their team, provide creative vision, manage the individuals, partner with cross-functional peers, roll up their sleeves and do the work, oh, yeah, and build their team. That last item gets deferred, as it doesn’t have the urgency of their other responsibilities. As such, many Hiring Managers find themselves in this cycle:

Depicts the vicious hiring cycle

Perhaps the single most impactful thing a Hiring Manager can do is protect their time for recruiting and hiring. When active, expect to spend about 4 hours per week per open headcount—this accounts for time spent sourcing, reaching out to prospective candidates, initial conversations to gauge interest, deeper conversations once someone applies, and the background stuff around planning and preparing others to support the hiring process. 

Over-reliance on Recruiters

When I counsel design executives and their leadership teams about recruiting and hiring practices, I often get a variant of the reply, “Isn’t that the Recruiter’s job?” The short answer is: No. 

This isn’t to say you shouldn’t develop a strong partnership with your Recruiting team. But, I’ve seen, again and again, that when Design Leaders rely on a separate Recruiting team, particularly for sourcing potential candidates, their efforts come up short. 

The Design Org needs to own their recruiting and hiring practices and processes. The Recruiting partners are their to support you, not do your job for you. 

Under-reliance on the rest of the Design org

While Hiring Managers need to be the engine that drives recruiting and hiring, this doesn’t mean they operate as lone wolves, expected to do everything on their own. Hiring Managers must rely on support from others in the Design organization, specifically:

  • Their manager — to help them protect their time, and manage the relationships with peers who may be upset that the Hiring Manager is focused on recruiting, and not “the work.”
  • Their team — Hiring Managers should engage their team members in sourcing, gauging interest, and interviewing. Not only is this an example of “many hands make light work” (ok, lighter work), I have found that passive candidates (i.e., those not actively looking to change jobs) are often more receptive to outreach from another designer, in a way that they are not from a Design Manager, and definitely not from a Recruiter.
  • Design Operations — Any scaling organization should have a “PeopleOps” person specific for Design, and among their responsibilities is maintaining a set of robust tools to support the recruiting process: job descriptions, career and levels frameworks, question banks, and assessment rubrics. 

Insufficient articulation of the role(s) to be hired

Hiring Managers know they need people, and often take an existing job description, lightly revise it, and post it. They rarely do the diligence to figure out what they actually need in the role. This hinders the recruiting process, as it becomes apparent, through conversations with candidates and colleagues, that there is not a shared understanding of the profile we seek to hire. 

This is a classic example of “measure twice, cut once.” A little more work upfront will lead to far less time spent down the line. 

One tool I’ve begun to see great promise in is the Thank You Note, as posited by Jared Spool. This is an “artifact from the future,” where the Hiring Manager drafts a memo thanking the person for what they’ve accomplished in their first year. Putting yourself in that ‘year ahead’ mindset, while forcing yourself to be specific, results in essentially drafting the job description. 

Cavalier recruiting processes that ignore known best practices

This frustrates me more than any other aspect, because solid practices for recruiting are not mysteries, but teams neglect them. Hiring Managers resort to what they’ve done in the past, and everyone wonders why it’s so hard to find good people. 

Processes that are too lengthy or too brief

For a client I supported in 2016, I recommended shortening the interview day (which takes place after initial phone screens) to “5 hours, 6 hours most.” When I recently re-read that, had I been sipping a beverage, I would have done a spit-take. Because while that amount of time is too long, I’m now seeing teams that spend 2 hours with a candidate, total, before making a hiring decision, driven by the need to ‘act fast’ in this competitive market.

In my experience, there’s a “Goldilocks” scenario that works for most design/research/content hires:

  • Two 30-45 minute phone screens, one conducted by the hiring manager to get a sense of the candidate as a professional, another by a team member digging in to the specifics of their craft
  • Panel Presentation + four 1:1s, taking about 2.5-3.5 hours

You need to spend enough time to feel confident in the ‘signal’ you’re getting. But too much time leads to diminishing returns. 

Adversarial stances with candidates

Many hiring managers (and their broader recruiting context) approach engaging candidates in an adversarial way, where the candidate has to ‘prove themselves’ worthy of consideration. Fuck that masculine posturing bullshit. Your company isn’t so great that it can act as if they’re deigning to speak with someone.

I’ve also heard Hiring Managers say that they don’t want to provide too much information (see the next item), because they felt part of the process was the candidate to figure out what’s expected. Recruiting processes shouldn’t be the conversational equivalent of an escape room, where the candidate solves the puzzle of ‘how do I get hired?”

And, for my sake, just stop with the design exercises.  No, really.

No preparation for candidates or interview panelists

Perhaps because of the time constraints mentioned at the outset, I often find Hiring Managers (and Recruiters) do almost nothing to prepare either the candidates or the interview panelists about the process and what’s expected of them. 

With candidates, sometimes it’s a matter of the prior point on adversarial stances, but often it’s just thoughtlessness. Apart from blocking time on their calendar, candidates often have no idea what to expect from conversation to conversation. 

With panelists, often, they learn about an interview when a slot is dropped on their calendar, with no context, not even a resume or LinkedIn profile. 

Candidates should be provided extensive preparation for the process. How long it will take; what the steps are; how to shape their portfolio presentation; whom they will be meeting and what topics will be addressed. We want to best know the candidate, and that means enabling them to present their best self.

Panelists should be coordinated such that each has a topic area that they dig into, and a set of questions to draw from. This avoids needless duplication across 1:1 interviews, and ensures a broader understanding of the candidate. 

Gut-level judgment of candidates

Throughout the process, the assessments of candidates are typically superficial and gut-driven. Hiring Managers and panelists may take notes, but often there’s no standard by which to make a judgment, and so hiring decisions are based solely on feeling, rather than a considered judgment, placed against a robust profile of the role.

This gets back to the issue shared earlier, where Hiring Managers insufficiently articulate the profile of a desired candidate, so people don’t have a clear frame of reference for their judgment. This can lead to a couple of different problematic outcomes:

  • the endless searching for some kind of unicorn who satisfies everyone
  • offers extended to a candidate that everyone likes, but is actually not suited to the role: for example, hiring someone as a Lead Designer because everyone thinks highly of their design skills, but not enough was done to assess their leadership characteristics

A lack of up-front clarity also contributes to implicit bias, favoring candidates who ‘look the part,’ whether or not they’re best suited. 

Assessment rubrics for each stage of the process should be clearly defined ahead of time. I’ve published a tool I’ve used to support portfolio reviews. You’ll need to come up with your own for other stages. 

With solid assessment rubrics, hiring decisions become much clearer and with reduced bias. You know when someone is qualified, and you’re confident in making an offer. 

And there’s more…

What’s shared here are the top mistakes that, in my view, contribute the most to poor recruiting outcomes. But by no means are they the only issues that commonly arise. Others include:

  • Poorly written job descriptions, typically too vague, boilerplate, and littered with non-inclusive language that discourages qualified applicants
  • Unclear or undefined levels framework, so judgments about job requirements, and then candidate aptitude, are made without any frame of reference
  • Sourcing practices that don’t go beyond posting a job to a LinkedIn profile and hoping for the best
  • Waiting too long to address the compensation conversation, only to find out in the offer stage that your salary band doesn’t meet candidate expectations
  • Lack of appreciation for reference checks, the only tool in this process that  engages people who have actually worked with the candidate

If this sounds like a lot, that’s because it is

Generally,  design orgs simply have not treated recruiting and hiring with the focus, attention, planning, and effort that it deserves. It is somehow just expected to get done. 

I find the story I told at the beginning, of a team going from 14 to 40 in a year, to be illustrative of a path forward. I was supporting that team, and probably spending ~10-15 hours a week on various activities that support recruiting (career ladders, job descriptions, working with recruiters, sourcing, interviews, etc.) By having a senior person in a People Ops-like role, who wasn’t weighed down with explicit management responsibility, who could develop materials to support recruiting practices, and also drive the effort in hiring key leadership roles, this team was able to scale quickly and with quality. Most teams aren’t willing to make such an up-front investment, instead hopeful that they can get by with what they have. What I’ve seen, though, is that orgs that make that investment, realize a worthwhile return. 

From a VP of Design I work with:

“I had to have an intense conversation with someone on my team, who is struggling with the shift from Design Manager to Design Director. The Product Lead this Director works with has started reaching out to me again. When I dug into it with her, I found that she’s still doing the thing that Product Managers love, getting into the nitty-gritty details. But the Product Lead is still waiting for a vision statement, a hypothesis around where the experience could be going. She went too deep too fast, and hadn’t gotten alignment on strategic direction.”

When working with executive design leaders across organizations, I often hear something along these lines. Their Managers and Directors don’t know how to best spend their time, and where to focus their attention. Interestingly, I hear something similar from C-level people about design executives—they’re too focused on their team, and not the organization as a whole.

What many design leaders don’t understand is just how much their role changes, in particular, the relationships they need to have, as they advance in their career. 

Design Manager

A Design Manager is someone relatively new to formal leadership, and has people reporting into them, anywhere from 3 to 8 (any more than that, and the Manager will be overwhelmed). 

Diagram of how a manager spends their timeTheir primary orientation is downward. They’re focused on getting the most out of the team the manage, making sure they’re delivering on expectations in terms of addressing problems and upholding quality.

Their secondary orientation is sideways, working both with Design Manager peers to drive coherence across teams, and working with cross-functional peers (Product Management, Engineering), to coordinate and plan delivery efforts.

Design Director

When we promote a Design Manager to become Design Director, we often don’t communicate how this is a fundamentally different job than the one they had before. As the quote that started this post shows, many new Directors resort to the practices that helped them succeed as a Manager, but those will get in the way of their performance as a Director. 

Diagram of how a Design Director spends their timeA Design Director’s primary orientation is sideways, and not only that it’s mostly outside of Design. An effective Design Director should be spending more of their time and energy working with non-design peers and other stakeholders than with any other kind of colleague.

Their secondary orientation is downward, with a focus on managing their Managers. Their job isn’t to get into the nitty-gritty themselves, but to provide guidance and mentorship for their reports. Directors are also crucial for establishing the management culture and philosophy for their teams. But they shouldn’t need to spend anywhere near the time they used to in managing down, because, well, they have managers to handle that. 

Lastly, a Director will spend a small portion of their time managing up, to their VP and non-design leadership, keeping them apprised of what’s happening in their world, and learning overarching strategy and vision in order to make sure their organization is aligned with global goals. 

Design Executive (S/VP of Design)

When talking to CEOs, their primary concern about Design Executives is that they see themselves as a Design Leader first and an Organizational Leader second. CEOs expect Design Executives to see their cross-functional peers as their “first team.” with the design organization as their second.

How a VP spends their timeAnd in terms of time spent, it goes even farther than that. The Design Team should be where a Design Executive spends the least amount of time. Their primary orientation is sideways, toward their executive peers. This is about planning and strategy for the organization, identifying opportunities for the business and how their coordinated teams can realize them.

Their secondary orientation is up and out. It may seem counterintuitive that an executive would spend so much time engaging with a small number of even more senior executives, but that’s the reality. That’s your key audience. They’re the ones who are needed to support the plans of the Design Executive and their peers, to commit the resources necessary. “Out” may mean executive leaders outside your direct reporting chain, and in some environments it may mean key customers or partners. As a Design Executive, you now represent the company in a variety of contexts, both internally and externally.

A high-performing Design Executive should spend their least amount of time focused on matters within their Design Organization. It may take a while to get to this point—it requires a strong Design Leadership team, and effective operational practices around recruiting and hiring, staffing, performance management, quality standards, etc. But, really, a Design Executive shouldn’t need to spend much time orienting downward, because they should be able to rely on their org to get stuff done. 

 

 

This post builds on the Emerging Shape of Design Orgs.

As design organizations scale, I’ve worked with a number of design leaders who struggle with all that’s expected of them. Let’s look at the “HR Software” org I drew in the last post. 

No Time for Creative Leadership

The VP Design is a true design executive, and, as I wrote in The Makeup of a Design Executive, is expected to deliver on Executive, Creative, Managerial, and Operational leadership. The thing is, with a team this size, and particularly if it’s growing (as so many teams are), they simply don’t have the time to do it all (unless they work 60-, 70-, 80-hour weeks). And these VPs need to focus on what’s core to their role, which are the executive and managerial aspects, and so the creative leadership suffers.

Even the Design Director is spread thin—overseeing a team of 15-20 people, recruiting and hiring, encouraging professional development, building relationships with cross-functional peers. This takes up all your time, and, apart from weekly critique sessions, they don’t have capacity to provide creative and strategic leadership to their teams. 

Which Means No Time for Strategy

Design organizations are increasingly expected to contribute to product strategy, but these structures support little more than product delivery. If the team is asked to develop a vision for the future product experience 2-3 years out, how do they get it done? 

One way is to hire external consultancies. And that can serve as a good kickstart, but such relationships should be seen as bridges toward when the design org is able to conduct its own strategic practice. 

And as design orgs scale, and design leaders develop organizational authority, a common move is to create a Design Strategy group, a small team of senior designers to tackle wicked problems outside of the constraints of business as usual. It may look something like this (building on the depiction of the growing design org from the last post):

Scaled design organization with Strategy team tacked at the end(There’s an argument to be made that the Strategy Team could be a pillar of the Platform team. The point that follows wouldn’t really change.)

Separate Strategy Teams within Design Orgs suffer the same problem that any separated team has—getting traction. Now, looking at the diagram above, you could say the same about the Platform team, but in that case, the Applications teams all understand why integrating with Platform makes sense—the Application teams can focus on the higher order work specific to their business area, and move faster. 

Now take the perspective of an Application team. That Strategy Team gets to do fun vision stuff, play in a space with little accountability, and then what… tell us what to do? And if we try to work with the Strategy Team, we’re told that they’re looking at broader, end-to-end experiences, and don’t want to be confined to any particular business area.

And so the Strategy Team gets frustrated because while folks may get excited about their ideas, it’s not clear how they get purchase within product development.

Two Birds (Creative Leadership and Strategy) and One Stone: The Shadow Strategy Team 

So, scaling design orgs have a problem. The acknowledged leaders (executives and directors) don’t have the bandwidth to provide the strategic and creative leadership expected of them, and necessary for the optimal effectiveness of the team. Building a separate Strategy team addresses some of this, but is typically too removed from the actual work to make an impact.

A solution lurks within the Emerging Shape of Design Orgs, with the addition of Super Senior ICs . Design organizations are increasingly hiring Principal Designers and Design Architects, as shown in this diagram (click/tap to enlarge).

Scaled org with Super Senior ICs added

Design Architect. Reporting to the VP of Design, they have no managerial or operational responsibilities, and so are able to focus on creative and strategic leadership. I’ve written this job description a few times over the past couple years, and here is what the “Responsibilities include…” section looks like:

  • Provide creative and strategic leadership for design and throughout product development
  • Advocate for user-centered design best practices within product development
  • Partner with product and engineering leaders across the company
  • Spearhead the development of experience-led product vision across the entire product suite
  • Provide guidance and direction for key ‘horizontal’ activities such as Design System development
  • Create strategic design deliverables such as strategy decks, customer journeys, visions of future experiences and evangelize these cross-product “blueprints” across teams
  • Build and maintain a framework for establishing and assessing design quality
  • Connect design with business value
  • Work with design, research, program management, and product leaders on process for product development

Principal Designer. This role is similar to the Design Architect, just within a specific business area, reporting to a Design Director. The primary difference is that they are also involved with design delivery, playing a very active role in design direction and critique, and occasionally serving as a “big project Team Lead,” spearheading important and challenging new product development.

The Shadow Strategy Team. With a Design Architect and Principal Designers in place, you now have the constituents of your Shadow Strategy Team. Instead of a separate group of strategic designers, they are woven into the fabric of the producing design organization.

The trick is, how to get them working as a team? That’s primarily the responsibility of the Design Architect, with leadership support from the VP and Design Directors to protect some of their time for organization-wide efforts. At a minimum, this team meets weekly to share what’s happening in their worlds, and to ensure efforts are connected across the end-to-end experience. Occasionally, the Design Architect may engage Principal Designers on vision and strategy work, with the benefit being that these Principal Designers ensure that the vision is grounded in the reality of the business areas.

Recapturing some of the Dream of UX

A common frustration among digital designers is how their practice has been reduced to production. I think a reason for this is that our organizations lacked creative and strategic leadership—we assumed it was coming from the executives and directors, but they were too busy just keeping things going. So it just wasn’t happening.

By having roles within this explicit focus, these super-senior practitioners provide can recapture the untapped potential of thoughtful, intentional design. 

 

In my previous post, I laid a foundation for thinking about the emerging standard shape of a product design organization. In the comments and on LinkedIn, a number of questions and comments came through, and by far the most addressed Design Systems and related platform matters. 

From what I’ve seen, while the overall shape of a design org is settling into something like I’ve shown, where specifically Design Systems lives varies from org to org. Earlier this year, I supported an enterprise software team building HR tools. From what I gathered, our plan for design org structure is one that’s emerging as a standard within enterprise software. I’ve altered some details for the sake of easier communication (tap/click to enlarge). 

Applications (or Experiences) and Platform. For years, working within product development organizations, I witnessed a lot of resistance to the idea of “Platform” or “Shared Services” teams. In the move to “Agile” there was a desire for every team to be an autonomous unit, capable of directly delivering value, with no dependencies on any other team.

As these orgs scaled, this proved to be folly, with teams needlessly duplicating effort, and recognition that dependencies are not a bad thing, just something worth coordinating. 

More recently, many companies are moving toward splitting product development into two big areas: Applications (or Experiences) and Platforms. In their latest book EMPOWERED, acknowledge product leadership experts Marty Cagan and Chris Jones write about this at length, defining platform teams as those “which manage services so they can be easily leveraged by other teams,” and experience teams as those “which are responsible for how the product value is exposed to users and customers.” 

Applications. In the prior post, there were generic BUSINESS AREAs. Now we’re making them specific. Applications refers to the specific, well, applications within the HR Software suite. If you’ve ever applied for PTO through software, you’ve used such an application.

Application Sub-teams. Given the size of the Applications design org, it’s best to break it up into smaller teams (team effectiveness drops considerably once a team is more than 7 people). One of the arts of organization design is figuring out the size and mandate of such sub-teams. In this case, we have three: Recruit and Hire, Onboard and Work, Comp and Benefits. The idea is for each time to have a meaningful and manageable chunk of the employee journey.

In my observations, it’s common for design orgs to be understaffed relative to the number of product teams or squads they are meant to support. So, for example, the “Recruit and Hire” designers may be working across 7, 10, even 15 Scrum teams delivering Recruit and Hire functionality. How that is handled is the subject for another day. The point here is that all the designers working on Recruit and Hire functionality are part of one clearly defined team.

Platform. This team designs stuff that is not specific to an aspect of the experience, but undergirds everything. 

Shared Experiences. In the comment to the prior post, Jorge Arango asked, “I’m wondering who looks after the structural integrity of the system across the org. (E.g., global nav, search results, etc. — IA stuff.)” This team is responsible for that. The integument and scaffolding that contains the rest of the experience. These are specific features and functions, such as global search, logged-in start page with modules specific to that user, and navigation schemes. 

Design System. A Design System is the very definition of a “service [to be] easily leveraged by other teams.” This team is staffed with experts in specialized design roles (Visual Designer, Accessibility Designer, Content Designer), since their work is leveraged by the rest of the organization.

These are not the only people working on the design system. The expectation is that this is a cross-functional team with product manager(s) and engineers. These are the people on the design team working on the design system. 

As the org continues to grow…

As I mentioned earlier, Applications sub-teams are often understaffed. Let’s say that’s been realized, and those teams are now growing. Instead of being sub-teams, they are now BUSINESS AREAs, each with a design director and teams within. (click/tap to enlarge)

Scaling design organization with platform design remaining the same, on the left

As a leveraged team, the Platform Design team should not need to grow at the same rate as Applications/Experiences team. It can remain stable, supporting a growing design organization (and product development organization) without needing to add people. This distinguishes it from UX Research and Design Ops, which need to grow with the rest of the team.

What’s worked for you?

Design Systems and Structural Integrity is an area where I’ve seen far less commonality across design organizations. But I think our field is maturing such that we should have “better practices” (maybe not ‘best,’ yet) identified that serve as guides. Please share in the comments!

Laying an organizational foundation

As a consultant focused on the org design of design orgs, I work across a variety of contexts—established businesses (banks, retail); software as a service (enterprise software); scale-ups (pre-IPO and growing); start-ups. And repeatedly over the past couple of years, I’ve found myself drawing some variation of the following generic digital product design org chart (click/tap for full size).

Generic digital design organization chart

Let’s look at the various bits.

VP Design. A true executive role, with budgetary and headcount authority, often reporting to an SVP of Product Management (and occasionally to an even more senior executive overseeing all product development, including engineering).

BUSINESS AREA. We’ll further explore this concept later, but for now, the idea is that there are design teams, lead by Design Directors, dedicated to some discrete business goal (in a marketplace model, one Business Area would be the seller side, and the other would be buyer side; in enterprise software, one business area may be Applications, the other Platform). 

Design Director (and below). Each team has between 10-25 designers, lead by a Design Director, supported by some number of Design Managers (this example is generous, with a manager for every 4 designers; usually it’s closer to 7 or 8 designers). The Design Managers are responsible for an aspect of that Business area. So, if this were marketplace model, and Business Area A were the Buyer side, each manager is responsible for a stage in the Buyer journey, in this case it could be Research and Discover, Purchase, and Post-Purchase. 

Designer. These are Product Designers, with a range of experience: Lead, Senior, mid-level, and Associate/Junior. 

UX Research. A small team of (Lead to Junior) researchers who support the organization, reporting to a Director/Manager responsible for the practice. This group is distinct (as opposed to being woven into the Design Directors’ teams), so as to support their career development as UX Researchers, reporting to a manager who has explicit responsibility to coach and grow them professionally.

Design Operations. Similar to UX Research, a distinct group that supports the organization, reporting to a leader who is both developing the practice, and managing the professional growth of their team. 

DPM. Design Program Manager.

People Ops. The beginning a “shadow HR” function within Design, to account for the fact that standard HR practices for recruiting and hiring, onboarding, professional development, and performance reviews often don’t apply well to design teams.

Research Ops. UX Research practice requires significant effort in planning, coordination, communication, scheduling, paying, etc. If your UX Researchers are doing this work, it’s taking away from their practice. I place Research Ops under Design Ops as I’ve found it more typical that Research Ops people want to grow their careers within Ops, not in Research. 

Redrawing to show relationships as it scales

That typical hierarchical org chart does not depict the relationships between different parts of the team. Instead, I prefer a diagram that looks like this. (click/tap for full size)

The BUSINESS AREAs are ‘verticals’ within the design org, with UX Researchers and Design Program Managers dedicated to them, while reporting to their function lead. 

UX Research. With two researchers supporting a business area, one should be truly senior, and the other more junior. 

Design Program Management. As shown here, the DPM is oriented on the Design Director. The two of them essentially ‘run’ their part of the organization, which the Design Director focused on creative and managerial leadership, and the DPM addressing the operational needs.

This diagramming helps us see how such an organization may scale (click/tap to enlarge).

Drawing of the generic org scaling

Because of the genericness depicted, there is a lot that I’m not (yet) addressing, and which I plan to in subsequent posts. But one thing I’ll briefly touch on, as I hear Kristina Halvorson yelling it in my mind’s ear, is

What About Content?

And there is a simple answer to this. Either:

  • some of the Designers in the design teams are Content Designers
  • or Content Design functions analogously to UX Research and Design Ops, as a ‘horizontal’ team, reporting to a Head of Content Design, and with specific content designers

(I’d love to hear from folks on what organizational model they’ve found works best for Content Design.)

What’s Next?

This post is meant to be a foundational building block for further thinking on emerging standards in the shape of design organizations. Subsequent posts may include:

  • Digging into BUSINESS AREAs
  • The New (Shadow) Design Strategy Team (it lurks within this structure)
  • Experience Teams vs Platform Teams
  • Design Systems and Accessibility teams
  • How big this scales before needing a new model

   

The New Yorker just published an interview with tennis legend Billie Jean King, where she discusses establishing women’s tennis as a global money-making sport.

The whole interview is a mini-masterclass on leadership. From the recognition of the importance of relationships, to the specificity of her vision (equal pay), to the relentless politicking she did behind the scenes to get everyone on board, this interview contains more wisdom about leadership than most books. 

What spurred this post was this passage, which I’ve… slightly altered:

I feel like most of the designers do not understand the business side of things. Designers say, What should I do? What should I learn about? I go, Learn the other side of the story—learn the business side. Most designers just want more money. And I’m, like, Just understand their side, so when you sit down to speak, and have dialogue, you actually have some understanding and empathy for them. And, if you can show that, I think they’ll start to think about you in a different way as well. It’s just about relationships—everything.

(Okay. She didn’t say “designers.” She said, “athletes.” But, literally, that’s all I changed.)

This quote reveals just how universal this is. For anyone to succeed in business, they need to learn the business side. And when a non-businessperson invests some time and energy in doing that, the businessfolks will pay attention.  

…that Adaptive Path launched. The website (from archive.org):

Worth repeating the language on that homepage, as, 20 years later, it’s still an animating principle for me:

We believe that design is a strategic business issue, and that effective user-centered design improves profitability. We view success not only as launching an effective design, but also developing stronger organizations that can make wise decisions about design long after we’ve gone. That’s why we make sharing our knowledge and experience part of everything we do.

Through consulting, publishing, and speaking engagements, we develop high-quality user experiences, and educate people and organizations to do the same.

Adaptive Path accounts for both the highest highs and lowest lows of my professional career (I’m guessing this is true for any company founder). I’m deeply appreciative for the partnership of my co-founders who enabled me to be part of something I could have never done on my own. I’m grateful for the community that embraced us, and, more importantly, for the deep human connections I made with so many people in that community, who I consider close friends to this day (even if we haven’t talked for a while!).

A brief sidebar

As my announcement on peterme.com demonstrates (you’ll need to scroll down), we enjoyed the “countdown” aspect of the date. We were also taking a dig at marchFIRST , a reference doubtless lost on anyone today.