Holy shit! I co-wrote a book. You can read it right now!


Org Design for Design Orgs, the book I co-wrote with Kristin Skinner, is now available as an ebook. You can order it from Amazon or O’Reilly.

We’ve also launched a website which we hope will over time become a growing source of ideas and materials for people building in-house design teams.

Now that there is a dedicated website, I’m going to be placing my org design thinking over there (and believe me, I have a lot of it!).

I’m so excited, and eager to hear what people think of the book!

You probably don’t have enough designers

On Twitter, Sally Carson asked me the question, “…how to best ‘resource’ design & plan projects when you have designers embedded on cross-functional teams?”

I gave a 140-character answer, “The simple answer is: hire more designers. Or, only do so many projects where you can deliver quality. This means saying no to some.” As I frequently am asked some variation of this question, it warrants a deeper response.  

First, I’ll start with a glib statement: You probably don’t have enough designers. When I talk to folks who are feeling some sort of pain around their design team, more often than not the problem is that they are trying to do too many things with too few people. Design teams are typically understaffed, because it’s not understood just how many people it takes to deliver on quality, and it’s more prudent to under-hire (and save money!) than over-hire.

So, what happens when there aren’t really enough designers to go around? Relevant to this discussion are a capable of paragraphs from my forthcoming Org Design for Design Orgs book:

Designers often express a couple of traits that can get them into trouble. One is a desire to please. Designers want to make others (clients, colleagues, users) happy. And so, when asked to do a thing, the default is often, “Yes.” The other is a revulsion at seeing work go out without designer involvement. So, even when not asked to do a thing, if they see that something might be shipped that wasn’t intentionally designed, they’ll try to find a way to contribute, so that what is released isn’t terrible.

While these intentions are good, the results are self-defeating. Teams get spread too thin, delivering across too many programs, work overlong hours, and ultimately deliver subpar work. A design organization is only as good as what it delivers, and if it is producing crap because it’s trying to do too many things, than the rest of the organization will associate design with crap. Design leaders need to wield the power of “No.” Design work should only be done when adequately prioritized and staffed, and when there is time to develop quality solutions. This doesn’t have to mean excessively long schedules for endless rumination and exploration. Any good design leader knows that there is a point where a design team realizes diminishing returns. What it does mean is empowering the design organization to uphold what it takes to deliver quality, and decline work that doesn’t fit.

Companies are always trying to do more than they have people to deliver on. And many are terrible at prioritization. A key means for prioritization is contained in Sally’s initial question: the ability to appropriately staff a cross-functional team should be a forcing function for just what gets done. You shouldn’t have to ‘resource’ embedded designers — by nature of their embedded-ness, they are automatically resourced. If you have to ‘resource’ designers,’ that is a symptom of too few designers trying to do too many things. If a cross-functional team cannot be created without resourcing, and sustained for the long haul (i.e., not dissolved and reformed to do a totally different thing), then that’s a bright sign that you shouldn’t try to do that thing.

Now, it’s hard for design leaders, especially those trying to earn credibility, to say, “No” to their colleagues. But it’s imperative. Stick to your guns. Show just how good the work is when the team is appropriately staffed. When people see that, they will clamor to get more folks on the design team.

That leads to a whole other problem–recruiting and hiring. But it’s a good problem to have!

“Should Designers Code?” fetishizes tech over other crucial design skills

I’m writing a book on building effective in-house design teams. I recently completed a draft of the chapter on professional development for designers. The following is inspired by that.

Design is so much more than what most people think it is. Even than what most designers think it is. As someone who has worked in design for 20 years, perhaps the most frustrating industry conversation revolves around “should designers code?”The idea that a designer who codes is a “full-stack designer” demonstrates the shallowness of most thinking about design as a practice, and a skill set. It speaks to a technical fetish that undercuts the full potential of design.

There is opportunity for design to be woven through every aspect of a customer’s interaction with an organization. In order to do that, a variety of skills need to be brought to bear, many of which are typically neglected in discussions about what designers should learn to do:

  • User research. Conducting user research sessions (in-home, in-office, user testing, diary studies), and deriving meaningful insights through analysis.
  • Information architecture. Structuring content, developing taxonomies, crafting navigation, and other activities that make information accessible, usable, and understandable.  
  • Interaction design. The structural design of a software interface, supporting a user’s flow through a system, and ability to successfully interact.
  • Visual design. Color, composition, typography, visual hierarchy, and brand expression that present the product or service in a way that is not only clear and approachable, but appropriately exhibits personality.
  • Writing. Clear written communication that, like good design, guides the user through an experience. Much of the time, written content is the experience, and far more valuable than the design dress around it.
  • Service design. Systems-level understanding of all the piece parts (technical systems, front-line employees, touchpoints, etc.) that go into delivering a service, coordinated to support customer journeys.
  • Prototyping. Quickly simulating proposed designs in order to better judge their user experience. Could be deeply technical (writing code) or a more patchwork use of tools like AfterEffects, Keynote, and Quartz Composer.  
  • Front-end development. Delivery of production-ready front-end code. Valuable in ensuring that designs are implemented as proposed.  

It’s easy to argue that user research, information architecture, and writing are design skills every bit as important as coding. In fact, those practices better support strategic efforts, and so may have greater impact than the execution orientation of coding.

The range of skills demonstrates the foolishness of the idea of a “full-stack designer.” No one person can practice all these skills with any real mastery. In my experience, folks become expert at one, maybe two, strong in a couple others, and competent in a couple more (and this is after 10-15 years of work).

Given this variety, how a team member grows their skills is variable, depending on the designer’s desires, mindset, and inclination. There’s no set path for designer growth. Some will learn to code. Others will learn to research. Others will map systems (of information, of relationships between people). All are necessary, and no particular path should be encouraged over others. 

This range also points out the folly of having a single designer embedded on product teams. As no one designer can deliver across this set of skills, no one designer should be expected to act alone. Designers work best, and deliver best, in teams, where their skills are complementary, allowing the whole to be greater than the sum of the parts.

The variety of skills also changes who is typically thought of as part of “the design team.” Too often we get caught up in roles and titles, when what matters are the skills that are being brought to bear, regardless of who is doing them. Content strategists (who excel at writing, are strong in information architecture and user research, and can do competent interaction design and service design) or UX Researchers (who may excel at user research, be strong in writing and service design, and competent in interaction design and information architecture) could (should?) be considered part of the design team.

I guess what frustrates me most about “designers should code” is that it demonstrates how designers can get in their own way. Fetishizing code is fetishizing production, at the expense of strategy. It keeps designers in a subservient mode, receiving requirements from others, happy just to execute. There is a broader and deeper opportunity for designers and design practice to drive the definition of those requirements and weave through an entirety of a customer’s experience. Yes, code is part of that, but only one part.

Design can be so much more than “problem-solving”

I’m writing a book on building effective in-house design teams. I occasionally share passages from the book that stand on their own. What follows is something I’m have a beast of a time articulating. Feedback is welcome!

Design can be so much more than “problem-solving”

Business in the industrial and information ages of the 19th and 20th centuries was dominated by the analytical approaches typical in scientific management and engineering. These approaches are insufficient for tackling the complex challenges companies face now. This has lead to greater investment in design for the following reasons:

  • Squeezing greater efficiency has run its course, and design’s generative qualities are seen as means to realize new business value
  • By its very nature, software breeds complications that require design to rein in; with networked software, this complexity is exponentialized
  • The shift from products to services, with umpteen touchpoints by which someone chooses to interact, places greater reliance on design for coordination so as not to overwhelm the customer

While these challenges explain why corporations are willing to spend, focusing only on known problems limits the potential impact that design can have on a company. While design is often associated with “problem-solving,” the irony is that this view represents the same reductionist mindset that created the challenges that design is being brought in to address.

Problem-solving is only the tip of the iceberg for design. Beneath the surface, design is a powerful tool for problem-framing, ensuring that what is being addressed is worth tackling. Deeper still, and discover the core opportunity for design is to inject humanism into work. The best designed products and services don’t simply solve problems, they connect deeply with people. When design is combined with social sciences like anthropology and sociology, and other creative disciplines such as writing, there exists the possibility of creating a powerful expression of the human experience. As Steve Jobs said,

Design is the fundamental soul of a man-made creation that ends up expressing itself in successive outer layers of the product or service.

Hiring: reject a candidate for the right reasons, not just because they’re different

(I’m currently writing a chapter on recruiting and hiring designers. The following passage is about the debrief after The Day of Interviews, and how to proceed if the the interview panel is split. Essentially, make sure that it’s not just because the candidate is somehow different.) 

The challenge is when a candidate splits the panel, where some are strongly positive, and others are inclined not to hire. Navigating this proves to be among the most heightened and sensitive tasks for a design leader, because there is nothing more damning than a mis-hire, especially where there’s evidence that not everyone was on board.

In most situations where there’s a split, the easiest decision is the same as the right decision–do not hire. Given how costly it is to make a hiring mistake, this is where better-safe-than-sorry is an appropriate strategy. BUT. It is not a universal, and how this is handled is one of those areas that distinguishes design leaders from design managers. If a design leader deeply believes in the potential of a candidate, and can identify flaws in the rationale of those who object, the design leader should make the case for why an offer ought to be extended to the candidate.

There are reasons for rejection that design leaders need to be wary of, and call out if they are the only impediment to hiring.

Unfamiliar background or approach. Designers, particularly those with less experience, can be quite orthodox in how they evaluate other designers. They may be suspicious of any designer who doesn’t share their background or approach. An atypical background (maybe they didn’t study design in school), or unfamiliar approach (perhaps they don’t use typical design tools, or they’re unfamiliar with industry standard methods), can make panel members uneasy, because it’s not how they do it, and they don’t understand how other ways can be successful. The design leader’s role is to remind the panel of what is most important – results. If an unorthodox approach leads to great design work, the onus is on the team to figure out how they might be able to incorporate such different ways into their team. In fact, a willingness to consider people with atypical backgrounds provides two benefits: there will likely be less competition for that person (because other companies will also be hesitant with the unfamiliar); and the incorporation of new ways of working will increase the team’s diversity of perspective, and enable them to do better work.

Awkward communicators. If the interview process has one crucial drawback, it would be its reliance on conversations as the primary medium of understanding. The portfolio review mitigates this somewhat, but one of the things any candidate is being tested on when talking to people over the course of a day is how well they communicate. Many talented designers are not good oral communicators, and many are quite introverted. It might even be part of the reason they got into design–they may be more comfortable with pictures than words. People who are awkward communicators (and good designers) often process the world differently than others, and that difference can actually make for a stronger team by bringing in uncommon ways of working and thinking.

Candidate is a little weird. Maybe they talk fast or loud. Maybe they have some uncommon obsessions. Maybe they demonstrate unbridled enthusiasm or a lack of social graces. Whatever it is, you will interview candidates that are a little weird. Don’t let that weirdness be a turn-off. In fact, lean in to your team’s weirdness. If a design team can’t bring weirdness into a company, who can? If people on the interview panel grow wary when candidates’ let their freak flags fly, reorient their thinking to the quality of that candidate’s work, and whether they think the candidate will be truly disruptive (and not just a little strange).

Principles for Recruiting and Hiring Designers [FEEDBACK DESIRED]

[The following is a passage from my book-in-progress on in-house design teams. It’s a (very) rough draft on the principles that should undergird the recruiting and hiring process for designers. I think I believe everything here, and I think it’s pretty complete, but I’d appreciate feedback, commentary, calling of bullshit…]


The recruiting and hiring process warrants the same design attention and intention of any other experience. Do not succumb to your company’s standard operating procedure.

Recruiting designers is different from other recruiting other roles. Recruiters, even those who work with other craftspeople such as engineers, are often surprised to find that what works for other disciplines falls flat with designers. What follows are generalizations, so will not be true in all cases, but have borne out over our careers in hiring. Generally, what we have learned is that designers want to do great work, work with interesting people, and get paid fairly for it, pretty much in that order.

Make the approach humanistic. While no one wants to feel like a cog in a machine, designers are more sensitive than most to feeling subjected to bureaucracy, and some recruiting processes feel like filing taxes or hospital visits–filling out forms, submitting material into a faceless system, uncertainty as to when to expect a response, shuttling from handler to handler. Make sure to provide a human touch at every step in the process. Beware of adopting approaches that make it easier for you, but less personable. Given the competitive talent market, it’s worth feeling some friction and taking on extra work if it makes the experience more pleasant for the candidate.

Money is table stakes, but not a strong motivator. This one is a little tricky, because it can be interpreted that “designers don’t care about money.” While that might be true for a few, most designers want good compensation for their work, particularly where the cost of living is high. That said, throwing money at designers does not guarantee they’ll accept an offer. In fact, many will find it suspicious, wondering what such largesse is masking. (Many designers have an uneasy relationship with money.) Don’t try to exploit designers’ antipathy towards money–they’ll ask around, and if they feel like they’re being taken advantage of, the deal is off. Commit to making offers that are fair for the market, and then spend time and effort on the other factors that will guide their final decision.

Emphasize the work to be done. For most designers, the primary motivation is the nature of what they will work on. Such inclinations vary widely–some designers love hairy content problems, others want to build complex enterprise software, others crave sexy consumer experiences. Recruiting efforts should stress what makes the work compelling from a designer’s standpoint. When Peter was at Groupon, the stock was in a bad place and the company had become a media whipping boy. However, he was able to direct attention to the interesting design probem, which was to figure out how to leverage Groupon’s success with daily deals and create other ways to connect shoppers and local businesses. Designers were attracted by the opportunity to to deliver new features and functionality that created a marketplace, and the meaningful challenge of working with small local businesses at scale.

Explain the context in which that work is done. While some designers are dedicated to solving problems in specific industries, such as healthcare or education, many designers can root out what is interesting in any sufficiently complex problem. So when they’re choosing between job options, they seek to better understand the context in which they will work. Will they be expected to work on their own, or will they be part of a team? Are there opportunities to mentor or be mentored? What kind of authority and ownership will they have over their work? Is design respected within the organization? How does the company treat its employees? No one context works for all designers, so be clear about the characteristics of yours.

Be honest, even frank. Don’t just tell them what they want to hear. Engaging with candidates reveals their preferences and desires. For design leaders hungry for talent, it can be tempting to tell candidates what they want to hear, to get them through the door and at a desk. However, if it contradicts what they then experience, the working relationship starts off on the wrong foot. That person is now less likely to suggest others to join, may themselves be looking for exits, and the effort invested in bringing them proves for nought.

If a candidate makes clear they want to manage others, but there’s no opportunity for that in the foreseeable future, don’t tell them, “Oh sure, let’s discuss that in 6 months and see where we’re at.” Whatever the pain in losing a great prospect, say, “I don’t think we have a fit at this time,” and move on. Bring that person on, even if they have been told there are not management opportunities, and every discussion is clouded by that management desire.  

Be direct and honest about what it is like to work there. Don’t sugarcoat troubles. Don’t dwell on them, but acknowledge them and make clear the steps being taken to address them. The design community can prove surprisingly small and tight-knit, and word gets around. Bullshit is found out.

[There you go. Thanks for reading.]

“Head of Design”: Defining this role

I’m co-writing a book on building in-house design teams. I’m also currently in the job market, so I’ve been thinking about, and talking about, the role of “Head of Design,” which you’re starting to see pop up across Silicon Valley. Here’s what I wrote to define the role.

Head of Design

For design to realize its potential requires focused, empowered leadership. “Head of Design” has emerged as a title for this role, which works regardless of whether they are considered a manager, director, or VP.

Whatever the level, the head of design is the “CEO” of the design organization, ultimately accountable for the team’s results. That impact is the result of how they handle three types of leadership:

  • creative
  • managerial
  • operational

A Head of Design provides a creative vision not just for the design team but the whole organization. They establish processes and practices for realizing that vision, and set the bar for quality. They contribute to the development of brand definition and experience principles, and ensure that those are appropriately interpreted through the team’s work.

Their managerial leadership is realized through the tone they set for their team. What kind of work environment do they foster? How are team members treated, and what opportunities are they given to grow? How is feedback given? How do they hire, and who does that bring in? The sum of these decisions defines the Head of Design’s managerial style.

Operational leadership is a combination of very little things and very big things, all in the interest of optimizing the design organization’s effectiveness. The little things are what the rest of the team sees, in terms of how communications are handled, which tools are supported, how work is scheduled, how team meetings are run. The big things tend to happen behind the scenes, and involve interactions with a company’s core operations teams such as finance, HR, IT, and facilities. These include opening requisitions for headcount, adjusting salaries to ensure market competitiveness, establishing employee growth paths, acquiring the necessary hardware and software, and claiming physical spaces.

A common mistake made by company leaders when hiring a Head of Design is to favor creative leadership qualities over the managerial and operational. They bring in a creative visionary with big ideas and a beautiful portfolio, but often those folks don’t have the patience or mindset for the mechanics needed to actually make an organization run. Team members struggle without good management, flail without tight operations, and the team proves far less effective than they could be. Admittedly, it’s a challenge to find an individual skilled in all three forms of leadership. Remember, this role is the “CEO” of the design team, and as such, managerial and operational excellence are crucial.

As the team grows, the Head of Design will not be able to perform detailed duties across these three areas. This is when you bring on Design Managers and Directors (for people management), Creative Directors (for creative vision), and Directors of Design Program Management (to run operations). With these lieutenants in place, there is still plenty to do. At that point, a Head of Design focuses on:

Recruiting and hiring. Always. There may be nothing more important in the organization than identifying talent and getting them to join the team.

Living the culture. Addressed in depth in Chapter 7, the culture of a design team is essential to its long-term success. A Head of Design not only establishes the team’s cultural values, but demonstrates them every day through their actions.

Process and practices. Working with design managers and creative directors, establish a methodological toolkit, and make sure it is shared, understood, and used throughout the team.

Vision. Developing a “north star” for the company is not a one-time act, but an ongoing process of refinement and evolution.

Represent design for the organization. The Head is the primary voice of design inside and outside the company, sharing its work, evangelizing its success, articulating its vision. And sometimes this representation means fighting for design in the face of policies, procedures, and bureaucracy that limits the team’s potential.


Thoughts on fostering a collaborative work environment

[I just wrote the following passage for my book on building in-house design teams. It needs work, but I still felt it was worth sharing.]

Realizing the benefit of diverse perspectives requires a supportive environment where people are encouraged and comfortable sharing their work, spurring collaboration that makes the final output better than what anyone would deliver on their own.

Every member of the team must demonstrate respect to every other member, or the openness required for successful collaboration will not emerge. Dismissiveness, insults, cattiness, and behind-the-back gossip lead to people feeling shamed and shutting down, and cannot be tolerated.

Earning one another’s respect is necessary in order for the team to “get real”, because frank and candid critique and feedback are essential for upholding the high quality standards. Greatness comes from the tension and collision of different perspectives, addressed openly and honestly. Design teams that favor politeness over respectful candor will rarely produce great work.

Organizational hierarchy can stifle the free flow of ideas within a design organization – when senior people speak, it often stops the conversation. It’s now become cliche, but it’s worth repeating – great ideas can come from anywhere. Great design leaders encourage everyone to speak up, and, for themselves, wait to speak last. These leaders must also place their work alongside others, and accept others’ critique with grace and humility.

The collaborative environment referred to so far has been figurative, but it also should be made literal. Great design work takes space – places to collaborate, whiteboards for sketching and ideation, walls to show work. And those spaces should be permanent, places where the team works and sees their work all around them. Not only does this encourage continual engagement from the team itself, such spaces enable people outside the team to quickly connect with the work. It literally demonstrates openness and transparency. And instead of having occasional big share-outs (that require preparation that takes time away from productivity), these spaces support frequent lightweight check-ins that ensure the work is on track, because if it’s beginning to veer off-course, it is quickly corrected.

THE best conference for UX/Design managers and leaders…

…is Adaptive Path’s MX Conference, taking place on March 29-30 2016 in San Francisco.

I’m biased. After a few years away, I’m back and helping program and host this year’s event. We have a stellar line-up, including Bob Baxley (formerly Apple and Pinterest), Hyo Yeon (leading the design charge at McKinsey), Janaki Kumar (VP Design at SAP), Kim Scott (spreading the gospel of Radical Candor, a philosophy I can totally get behind), and many others. Oh, and me (I’ll be co-teaching, with Kristin Skinner, a workshop on “Org Design for Design Orgs”, based on what we’ve been writing in our book).

No other conference packs so much value into two days for folks who are managing/directing/leading design teams.

AND: Use the promotional code FOPM to get 15% off the registration price!

Design Team Leads

My friend Dane Petersen asked on Twitter: “Honest, unsnarky question: If design is thinking by doing and leadership means someone else does the doing, how does a design leader think?”

I’ve written a bunch about this in the book I’m writing. Here is what I wrote about the “team lead”, the person responsible for a 3-7 person design team tackling a problem.

Team Lead

Regardless of size, each design team benefits from a single point of authority and leadership, an individual with vision and high standards who can get the most out of their team. This is the most important role on the team, and the hardest job to do well.

Team leads must be able to:
Manage down. Leads are responsible for overall team performance. They need to create a space (whether physical or conceptual) where great design work can happen. They must coach, guide, mentor, and prod. They address collaboration challenges, personality conflicts, unclear mandates, and people’s emotions.

Manage across. Design leads coordinate with product leads, business leads, technology leads, and people in other functions in order to make sure their teams’ work is appropriately integrated with the larger whole. They must also be able to credibly push back on unreasonable requirements, and goad when others claim that the design team’s work is too difficult to be delivered.

Manage up. It’s crucial that these leads are comfortable talking to executives, whether it’s to explain the rationale behind design decisions or to make the case for spending money, whether on people or facilities. Design leads must present clear arguments, delivered without anger or frustration, that demonstrate how their work ties into the larger goals and objectives of the business.

In short, the best team leads are a combination of coach, diplomat, and salesman. And they are folks who, through, experience, find they can span the conceptual scale from 1,000 feet all the way down to 1 foot. They oversee the end-to-end experience, ensuring that user needs are understood, business objectives are clear, design solutions are appropriate, and the final quality is high. To achieve coherence, they must integrate efforts across product design, communication design, user experience research, and content strategy. They are responsible for articulating a design vision shared not just by their immediate team, but their cross-functional partners as well. No wonder it’s so hard to find such people!