Design orgs get fucked over by relative team size

Typically, design orgs are significantly smaller than the engineering orgs they support. Designer:developer ratios are usually between 1:4 and 1:10. In the diagram here, we’re looking at 1:6.


In the book, we discuss the benefit of this ratio—design is a highly leveraged function, where a relatively small number of designers can have an outsized impact.

There’s a dark side to this though, in terms of perceived authority and influence.

In this example, the figure in black is the design Team Lead, overseeing the work of 5 others.

On the engineering side, that gray-ish figure oversees 30 engineers working with those designers.

Companies typically assign levels and seniority based on the number of people in someone’s organization. And this is where design orgs get fucked. With 5 people in their org, the Team Lead would be considered a Manager, but the Engineering Lead, overseeing the work of 30, would be considered a Director, maybe even a Sr. Director.

And so, while the Team Lead and Director of Engineering are peers when it comes to matters of scope, most companies would invest greater authority with the role overseeing more people.

As long as this persists, design will remain the kid sibling of other larger functions, and have trouble being seen as a true peer.

To address this, we need companies to rethink how they assign seniority, moving away from “how many people report up through you?” and towards “what is your scope of influence on the service we deliver?”

You probably don’t have enough designers

I’m reposting items originally written for This post is from April 19, 2016.

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 reposting items originally written for This post is from April 13, 2016.

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 reposting items written originally for This is from March 3, 2016.

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 reposting items originally written for This post is from February 18, 2016.

(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).