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:


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?


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? 


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. 


(What follows is a muddle of thoughts spurred by dialog across blogs, mailing lists, and Twitter. I don’t quite have the time to shape it into something that makes tight sense, but I hope it’s useful anyway, as a part of that larger conversation.)

In the most recent episode of Finding Our Way, Jesse had this to say about the dream of UX:

If I think about the original dream of UX, the dream was that these practices would enable product strategy, product definition, product decisions to be made with experiential outcomes as the primary criteria for whether or not something shipped. And the idea implicit in that, being that value would naturally flow from optimizing for experiential outcomes, that has not really happened. The designers have been sort of sent back to their desks to make more screens… The promise hasn’t been realized.

And there are a lot of the UX old school folks like ourselves who feel like something has been lost along the way, okay, and are getting pretty discouraged about what it’s going to take to recapture that or to fulfill that promise. But my question is, Was that promise one worth investing in, in the first place? Like was the dream of UX, really just a dream?

Since we recorded this, I’ve seen a couple demonstrations of “UX old school folks” discontent: Mark Hurst’s “Why I’m Losing Faith in UX,” or Cornelius Rachieru’s recent tweet: 

Thing is, they might as well just be saying, “Make UX Great Again.” Those were not glory days, as a whole, for matters of user experience. It was exciting for us practicing it, being on the vanguard of a new discipline, granted authority and influence long before we knew how to wield it (I ran a design team when I was 28). Oh, and we were younger, more naïve, had more hair.

But in no objective sense were things better for UX. Most companies didn’t know it existed. Most who did, drastically underinvested in it. Those who were willing to invest in it were savvy enough to listen to thought leaders, but that was a paltry percentage of the real work to be done.

UX in 2021

What’s happened by 2021 is that UX is not interesting in and of itself anymore. UX is a given. As Joe Lamantia said in a mailing list I’m on, “it’s furniture.” And the challenges and frustrations people are expressing are largely due to this maturation.

We’re moving from “the dream of UX” to “the reality of UX.”

Personally, and perhaps idealistically, I’m still bullish on the promise and potential for the humanistic practices that UX represents. I work with companies, stupid boring old companies in industries like enterprise software, and banking, and insurance services, who see the potential for good design to advance their business in a human-centered way. I’m still hopeful that more people “doing UX” will continue to nudge human experience towards the center of business concerns.

I’m not naïve. I read, and largely agree with, Ruined by Design. I see design exploited to serve unsavory business practices. I witness product development organizations that view design as a production job, feeding assets to development like shoveling coal into a train engine. 

Things aren’t great. But then, they never were. 

But I see the massive investment companies are making in building in-house design teams, and more and more design leaders in the C-Suite, and I think things are getting better.

Yes, we’re going through a phase where design was largely seen as a contributor to production, as, to non-designers, that was the evident value of the practice. But I am also seeing more and more companies hiring “super senior IC” designers, as they recognize they’ve lost the positive influence that design can have on strategy, on holistic and coherent experiences.

What Design and UX need is engaged leadership

I guess what I’d say is, don’t confuse a moment in time for some new normal. Things continue to evolve. And instead of whingeing about how things were better in the old days, it’s on Design and UX leadership to do the hard work of figuring out how to advance our humanistic values. This means shifting our attention away from the ‘fun stuff’—tinkering with process, creating inspiring visions—and engaging with the difficult and messy stuff of people and organizations: communication, relationships, and education. It also means accepting what Noah Fang just tweeted in a discussion:

UX And Design also need new voices

As we move on from The Dream, I find that I’m way less interested in the solipsistic whining of successful middle-aged pale males, and instead disheartened by how we’re engaging the next generation of designers. A couple years ago, Jesse shared a tweet thread from a young designer at Instagram:

And more recently, a college student aired her self-flagellation of seeking purpose in UX Design:


i really thought designing buttons for apps was the answer to why i was alive…i cant

♬ original sound – sue ellen

And there’s clearly a disconnect about how we’re framing the work, and then how the work is actually being done. 

It’s also worth noting that, in those Bygone Days of UX Yore, industry leadership and public commentary almost wholly excluded voices of color. As we’re seeing in so many aspects of our modern life, we need to focus attention on our BIPOC peers, who are doing the work of charting a path toward a more truly inclusive future. Lisa Angela opened many eyes with Undoing the Toxic Dogmatism of Digital Design. David Dylan Thomas’s Design for Cognitive Bias shows us the traps we unknowingly step in. And Vivianne Castillo broke open my mind in her time on our podcast, and through her work with Humanity Centered, where she advocates for embracing truly human-centered practices (including self-care and trauma management) in our work.

As the UX profession matures, it’s time to wake up, and begin the real work of making those dreams a reality. But just because we’re moving away from the ‘dream,’ doesn’t mean we’re giving up hope. I’m quite hopeful of our collective ability to steadily move things in a healthier direction. 



Finding Our Way, the podcast Jesse and I conduct, is going on hiatus until about autumn. In our most recent episode, we reflect on the conversations we’ve had, and I thought I’d pull some key ideas from that, and dig into them here.

Perhaps the key tenet that emerged from the conversations in Finding Our Way is that “Leadership is relationship.” Even more important than having a vision is knowing how to relate to all kinds of people, getting them excited about possibilities, getting them to believe in their own capabilities, encouraging them to break down barriers between one another to achieve good things, and providing guidance for smart decision-making towards the desirable outcome.


Healthy relationships are built upon the craft of communication. Yes, it’s a craft, and one that you can develop and hone. The craft of communication encompasses

Spoken communication

Are you clear? Direct? Are you able to tailor your communication to the person(s) you’re talking to? Do you speak with confidence?

Written communication

Given the myriad places we now write, it’s crucial that you know how to shape what you write to suit the medium, the context (email vs chat vs document), the audience, and your message. 


Leaders often have to conduct ‘one-to-many’ communication, whether in a conference room with peers, reporting out to executives, or presenting at an all-hands. How presentations are shaped drive impact, so exploit narrative and storytelling techniques, build your argument, and provide a clear rationale.   


Leaders sometimes forget that communication is two-way, particularly when practiced with the intent to build relationship. Being an active listener goes a long way to establishing bonds. 


Perhaps inferred within the prior components, but I felt it worth calling out, even if only as a reminder to myself. How do you ‘show up’ when communicating? Do you appear engaged? Are you distracted? Do you hold people’s gaze, or look away? Do you show confidence, and ‘hold the room’? Be mindful of, and intentional with, your physicality when communicating.

Information architecture

It may seem peculiar to say that a UX/content practice like information architecture is part of the craft of leadership. The logic is:

if relationship is built on communication,

that communication is very much about information (particularly in the kind of distributed, often asynchronous, reality we have found ourselves in),

and in order for that communication/information to have impact,

it must be structured and presented in a way that makes it understandable and accessible.

Such intentionality about the shape of communication suggests an architectural frame. 

When we discussed it on the podcast, Jesse extended this need for IA thinking:

[L]eaders are, of necessity, orchestrators of systems, and systems instantiate knowledge as information architecture within them. So, the IA that gets embedded and coded, baked into your systems, becomes the way that the organization understands the world. And so, it is on the leader to imbue, infuse, enrich that IA with as complex and nuanced and understanding as they possibly can.

For leaders, who seek influence and impact beyond themselves, communication is the means of wielding that influence. As such, every communication must be conducted with intent and consideration. It’s exhausting, but it’s just part of the deal. 

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 TeamingThe Wisdom of TeamsThe Five Dysfunctions of a TeamTeam 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. 

When a design team is small, fewer than 10 people, design quality can be successfully managed informally—reviews, crits, swivel-the-monitor discussions. The Head of Design can reasonably keep tabs on all the work, and, through discussion, drive their team toward higher quality.

As design teams grow into design orgs, this oral culture approach frays. The Head of Design can’t see all the work. Quality is determined by design managers and team leads, who may have varying opinions as to what good looks like. The larger the team gets, the more chaotic this view of quality becomes. Additionally, a larger design org is part of an even larger product development org, which ends up exponentializing the voices commenting on design quality. 

With all this noise, the only way to handle design quality at scale is to establish clear frameworks, guidelines, patterns, and measures of success that can shift local discussions of design quality from personal preferences and toward organization-wide references. 

What surprises me is that pretty much every design organization I engage with, regardless of size, still maintains that folkloric approach to quality. This is dangerous, because, at the end of the day, all a design org has to show for itself is the quality of the work it produces. If there are no standards, if that quality is all over the map, that reflects poorly on the design function as a whole.

The trick is, how does one define design quality? Our colleagues in software engineering have it easier—there are industry-standard criteria (reliability, efficiency, security, maintainability) with clear metrics. These criteria all pretty much hew to “how well does the code function for the needs of the machine?” 

Design quality, though, is perceived in the messy context of people and business. When we say that a design is “good,” what do we mean? How do we distinguish that from “great”? How do we articulate a quality framework so that everyone on the team understands what is expected in terms of the sophistication of their work? (When I work with VPs of Design, I ask them, “How do we inform a 25-year-old junior designer in your most distant office what good looks like?”)

Over time, I’ve developed a an approach to establishing design quality within an organization. There are a slew of components:

Usability Heuristics

In 1997 I took Richard Anderson’s UC Extension class on “User-Centered Design and Usability Engineering.” (It is still the only formal training, outside of conference workshops, I’ve ever had in this field). Among the things he taught was “heuristic evaluation,” a method for assessing the usability of interfaces. 

24 years later—that tool is still useful. Jakob Nielsen developed an updated presentation of the heuristics late last year. This is as close to an ‘industry standard’ as we have for a quality assessment of interfaces akin to what software engineers have developed. They’re insufficient on their own, but they are a great place to start.

Brand Personality Characteristics

Usability heuristics are table stakes. Good design goes beyond that,  delivering experiences specific to the company and the context it  operates within. To avoid coming across as me-too, it’s important that design embody the personality of the company brand. This isn’t just for marketing design either—it is perhaps more important in product design, as that is where the promise of the brand is actually delivered.

Any reasonably mature company should have a robust brand identity. This is more than a logo, typeface, and set of colors. It’s also includes a set of personality characteristics specific to the brand, traits that are important to express to help strengthen that customer connection.

Take those characteristics, and turn them into a set of “personality heuristics,” and as you develop, or review, designs, ask yourself—are we presenting ourselves in a way consistent with the personality we seek to express? 

Experience Principles

Experience principles are a set of statements for how people will experience using your product. Whereas brand personality characteristics are very much inside-out (how the company wants to be perceived), good experience principles are outside-in, based in user research, and distilled insights from what qualities users seek in their experience. 

Back in Ye Olden Days of UX, experience principles were all the rage. At Adaptive Path, they were a key aspect of any strategy and design work we did. From what I can tell, like other aspects of classic UX design (RIP site maps), they’ve fallen out of favor. Which is too bad—this post by Julie Zhuo makes clear how helpful they can be.

Former Adaptive Pathers Chris Risdon and Patrick Quattlebaum shared their practice in crafting principles, and here’s a website cataloging dozens of published principles. (Favorites include: Tivo’s original design principles, Microsoft Windows 7 Design Principles, Opower’s Design Principles, Asana’s Design Principles.)

As with brand traits, turn these principles into a set of heuristics, and assess your designs for how well they deliver on those heuristics. 

Design Guidelines / Design Systems

Perhaps the best known way to maintain a certain level of acceptable quality at scale is to institute design guidelines, or, if you have the resources and the need, a fuller-fledged design system. These help ‘raise the floor,’ of your design, by making sure that, at least in the content and interface, there’s consistency across the entire user’s experience.  

While I support the development of design systems, I’m wary of how they’ve emerged as a panacea to solve all design problems. I take issue with this because I see design as a fundamentally human endeavor. For design to thrive, it must be rooted in a healthy and humanistic context.

Design systems are about automation and, frankly, are dehumanizing. This can be okay if there’s a strong design culture in place that can wield the systems with taste and judgment. But if there isn’t, then design systems simply support the mechanization of design, reducing design practice to asset creation to feed the engineering machine.

Inclusive design and accessibility practices

Regrettably, my commentary here will be thin, as this is an area I haven’t explored in much depth. But my neglect shouldn’t be your excuse! Because when we say “quality,” there’s an implication of “quality for whom?” When we discuss Measures of Success next, we situate design quality in a business context, and, well, if a significant portion of potential users cannot engage with your design because it is ignorant of inclusive principles or accessibility guidelines, that’s bad for business, which is bad design. 

Quality toolkits for inclusive design have been developed by the University of Cambridge and Microsoft

Measures of Success

Fundamentally, the only measure of design quality that matters is how it contributes to (or detracts from) whatever has been agreed upon as a measure of success. Unlike engineering, where there are industry-wide standards for success, success for design cannot be extricated from what success looks like for the broader organization. 

In my experience, the most salient measures of success for design are identical to those for product management. Key “product” metrics around acquisition, retention, satisfaction, engagement, task completion, etc., are what designers should primarily be delivering against, and are the most important markers of ‘quality.’  

That said, it’s surprising how often product development work starts where the product team doesn’t have a clear understanding of success. I encourage my designers, and now the design teams I consult with, to not engage on any work until there are clear, shared measures of success. Without an understanding of what success looks like, decision-making becomes arbitrary, and designers find themselves jerked around… which inevitably leads to lower-quality work, as stuff gets shipped half-baked, it’s hard to say “No” to less important projects, people are spread too thin, etc. etc.

For more on this, I appreciate this article: Empower Product Teams with Product Outcomes, not Business Outcomes. (And just remember, design ‘outcomes’ are the same as product ones.)

Explained Exemplars of Quality Work

The next step is to take the elements discussed so far—traits, principles, guidelines, and measures—and show how they are embodied and delivered in final product. Every team should have a gallery of exemplary work, with clear explanations as to why the work can be considered, well, “good.” You can think of it as case studies, or a design team’s collective portfolio, though in this case, process is less interesting than the final product.

As we’ve discussed, whereas engineering quality is standardized and largely context-free, design quality is very much rooted in the context in which it operates. Also, design decision-making is not solely the product of a rational process. As such, there will always be subjectivity in the creation and assessment of design. By sharing exemplars in this gallery fashion, you can meld the subjective with the objective, and teach the team the language by which matters of quality can be communicated.  

Oh, and if your team doesn’t have their own quality work to share (because they’re so new, or they just haven’t been able to deliver on the kind of work they feel proud of), then start your gallery with publicly available work.

Unfortunately, there aren’t many examples of “good design” galleries in the spirit of which I’m thinking. I’ve always dug Milton Glaser’s critique of Olympics logos, as it’s not just preferences, but rooted in robust design values.   

Mature and inclusive critique practices

Critique is not a ‘nice-to-have’ in the design process. AsErika Hall said on an episode of Finding Our Way :

“The practice of design is creation and criticism in dialogue with one another. And I think we’ve emphasized creation and completely lost the sense of criticism, even though that’s fundamental, that’s one half of that dialectic.”

Critique is how we get to quality. We place our work up or review, we get feedback from other minds, and the refinements based on that input make it better. 

A problem, often, with critique is that it can feel arbitrary and rooted in preferences. That’s why I’ve placed it last—critique should be rooted in all the elements shared before. 

Even with all these elements in place, it’s crucial to attend to the practice of critique to ensure that it operates in an inclusive fashion. Braden Kowitz has written on practices that lead to improved critiques

I reviewed a number of explanations of critique processes. Some that stood out:

Design Critiques at Figma . Super extensive, and quite apt in our everything-remote world.

How to Run a Design Critique . From our pal Scott Berkun. 

Defining quality is of existential importance for design organizations

Because design teams are judged by the quality of their output, it’s essential for these teams to thoughtfully establish just what quality means in their organization. Clarity around quality empowers design teams to:

  • push back on unreasonable requirements (or, if no requirements exist, insist on developing those before doing any work)
  • incorporate quality determinations into the broader product development process, to discourage shipping crap
  • protect team members’ time, focusing on prioritized efforts that are meaningful and likely have impact, and ignoring executive brain farts that everyone knows won’t go anywhere
  • staff projects and programs appropriately to drive to those quality outcomes
  • consistently deliver good work, which leads to ongoing benefits, not just with customers, but internally for morale, retention, and hiring

This post is already too long, and I feel like I’ve only scratched the surface. I’d love to hear about how you define quality for design, and what resources you’ve found valuable in that work.  

For many professionals, today is the end of the work year. It also the end of my first full year as an independent consultant, and I thought I’d reflect on experiences and realizations I had, if only to remind myself that time has, indeed, passed, and it’s not somehow still March.

This will be a grab-bag. Bear with the assortedness. Here’s a TOC:

  • As Design teams scale, they need to define themselves
  • Leadership roles need better definition
  • The Resurgence of the Super-Senior IC
  • Recruiting and hiring isn’t taken seriously enough
  • Finding Our Way podcast

As Design teams scale, they need to define themselves

5 times this past year, I helped Design teams draft their charter. Each of them had reached a scale that they could not be managed informally any more. Perhaps more importantly, though, they had each come to the realization that their work had been defined by others, by non-designers, and that they had been placed in a mode reactive to the needs of others. 

These teams sought greater control over their work, but weren’t sure how to establish that. They worked with me to develop a charter so that they had a firm grasp of their purpose, values, norms, output, and measures of success. By actively defining themselves, they’re better empowered in internal discussions about just what they work on. 

Leadership roles need better definition

Another type of engagement that became common was helping companies better define their design leadership roles. A few times that was the most senior role, and that lead to the thinking shared in The Makeup of a Design Executive. I also helped define the distinct leadership roles of the team. Core to all this was something that Janice Fraser clued me into decades ago as we were building Adaptive Path:

For every role, particularly leadership roles, you need to align:

  • Accountability (how the role’s success is measured)
  • Authority (what decisions this role gets to make)
  • Responsibility (the areas which this role oversees)

More often than not, pain that individuals in leadership face occurs when these areas are not aligned. Particularly, when people are held accountable for things over which they have no real authority. 

The Resurgence of the Super-Senior IC

Over on the Org Design for Design Orgs blog, I wrote about the Emerging role in design orgs: The Super Senior Individual Contributor (Principal Designer, Design Architect).” Some took me to task for the word “emerging,” saying it had been around for decades. And while that’s true, it had really only gotten traction in savvier tech companies, particularly those that already had dual-track career ladders for engineers. If you look at the comments on the post on LinkedIn, you’ll see just how pioneering this role still feels.

As design orgs scale, I suspect we’ll be seeing much more of this kind of role. 

Recruiting and hiring isn’t taken seriously enough

For all the talk of “people are our most important asset,” most companies do not take the activities of recruiting and hiring seriously enough. They toss off job descriptions, have no clear career ladders or levels framework, loosely structure hiring interviews, and leave candidates hanging, or provide only the most cursory follow-up.

This past year, I had the fortune to really dig in and develop a thoughtful and thorough recruiting process for a big enterprise (who were needing to hire rapidly), and I surprised myself as I realized just what it takes to create a process that’s fair and equitable, that appropriately assesses competencies and skills, and that’s manageable for an internal team.

To build such a thing is quite onerous, as when you pull on the recruiting thread, the whole org design unravels. You need to understand levels, professional development, have a clear taxonomy of (technical, strategy, professional) skills and an understanding of what progression looks like, and a view of how the work gets done (embedded in scrum?, dual-track agile?).

You then need to structure a recruiting process that sources and vets candidates efficiently, effectively, and fairly, that doesn’t waste people’s time, and leads not just to hiring, but successful fit that lasts. 

This is all real work, and it is exceeeeeeedinly rare to find companies willing to put in the effort.    

Finding Our Way podcast

Recording the Finding Our Way podcast with Jesse has been perhaps the professional highlight of my year. He and I hadn’t worked together since I left Adaptive Path, and I missed our conversations. We are grateful for the overwhelming and positive response we heard from the community—we seemed to tap into some themes and concerns that were on many minds. 

A few episodes stand out for how they reshaped my thinking:

10: We Have Trust Issues

You cannot successfully lead for any length of time without a basis of trust. But deconstructing trust demonstrates just how slippery a concept it is. I think we do a good job poking at it from a variety of perspectives, and what we unpacked here became an undercurrent in later discussions.

18: How Agile and Scrum ruined product management, and other things ft Melissa Perri)

Our second season featured conversations with design, product, and research leaders, all of whom I learned from. This discussion with Melissa Perri helped us realize just what degree design leaders have been gaslit about product management practice.

20 —The business model is the new grid, and other mindbombs (ft Erika Hall)

Jesse and I have known Erika for about 20 years, and she’s always been a useful provocateur. This discussion possibly ranged the farthest, while retaining remarkably high signal. 

23—Make UX truly human-centered by addressing trauma, power, and other necessary and uncomfortable realities (ft Vivianne Castillo)

While many discussions helped me better articulate what I already felt, this conversation with Vivianne actually changed my perceptions, specifically around the practice of user research, and the responsibility we have to those who conduct the research and the participants. I’m still grateful for how Vivianne opened my eyes. 


Here’s to a new year!

While 2020 was an undeniable crapshow, I’m grateful that it proved to be fruitful for my work. I look forward to thought-provoking opportunities in the new year, and appreciate all of you who take the time to read what I write, and share your thoughts with me.

To 2021!

I’m reading The Manager’s Path, an excellent book on managing technical teams, that’s wholly relevant for people managing design. Towards the end, Camille Fournier addresses “The Big Leagues,” and what it should mean to be a Chief Technology Officer:

First and foremost, a CTO must care about and understand the business, and be able to shape business strategy through the lens of technology. He is an executive first, and a technologist second. 

It’s a light edit to make this work for Chief Design Officer:

First and foremost, a CDO must care about and understand the business, and be able to shape business strategy through the lens of design and user experience. She is an executive first, and a designer second.

Thing is, when I talk to CEOs, GMs, and others who are looking to hire a design executive, a common criticism I hear is that the people they talk to are designers first, second, and third. 

Which, to me, is understandable. Design Leaders have had to expend so much effort fighting for their teams, their practices, their perspectives, that such a pose has become their default as organizational leaders. 

However, it’s holding them, and their teams, back. True design executives need to see their executive peers as their “first team,”  and their design organization as their second team. To be a design executive is to be an organizational leader. If you consider yourself simply the senior most design person, then you (and your team) will be constrained in its ability to make a broader organizational impact.

And I get it, this is hard. For so many design leaders, Design is core to their identity. But it’s time to recognize that for design to truly earn that ‘seat at the table,’ design executives must, perhaps counterintuitively, make design their secondary concern. 

A common oversight companies make when hiring a Design Executive is that they do so in a vacuum, and thus overload the role with responsibilities. They seek a Creative Leader with Executive Presence who can Scale an Organization, Build a Compelling Culture, drive Design-Lead Product Strategy, ensure High Quality, and Deliver Business Results. 

And it’s not that you can’t find an Executive who can do this. But they can’t do this all at once, and they will have distinct areas of strength and weakness. But companies hold out for a Design Jesus, talking to countless candidates, and only after 6 months, 9 months, even a year, come to grips with reality and figure out what they actually need in that role.

Companies should instead think about how to establish a Design Leadership Team, a small group of senior design leaders who collaborate to ensure the effective practice and delivery of design. Every time I develop a profile for a Design Executive, I do so in the context of building a Design Leadership team, making clear that each member of that team has distinct emphases that, when combined, should lead to a whole greater than the sum of the parts. 

In The Makeup of a Design Executive, I listed the four components of that leadership makeup: Executive, Creative, People, Operational. This can help us navigate the makeup of the leadership team, as we place different emphases on the different roles.

Design Leadership Team

SVP of Design, Chief Design Officer

Executive and Creative Leadership

  • Holds own with executives
  • Strategic partner with end-to-end vision 
  • Inspirational and enabling leadership—models the culture
  • Recruiting and retention strategies
  • Advocate/champion for design
  • Establish quality standards

Head of DesignOps

Operational Leadership

  • TeamOps (effective delivery of Design, program management)
  • PeopleOps (recruiting coordination, onboarding, review programs)
  • Resources, facilities, and services for Design
  • Design Education programs
  • Vendor management

Design Directors

Creative and People Leadership

The folks typically oversee a significant swath of the design org (~20 people), and could be organized by product, customer type, or stage in a customer journey. They oversee the design teams doing the work, collaborating cross-functionally, and delivering the user experience. 

  • Uphold quality standards through the work
  • Connects design effort with product and business strategy
  • Recruiting and hiring for their teams
  • People and performance management (for designers)
  • Process and practice, both internally and cross-functionally 

Heads of Functions (e.g., UX Research, Content Design)

Creative and People Leadership

Obviously, Design is typically the most prevalent practice within a team, and doesn’t warrant specialized leadership. Other practices, such as UX Research and Content Design, typically are not staffed at the same rate, and the roles are deployed differently. It’s important to have heads of these functions to ensure:

  • Establishing best process and practices, internally and cross-functionally
  • Developing quality bars for these practices
  • Recruiting and hiring within the practice
  • Appropriate staffing across project work
  • People and performance management (for their function)

Principal Designer, Design Architect
(Super-Senior Individual Contributor)

Creative Leadership

I recently wrote about this role at length, so won’t duplicate that here. What I will say is that as design organizations scale, the SVP of Design and the Design Directors, who are expected to contribute Creative leadership, find that the other responsibilities of their role (Executive Leadership, People Leadership) take time away from creative engagement. And while they may be able to provide Creative leadership in bursts, they cannot sustain it. If that is the case, it is time to bring on Super-Senior Individual Contributors who can focus solely on Creative leadership.

With the idea of a complementary Leadership Team in place, it becomes easier to think about how to hire for each role, as you no longer are considering them without context.

And you may find yourself rejiggering the Leadership types represented here. Say you recognize the need to bring on an SVP of Design to scale the organization and drive design advocacy throughout the company, and you already very strong Creative leadership at the Director level. In that case, an SVP with emphasis on Executive and Operational leadership may be more suited to this context. 

This past year, I’ve helped a few companies looking for design executives (“Head of Product Design,” “Chief Design Officer,” someone reporting into the C-suite, and may be in the C-suite) by developing a profile of the role that they can hire against.

Often, these companies begin with a fairly rudimentary understanding of the role, focused on some form of “being a creative leader.” Through my efforts, I’ve developed a four-part framework (different than the other four-part framework I shared earlier) to break down the responsibilities of what it means to be a design executive.


An organization-wide leader (not a “design leader”). Their ‘first team’ is with other executives, and the responsibility here is to bring a design-and-user-experience-informed perspective to company challenges—planning and strategy, business success, etc.  

There are also expectations for representing and advocating for Design throughout the company, its potential, and what it needs in order to be most effective.


As the head of a creative function, there are expectations around how this person inspires, and holds the Design team accountable to, the delivery of high-quality work.

In terms of practice, their work is oriented on systems and strategy, with the primary output of cohering the work of their team in some kind of end-to-end experience. This is particularly important if they’re overseeing Brand/Marketing and Product Design. 


As someone leading a sizable organization, they are responsible for building a healthy, performant, and long-lasting team. 

This includes overseeing recruiting and hiring processes, career and professional development, establishing a compelling team culture, and designer-friendly day-to-day people management practices. 


This role requires facility with the operational realities of an organization at scale, including people, process, programs, communication, coordination, annual planning, budgets, onboarding, managing partners, and more.

They may be able to delegate this work to a Head of DesignOps, but they need to know what it means for these efforts to be humming. 

With these four aspects identified, the next challenge is figuring out how much effort the Design Executive is expected to put against each area. It won’t be an even 25-25-25-25 split. It will vary from company-to-company, depending on the context in which this role resides. Generally, I think the following percentages are a good place to start:

Executive: 33%, Creative: 32%, People: 20%, Operational: 15%. 

The idea being that the bulk of the Design Executive’s effort is on the content of the work (Executive + Creative being nearly 2/3rds), while recognizing that there are very necessary People and Operational efforts necessary to maintain organizational health. 

Also, what often happens as an organization grows, is that the People and Operational aspects end up taking the majority, if not all available time, because they are the elements that must be addressed in order for anything to work.

When that happens, a framework like this can be a helpful diagnostic for that design executive to go to their boss with, and say, “I need to hire a Head of Design Operations” or “I need Design Directors,” so that they can return focus to the Executive and Creative work that is expected of them. 

In my next post, I’ll address the makeup of the Design Leadership Team, that includes that Head of Design Operations and Design Directors. 

A challenge for design leaders and managers, especially new ones, is to understand all that is expected of them. Typically coming from creative backgrounds and roles, they don’t know what they don’t know now that they are accountable for the work of others. 

To help design leaders navigate this, I developed a framework for thinking about the different aspects of leadership, rooted in four archetypes. Originally only shared as presentation, I’m finally writing it up here.

Also, I’m publishing a Leadership Skills and Practices Assessment that design leaders and managers can use to assess themselves and the leaders on their team. I’ll talk more about the assessment at the end of this post.

The Framework


This is where you manage down ⬇️, getting the most out of your team. Most design leaders understand this role, because they had someone serve as a coach to them as they were coming up.


You also have to manage across ↔️, particularly with peers leading other functions (product management, engineering, marketing, etc.), to coordinate activities and processes that enable successful cross-functional work. It’s labeled Diplomat as leaders build relationships with non-designers, so that means appreciating others’ motivations and desires, and communicating with them so they understand what your team needs, without dwelling in designer jargon.

Some design leaders have developed this as senior practitioners, but this typically requires a new set of skills and practices.


Leaders also must manage up ⬆️, handling executives and other stakeholders who can empower the design team or, conversely, inhibit it. Key to this is developing the ability to ‘speak the language of business’ (a phrase which is now so common it feels cliché), to connect the efforts of the design team to broader business strategy. This develops credibility among senior leaders, providing opportunities for the Design team to ‘move upstream,’ and contribute earlier in the process.

Also key to being a Champion is to serve as the ? ☂️ , shielding the team from executive foolishness, whether swoop-n-poops (fly-by critique done with little context and no follow-up), requests for work done on short notice, shutting down efforts with potential, etc.

This is probably the archetype design leaders are least aware of, because when they were coming up, they had no idea that their bosses had to deal with this. And often, their bosses didn’t know they should be doing this work, and their teams suffered.

It’s worth recognizing that this is the most difficult archetype, because by nature it involves dealing with those with greater power and authority in the organization, often requires expending social capital, and it can feel like you’re putting your job in jeopardy. But doing this well is crucial for your team’s success. Too often I’ve seen teams feel like they’ve been thrown under the bus by a leader who did not Champion them, and that leads to a morale spiral and attrition.


Once a design team hits a certain size (around 12-15 team members), the design leader then needs to embrace the archetype of the Architect, putting in place systems, practices, and processes that enable effective functioning at scale. Without this type of effort, design orgs suffer as they grow, because coordination overhead is too costly, quality is not maintained, people are perpetually over- or under-utilized, recruiting and hiring is poorly executed, and more.

To support this archetype is why we wrote Org Design for Design Orgs, as many design leaders didn’t realize just how much of their job is organizational and operational once the team grows beyond a certain point.

As design orgs grow, much of this architectural effort becomes the responsibility of a DesignOps team. The design leaders are still responsible for understanding and directing these efforts towards delivering great design work, but aren’t expected to be developing and implementing these systems themselves.

Leadership Skills Assessment

To get a sense of how well you and the other leaders and managers on your team are doing in performing as leaders, I’m publishing my Leadership Skills and Practices Assessment tool. It uses the framework above, with a couple adjustments:

  1. There is no “Architect” assessment. Architect is about scaling the skills and practices reflected in the other areas.
  2. I’ve added “Self Management.” This is about how leaders show up as professionals — managing their team, their energy, their attitude.

This Assessment tool is something I’m eager to evolve, so any and all feedback welcome.

At a presentation I gave last year at the Design Leadership Summit, I began my talk with a bit of theater (you can see it at the outset of this video)—I stated a set of “Design Leadership Truisms,” inspired by Jenny Holzer’s work. I realized I haven’t published them, so, here they are:
































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.