Glowing unsolicited feedback about “Org Design for Design Orgs”

In writing Org Design for Design Orgs, Kristin and I had a sense of the kind of impact it could have, in that it addresses a gap in the current conversation around design, specifically on organizational, operational, and managerial issues. And while we consider this topic vital, we weren’t sure how readers would respond.

So, color us thrilled when this unsolicited feedback come our way a couple days ago. Responses like this that affirm our toil was worth it, and suggests the kinds of value you might get from the book.

Thank you so much for writing this book! The minute I started reading it, I couldn’t tear my eyes from it. It was almost 2am when I found myself in the middle of chapter 7, and had to really talk myself into getting some sleep that night.

Your book is so rich with personable, practical substance on how build design culture, that I felt like I was in a cozy fireside chat with a design mentor. It’s like I was listening to stories from someone who has lived through it all. Someone who could relate and empathize deeply with the issues I’m facing with my design organization now, and give smart, actionable advice on how to proceed forward.

I’m a designer and researcher at a startup that grew from 25 to 50 people over the course of 2 years. Our design team suffered through the “drawbacks of centralization” (your description of the “us vs them attitude” and designers rolling their eyes was uncannily accurate), and are now going through the “decentralized and embedded” setup. We haven’t lived in this model long enough to hit the drawbacks, but reading your book felt like it was a warning for what’s to come. Then reading about the “centralized partnership” is where I got seriously excited, and made me itch to propose these changes to my team immediately.

Our design team has been through so many ups and downs. Struggling with getting design to be recognized, getting research to be valued and integrated, designers hitting career ruts and stunted growth, issues with aligning with leadership. This book covered all these issues in well organized manner, supported by clear diagrams and real world stories.

This truly is the book I wish I had since the beginning. The book I would reference with, write proposals and plans with, wallow in sorrow with, get uplifted with hope with. It confronts the reality of being an in-house designer straight on. I always have it with me when I’m at work, showing highlighted sections to my design manager, to product managers and engineering leads I work with.

It’s not only a book that I know will be useful throughout my career in design, it’s the greatest design mentor I could ever ask for, always in my back pocket.

Thank you so much for writing this book.


Levels framework: like Lebowski’s rug for your design org

From Chapter 7 of Org Design for Design Orgs:

Many companies use a framework of levels to chart the seniority of employees. Typically, human resources (HR) teams use levels to calibrate employees across different functions, to make things easier in matters such as compensation. The risk of working with levels is adopting a bureaucratic stance, seeing team members not as people, but as resources within a certain band of experience. Do not let levels define the team. Instead, use levels from the perspective of the team members, who are eager to understand how they can grow and evolve in their careers. Done right, levels are the scaffolding that helps team members elevate.

In the chapter, we share a 5-stage levels framework. Because of printing constraints, we couldn’t put the entire framework on a single legible page, so here it is available for download (PDFformatted for 11 x 17, aka Tabloid, and should work in A3 for our friends outside the US).


I’m about to tread in some deeply organizationally geeky areas here, so be warned.

Since writing the book, and consulting with companies on design org matters, I’ve realized that a solid levels framework acts as a ‘core service,’ plugging into other aspects of running the org. Without this framework, design orgs flail, particularly those with more than 20 members.

Performance review and professional development

Most obviously, a strong levels framework assists performance review processes. As team members and managers work together to chart professional growth, having a clear understanding of expectations, and what it means to be promoted, proves essential. And to make sure that this is fair across the whole team, it’s necessary to make these expectations explicit and public, so everyone can see where they fit.

Many design managers are cavalier about levels, operating as if they’re not that important. If a team member wants to be called “Senior,” well, what’s the harm in that? As someone who has inherited teams over-leveled people, the harm is that the team member is not being honestly supported in their professional growth. Accelerating people through through levels before they are ready is a set up for failure. And if someone like me comes in and tries to rectify a chaotic situation with a clear framework, these team members feel frustrated as they are inhibited from further promotion until they appropriately shore up their experience and authority.


In the Levels framework we developed, progress for designers is tied to skills building. This feels appropriate for a role that is about practice and craft. As stated at the beginning of this post, it’s important to approach your levels framework from the perspective of a team member, particularly one earlier in their career who is figuring out how to grow. This can then tie into a more formal professional development or training program, as designers take classes, attend conference, read books, and practice, either deepening existing skills or acquiring new ones.

Team creation

A levels framework can assist with team creation. You will likely want to have a mix of junior and senior people, including someone who can serve as a strong lead. And through the skills-building previously mentioned, you’ll understand how can do what, and how to match them in a complementary way. If you find a skills or leadership deficit, that can inform…

Recruiting and Hiring

When opening a requisition for a new team member, how do you know the level of seniority you’re looking for? Many teams either guess, or they don’t bother specifying.

More importantly, how do you judge the seniority of a candidate? You can’t rely on their job title, as those are notoriously subject to inflation. Without a levels framework, this assessment is done relative to those who are already in the org – if the candidate seems to be about as senior as Jane, and Jane is a Lead Product Designer, than the candidate is brought in at that level.

However, in large design orgs comprised of many teams, that relative ranking becomes dodgy. It might not be apparent that one team’s senior-level candidate might be another team’s mid-level, and if that person moves between teams, it can be awkward. A clear, shared levels framework prevents this confusion.


This gets us back to compensation. Without a clear and shared understanding of levels, an organization may have two people doing the same thing but ranked differently, or two people ranked the same but with differing expectations. Since compensation is typically tied to levels, team members, particularly those who are expected to do more, but are earning less, will feel the unfairness. A clarified levels structure makes sure that folks are appropriately  ranked, and helps a company’s compensation consultants do better benchmarking when comparing a company with the broader market.

Ties it all together…

As I’ve engaged with more and more companies, I’ve found that a Levels Framework is like the rug in the Big Lebowski


Without it, all these important operations are untethered, with arbitrary decisions made in the moment that, when combined lead to an incoherent mess. Levels work as a ‘core service’ that ties together these elements into a cohesive whole.

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!