Peter and I are speaking and teaching about Org Design in the coming months. Check out our calendar of events and, if you’re in attendance, please say hello and let us know what you think of the book.
This showed up today, and looking at the book’s page on O’Reilly, you can order the paperback!
(Amazon is still showing pre-orders for the paperback.)
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?”
I’m reposting items originally written for peterme.com. 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!
I’m reposting items originally written for peterme.com. 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.
I’m reposting items written originally for peterme.com. 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.
I’m reposting items originally written for peterme.com. 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).
I’m reposting items originally written for peterme.com. This is from February 10, 2016.
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:
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.
I’m re-posting items originally written for peterme.com. This post is from January 26, 2016.
[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.