Category: org design

A few years ago, we interviewed Jen Cardello for Finding Our Way, and she shared that her team (UX Research) is peered with “market research, behavioral economics, brand, and advertising research, and customer loyalty” in an independent Insights team. The idea was for research to avoid a functional bias, so that it couldn’t be “weaponized” by marketing or design.  

Diagram showing UX Research, Market Research, Analytics and Data, Customer Care/Support as part of a Holistic Insights organization

And while UX Research is still typically found within a UX/Design organization, I’m witnessing a nascent trend of it being located elsewhere. For example, Nalini Kotamraju, SVP of Research and Insights at Salesforce, shared in a discussion on making research leadership more effective, that her team has “moved out of UX,” to be part of a broader product function. 

At the heart of this is a recognition that siloed research leads to a fractured understanding of the people the business is serving and territoriality around the idea of ‘who owns the customer,’ and that to be its most effective, research needs to engage in the entire end-to-end service experience, and that journey spans many organizational functions. 

And in my work, I’ve started recommending to my clients that they consider the creation of these holistic insights teams, using the simple diagram at the right to show how what are typically seen as distinct practices are actually puzzle pieces fitting together as a whole.  

Proceed with some caution

While an independent, holistic, and robust Insights org is the best mechanism for rich customer and user understanding, there are preconditions required in order for it to succeed.

A move towards an integrated Insights organization will likely be a journey, and must be taken with care. What’s crucial is that for the ‘containing’ function for UX Research to be a strong advocate and capable steward. If UX Research is moved out of UX/Design and into Marketing (to be partnered with Market Research), that could prove detrimental if Marketing leadership favors quantitative insights, or doesn’t understand the value of generative methods. In such a case, it would be better for UX Research to remain in UX/Design, where, even if its purview is limited, it can engage in a fuller practice.

Perhaps the greatest risk for a separate Insights group is to be seen as a disconnected internal consultant, dismissable by folks in Marketing or Product who feel that Insights isn’t aware of the real challenges on the ground, or simply ostracized because of some internal “us vs them” mentality. (I’ve talked about this as a challenge for strategic design.)

So, in order for this to work, your company must be a true ‘learning organization.’ In our discussion, Jen shared that Fidelity “is so obsessed with learning. We actually have learning days. Every Tuesday is a learning day.” Instead of worrying about being ignored or neglected, Insights has the opposite (and good) problem of being in too much demand. 

Another factor for any organization design is professional development. The ‘containing’ organization needs to be one that those practitioners aspire to lead. When UX Research is embedded within UX/Design, that implies that the career path for those UX Researchers is to become UX/Design Leaders. Is that true? Or are they better suited to becoming “Insights” or “Strategy” leaders? (The same holds for other functions like Accessibility. While many Accessibility teams start within UX/Design, those Accessibility practitioners typically don’t see their career heading toward UX/Design leadership, which suggests they belong somewhere else in the organization).  

How is your Research org organized? 

9 years ago, we started the process of writing Org Design for Design Orgs because there was burgeoning demand for making sense of the UX/Design function within companies. It now feels as if (UX/Market/Etc.) Research is in a similar moment. Who’s writing Org Design for Research Orgs? 

Thesis

Design maturity models are oversimplified frameworks that mask the necessary nuance to understand and develop an organization’s ability to get the most out of a Design function. That said, used responsibly, they can be a helpful heuristic, particularly early on, for orienting yourself in an organization. 

The futility of maturity models

Hang Xu has identified design maturity as a frame for better understanding the challenges the UX/Design community has been expressing. As a recruiter, he’s attuned to the impact of an organization’s maturity on a practitioner’s ability to succeed. He’s been writing a bunch on LinkedIn on this subject, including this recent post on probing and assessing an organization’s maturity. In direct communications with me, he’s asked for my take on the subject, and, as I see the concept of maturity come up more and more often in my work with design leaders, I figured I’d publish my thoughts. 

When we were writing Org Design for Design Orgs, I researched UX/Design Maturity models, as I thought they’d be helpful for grounding our discussion. What I found then (and still, largely, see now) is that these maturity models are too simplistic, reducing a bunch of factors into a single-number linear framework. Through my experience, I knew that a single organization may be at multiple places along the maturity line, which suggested that it wasn’t a useful tool for diagnosis.

My frustration proved fruitful, as it lead to writing chapter 3: The 12 Qualities of Effective Design Organizations, which is probably the single best chapter in the book. Instead of a single overarching maturity model, I believe it better to rate a set of qualities independent of one another, coming up with a kind of ‘report card’ for the organization. This specificity and nuance allows people to zero in on specific issues worth addressing. 

Erika Hall shared with me (in a direct message) her frustration with UX/Design maturity models as being “nonsense because they’re overly simplistic, linear, and…absolutely ignores the business model.” She then expanded on this on LinkedIn:  

Step 0 of “design maturity” is aligning the fundamental business model with the wellbeing of *all* users of and stakeholders affected by the systems being designed. This includes workers, communities, and ecosystems.
Otherwise, it’s just increasing levels of acontextual organizational proficiency in candy-coating extraction and exploitation. And then, what’s the point?

The utility of maturity models

So, if maturity models are so dumb, why do they persist, and why can’t even I shut up about them? In my work with design leaders, I’ve found that there is some value in the abstract concept of maturity as a guide for how to engage with their organization. This came up in the most recent episode if Finding Our Way, where Jesse and I circled the subject, and I reflected on Jehad’s comment that some design leaders shouldn’t go to the lengths of trying to ‘demonstrate impact,’ because the company might not be ready for that, but to instead to tune your message to the company’s maturity, which may involve a different means of ‘showing your worth.’ I then dug into this thinking on the intersection of UX Metrics and Maturity.

Jesse, in his work with his coaching clients, has developed a framing of ‘three trajectories’: organizational maturity, design maturity, and leadership, and how navigating the intersection of these trajectories is crucial for any leader wanting to operate at their fullest potential. (It’s worth reading his post, so go there and do that now.)

(Welcome back.) 

As long as you don’t take a maturity model to be prescriptive, but instead a tool for initial orientation, they can be a useful heuristic. If you have to use one the Nielsen Norman Group one is probably best, and appears to have become the standard. Interestingly, if you strip away oversimplified linearity, and look at the constituent factors (Strategy, Culture, Process, Outcomes), it’s even more useful, as it affords some nuance, akin to the 12 Qualities.  

Since I’ve become independent, perhaps the most common request of my time is helping companies develop good career frameworks for their UX teams. There are many reasons why they want them:

  • Provide clear professional growth paths
  • Smarter recruiting and hiring practices
  • Less biased performance management
  • Better alignment with other functions (e.g., product management, engineering)

In creating these frameworks, I resist linear “career ladders,” in favor of “trellis,” as my experience with people in UX is that they seek a bushier, less-directed growth, and these frameworks need to be flexible to handle the range of practices (design, research, and content) within UX. 

I have created a masterclass out of my approach to building these, and will be teaching it at the Design Ops Summit on October 5-6, 2023. You can register for the whole conference or just my class. Either way, use code MERHOLZ-DOS2023 to receive a discount. 

The Building Blocks of a Flexible Career Architecture

To create a robust architecture requires a set of components that interact with and build on one another. 

Capabilities

The skills, behaviors, mindsets, etc needed to do the work:

– Craft skills

– Strategic mindset and tools

– Professional abilities

Practices

Within any function is a set of Practices.

For UX, that’s typically UX Design, UX Research, and Content Design. 

Levels

An org-wide Leveling Framework structures a set of expectations for experience, autonomy, and scope at each career level, and across Manager and IC tracks. 

Roles

Specific roles are found at the intersection of Levels and Practices, with suitability and readiness made clear by competency in skills.

In the masterclass, we dig into each component.

Capabilities

We start with Capabilities as they are the ‘atom’ in a career framework. What are the skills, mindset, and abilities at the heart of the work? Through our activities, we’ll land on a Capabilities Taxonomy, which may look something like:

Craft

MAIN

Interaction Design
Visual/UI Design
UX Writing
Information Architecture
Planning Research
Conducting Research
Analysis & Insights

EXTENDED

Accessibility Guidelines
Inclusive Design
Service Design
Prototyping

Strategy

Experience Strategy
Technical Literacy
Business Savvy

Professional

Communication and Presentation
Collaboration and Facilitation
Structuring and Planning Work
Domain Knowledge
Navigating the Organization

Practices

The practices in an organization are an amalgam of craft capabilities. In the class, we’ll help you identify your distinct practices. In the UX organizations I’ve been supporting, it usually shakes out to something like: 

Practice Product Design UX Research Content Design
Core skills Interaction Design
Visual / UI Design		 Framing Research
Conducting Research
Insights and Analysis		 UX Writing
Information Architecture
Description Conceptualize, structure, and detail our offerings within the context of a broader user journey. Conduct research to identify the wants, needs and abilities of customers and end-users, translate those insights into recommendations from strategy to detailed design. Shape experiences using content and language to build user confidence. Plan, create, and structure product content.
Core activities Understand needs and behaviors; develop insights; diagram flows; design wireframes and prototypes; test solutions Develop hypotheses; identify methodology; plan research; conduct research; analyze data; synthesize findings; present insights; provide recommendations Explore voice and tone; Plan content governance; define standards for content types; develop end-to-end content strategy; draft content for end-to-end product experience; review content

Levels

Many career architectures start with Levels, but it’s only after Capabilities have been determined can you build a Levels framework, because how someone advances in their career is contingent on the development of their capabilities.

Years ago, I published the levels I created for the Snagajob Design team, and it has since become a starting point for many UX orgs. My thinking has evolved since then, and I prefer to start with a simpler overview of Levels, to then save the complexity for when folks are ready to dig into the details:

Detailed table of a levels framework.

In the masterclass, we dig into these specifics, as well as how levels differ for people on a Management or Individual Contributor track. 

Roles

Where we end up is a set of distinct roles that make up the UX organization. I find it helpful to visualize the org with each role shown:

This visualization makes clear the main paths through the organization. 

But wait, there’s more

What I’ve shared covers the core of the masterclass, but there’s a bunch more we address, including detailed rubrics for each Capability, the variety of ways people can grow in a Practice, how team members can use the tool to chart their career growth, how to roll out a new career architecture, and the difference between Professional Development, Performance Management, and Promotion.

If you’re reading this before October 5, 2023, you can sign up for my masterclass at the Design Ops Summit. If you’re reading this afterward and are interested in this material, don’t hesitate to reach out to me. 

Though the book I co-wrote is titled Org Design for Design Orgs, and, sure, it addresses broader design concerns (communication design, service design, hardware and industrial design, environmental design), it’s focused on a kind of design org, specifically digital product/UX design orgs reflecting the bulk of the experience Kristin and I have. 

As such, I’ve been surprised, and humbled, when I meet Brand Design leaders who have read the book and found it helpful in thinking about how they shape their teams. What I’ve found is that, as these teams grow, their leaders not only struggle with many of the same challenges product/UX design leaders face, their distinct organizational context leads to a whole bunch of different problems.

Yesterday, I had the honor of facilitating a public conversation titled “Org Design for Brand Design Orgs,” featuring Li-Anne Dias (Director of Brand Design at Handshake), Erin Pinkley (VP, Creative at Zendesk), and Jessica Rosenberg (Director of Brand Design at Webflow). The idea for the event came about when Li-Anne reached out to me with a lot of thoughts on applying the lessons from the book to her work, and so I connected her with Erin and Jess, both of whom I’d had the fortune of supporting in the past. Li-Anne prepared a presentation to kick things off, and I facilitated the conversation between the three of them, as well as bringing in questions from the audience. This all took place over Zoom, so we recorded it, and I have shared it on my just-launched YouTube channel:

Over these 75 minutes, we cover a lot of ground, but what we also realized is that this is a conversation that is just beginning. Each of us would love to continue the discussion, so if you’ve got ideas on where to do so, let us know!

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

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

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

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

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

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

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

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

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

 

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

   

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!