Thoughts and essays from the guy who coined the word "blog."
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!
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!
[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.]
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.
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.
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.
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!
When I work as a direct manager, my primary concern for anyone reporting to me is their professional and career development. I’ve learned that there are many ways for people to grow, and I want to be sensitive to the particulars of each individual on my team.
To get at that, there is what I call the Personal Professional Mission. I ask each team member just what is it that motivates them; why, in a universe of opportunities, have they made the choices that land them in the role they have. It’s a big idea that most folks have never been asked about, and haven’t considered deeply, and require some time to develop an answer. However, I find it to be the key to understanding how the person will want to grow, and the guidance and mentorship I can provide them on that path.
To help them understand what I mean, I share my personal professional mission: to make the world safe for great user experiences. This has pretty much been my animating principle since I first started blogging in 1998, and was perhaps most fully realized in the creation and development of Adaptive Path. It also spurred my departure from Adaptive Path, when I felt that I could best tackle this mission from inside the enterprise, as user experience no longer needed a laboratory for development, but instead required operationalizing in-house in order to deliver on the promise.
I was sharing the idea of the Personal Professional Mission to a design director looking for guidance in her career. And as I was explaining it to her, I had an uncomfortable realization: I don’t know if my mission still holds true for me, and I haven’t figured out what would replace it. This isn’t something I had thought about recently, and it caught me by surprise. But it also helps explain why I’m a bit adrift right now. I’m in the process of figuring out my next professional move, and the universe of options is a bit overwhelming (I know, it’s a good problem to have). I’m thankful I’ve uncovered what is at the root of this uncertainty, as it should help me address it. We’ll see where it takes me!
Historically, most formal design has been practiced by design agencies, which were environments set up to deliver optimal design output.
As design increasingly moves in-house, into environments that are not only not optimized for good design practice, but can prove quite hostile to it, a measure of a design team, and its leadership, is how they navigate this.
Many design teams find themselves at one of two poles.
I’ve now seen a number of teams, whose leadership comes from the design agency world, try to protect design by insulating the team from the rest of the organization. Essentially, these teams try to re-create the studio model when moving in-house, but in doing so inhibit connection with the rest of the company. This may lead to great design work in the abstract, but it also ultimately leads to ineffectiveness, as without those connections, the work of the design team is not realized through the product.
The other pole is one of total integration. Product design molds itself to whatever product development process exists, usually some flavor of agile. While this integration allows design to have some effect, the quality is subpar, because design is a different kind of activity than engineering, and what works for technical development is not ideal for great design. So, by trying to be accommodating team players, design loses what makes it interesting in the first place.
The challenge for in-house teams is to figure out how to keep that creative spark that makes design such a valuable contributor, without isolating it so much that it’s simply out of sync with the rest of the organization. It’s one of the (many) reasons I advocate for what I call the Centralized Partnership–centralization allows design to maintain it’s mindset and community of practice (i.e., it allows design to remain a little weird), while the partnership ensures those connections with the rest of the organization that keeps design relevant.
To maintain this balance requires vigilance and continual adjustment. This is a key aspect of any design leader’s role, ensuring that design doesn’t get run over by development processes, and not being so precious that it’s never put in a position to be realized.
(I’m writing a book on building in-house design teams. This brief passage struck me as worth sharing.)
In a networked-software-services world, to render an entire customer journey is a matter of managing overwhelming complexity. No team of designers, no matter how talented and capable, can acquire the necessary deep knowledge across so many domains to deliver robust work. This means that the design team can no longer rely solely on the hard skills of their practice and craft to succeed. In order to arrive at the most suitable solution regardless of context, the design team needs to practice the soft skill of facilitation. This is because designers are not the sole creators – there are too many moving parts, too much specialized knowledge necessary to fully appreciate a situation. Designers need to facilitate the creative output of others throughout the organization, tapping into a resource often left dormant. If working in a hospital setting, get nurses, technicians, and doctors to ideate around their specific problems. In a call center, have the customer service representatives pitch how they think things should be. The point isn’t to be slavish to the input from other functions – the design team still has the crucial responsibility of refining, honing, and executing these ideas. But it’s a recognition that the problems we’re solving are too big for any one team to have a complete handle on.
For the book I’m writing on building in-house teams, I was wondering if it was possible to articulate the Ideal Design Team, in order to have a frame of reference, of comparison, against which to judge any team. A quick chat on Twitter made it clear that this was a foolish proposition, but Leisa Reichelt suggested a developing a set of principles that could work regardless of organization.
I’ve spent the day noodling on this, and arrived at the following. I’ve tried to articulate them the way I would experience principles for a client — brief statements, hopefully memorable, that help drive decision making when thinking about establishing your team.
After I posted these to Twitter, Jess McMullin suggested: “10. Understand, articulate, and create value (for both business & users),” which I don’t think I can argue with.
For the book, I’ll dig into each of these. I’d love to hear y’all’s take on them, any glaring holes, or what you find most resonant.
I’m co-authoring a book on building in-house design organizations. In it, we advocate for what I call the “Centralized Partnership,” where design remains wholly centralized, and broken up into teams that are committed to different aspects of the business. We propose some radical ways of structuring your design organization, and I thought I’d share a rough draft of what we’re thinking.
===
Don’t just mirror the product organization or business units. In order for your team to successfully collaborate with others, it’s important to understand how the rest of your company is organized. However, it’s insufficient to have your design teams simply reflect that structure. Organizations grow and evolve over time, and the reasons for how they arrive at a particular structure are varied (e.g., acquisitions, firings, failed initiatives) and might not make sense for your team. A design organization that is not wedded to the structure of the broader company can help maintain a stable customer experience when the inevitable reorganizations occur.
If you can organize by customer type, do so. A fallacy is to have designers obsessed with the products and services they work on. Product and service features are just manifestations of parts of a user’s relationship with your company. Instead, you want your designers obsessed with their entire user’s experience. So, organize your teams by types of users. Many companies have clearly distinguished audiences — marketplaces have buyers and sellers; banks have personal/consumer, small business, and institutional customers; educational services have teachers, administrators, students, and parents; and so on. When a design team focuses on a type of user, it can go very deep in understanding them, and that empathy leads to stronger designs that fit the users’ contexts and abilities. So, for a marketplace, have a “Buyer Design Team†and a “Seller Design Team.â€
This kind of organization proves quite radical in certain companies. Banks and other financial institutions typically organize their teams around products or lines of business (basic banking, credit and debit cards, loans, mortgages, etc.) that behave as if in silos, and rarely coordinate. However, the same customer is engaging across these products, and can find the lack of coherence frustrating. To have a “retail consumer†design team that works across these products should lead to a better customer experience but will be difficult to maintain in the face of a company that incentivizes business units through their specific products’ success. This might require executive sponsorship to demonstrate just how crucial a cohesive customer experience is for the whole company.
Organize by the customer’s journey. If your company is successful, you’ll need to grow those teams. Keeping in mind that no team should have more than 7 people, consider splitting them up along a customer’s journey. For example, if you’re a travel service, you could section the teams into “Plan Your Trip,†“Book Your Trip,†“Take Your Trip†and “After the Trip.†Remember, this is regardless of whether the product or business teams are organized this way. Organizing by the journey allows each team to shift focus from features (search, browse, booking) to the overall experience, and the design work on those features will fit within the broader whole.
These specific teams will still roll up into a broader “Traveler Design Team.†It’s important that they remain in contact, even if it’s just a weekly meeting to share out what each sub-team is working on.
A ramification of this approach is that you might have designers from two different teams work on the same feature where your different customer types interact. One example of this is in a marketplace, where a buyer wants to book an appointment with a seller. From a product management and engineering perspective, “Book an appointment†would likely be the responsibility of a single feature team. In a decentralized organization, the same designers would work on the user experience for both the buyer and the seller. When you organize by customer journey, however, the concern shifts to figuring how this feature fits in the buyer’s and seller’s respective workflows. You want the Buyer Team to design the appointment feature in the context of the broader Buyer experience, and likewise on the Seller side. It might feel like inefficient overhead, but it should result in better conversion as the designs are mindful of context.  Â