Have better career conversations with your design team with this levels framework

tl;dr: I’m publishing a refined Design Team Levels Framework, based on what we’ve developed for Snagajob. Use it in good health.

As a design executive, one of the things I’m obsessed with is career development for my team members. We devoted a chapter to it in our book, including a levels framework which I shared in a post last September.

That framework was purposefully slightly vague, so leaders could adapt it to their org. This year, I became one of those leaders, joining Snagajob as the VP of Design. A few weeks ago, I presented to my team a new levels framework, which was a hybrid of what we had in our book, plus work that my Snagajob colleagues Rob Huddleston and Bridget Walsh had already done.

In the few weeks since sharing this new framework, my team leaders told me how it’s encouraged better conversations around professional development with their reports, how individuals on our team are using this to understand where they are and chart a path forward. I’ve been pleasantly surprised in the ways it has been embraced.

I’ve also realized that there’s nothing really proprietary about it. So I’m sharing it with the world. Here is the link to a public Google sheet:

Design Team Levels Framework

A key change from what’s in the book to this framework is the addition of an explicit Management Track. Our original framework was meant to be agnostic with regards to individual contributor (IC) or management, but through workshops and other sharing, we’ve found that it proved more confusing than helpful. Calling out a management track actually makes the IC track more robust, by showing how it parallels with management.

Also, the book focused on skills specific to software design. My team has communication design, copywriting, and video production practitioners, so this framework acknowledges those skills as well.

If you end up using this framework to guide your own efforts, we’d love to hear about it!

My chat with Stanley Wood

Over on Invision’s blog is an interview with Stanley Wood, a design director at Spotify. Stanley conducted a world tour and spoke with design leaders at many companies, and this conversations captures what he learned. I had the fortune of meeting him when he visited San Francisco, and Stanley shares what he took from our discussion:

At one point in the discussion, he said, “designers like to play together too.” It was so simple, because of course designers need to collaborate as much with designers as with non-designers; otherwise how do you ensure a consistent and delightful experience? It had always seemed like a binary choice—either sit together or sit apart—but in that one statement it was clear that both were important. There’s so much more I could add here, but instead I’ll just say the guy knows his shit and you would be wise to check out his book, Org Design for Design Orgs.

That’s an endorsement!

The whole interview is great. Read it!

The Minimal Design Team, according to Victor Papanek

In our workshop based on the book, we discuss the range of skills that need to be brought to bear for a design team (which is more extensive than what we wrote in the book):

design skills

This breadth is necessary for delivering on end-to-end service experiences that cross-channels, devices, and touchpoints. If the team doesn’t warrant having these skills on staff, it still needs to be responsible for the work done by any contract or external folks.

When we wrote this, we thought we were being quite bold in claiming design orgs should be responsible for delivery across such a gamut of practices.

Today I attended “Hippie Modernism” at the Berkeley Art Museum as part of Snagajob Design’s “Inspiration Day.”* It’s an impressive exhibit, detailing the intersection of progressive/counterculture sentiments and technological advances. There are many pieces devoted to design and architecture, and I was struck by this poster (“‘Big Character’ Poster No 1.: Work Chart for Designers”) by Victor Papanek, designer and design theorist who promoted humanistic values in design:


(Click to see larger. And give yourself some time with it. It’s worth it.)

44 years later, everything on this chart is still highly relevant to our society. Of particular note for people interested in design organizations is his proclamation of “the minimal Design Team”:

the minimal design team

So much for us being bold!

*Inspiration Day is a Snagajob Design team activity, where any team member gets one work day a quarter to go out and be inspired.

Where should designers sit?

One of the most common questions we get when teaching our workshop, and which friend-of-the-blog Todd Dominey submitted through our contact form, is “Where should designers sit?” It’s an interesting question, because it feeds a debate where there are two positions:

  1. Designers should sit with other designers in a studio-like setting, to benefit from peer critique, and learn and develop from one another.
  2. That’s stupid, because designers should sit with their cross-functional teams to better support product development.

For us, the response, as they say on Crazy Ex-Girlfriend (a show you really must watch, if you haven’t yet), is more nuanced than that.

To figure out where designers sit, consider a number of factors. In a company with a new design team, a small design team, or a low-morale design team, designers should sit together. This supports designers building a sense of camaraderie and learning from one another. If designers are isolated, they may grow weary of only being around those that are different from them, bristle at the lack of growth and learning opportunities with peers, and, eventually, leave to a company where they can grow their practice and careers.

As a company builds its design team and strengthens its culture, a transition occurs, where it becomes a benefit to sit with their cross-functional teams. The community bond is strong enough and the morale is high enough that it won’t break when designers are separated. There’s a productivity benefit when designers are in proximity to their cross-functional squads. And, with a strong design culture to draw from, designers advocate for a design-mindset with their non-design peers, helping make the whole company more design-driven. 

This should not mean a single designer sitting among a sea of engineers. There should never be only one designer working on anything – the idea of a design team is crucial, even if it’s just made up of 2 people. 

There is a third way, for companies with enough office space. Designers can have two seats — a primary one with their cross-functional team, and a secondary one with their design team (or with the whole design org). That way they still spend most of their time with their cross-functional colleagues, but also get time for critique, fresh eyes, fresh thinking, mentorship, etc., from the rest of the design team. It could work alongside a weekly cadence like this:

  • Monday—cross functional team: start the week with any planning, coordination, discussion, initial sketching
  • Tuesday—with design team: more of a ‘heads down’ day, with maybe an afternoon review across the whole team
  • Wednesday—with cross functional team: show the work that’s been done so far, get feedback, input, ask and answer questions, etc.
  • Thursday—back with design team: start applying polish to work, maybe more formal critique for refinements
  • Friday—with cross-functional team; wrap things up, get things ready for production, etc. etc.

We’d love to hear what you think, what has and has not worked for you. Leave us a comment!

Design Your Organization as Thoughtfully as Your Products & Services (From 2017 CX Outlook)

I contributed to Kerry Bodine and Doberman’s “The 2017 Customer Experience Outlook”, a collection of 14 smart pieces about design and user experience in the coming year, with the following short essay.

Design Your Organization as Thoughtfully as Your Products & Services

In the six years since Forrester Research first wrote about customer journey maps in 2010, the drumbeat for such service design practices and deliverables has grown steadily louder. In 2017, the penetration of smartphones and cloud computing has turned every company not only into a service firm, but one where customers expect 24/7 engagement through their channels of choice.

Companies must be thoughtful and intentional in how they coordinate the delivery of their service offerings across multiple digital and analog touchpoints, or they risk confusing and losing their customers to companies that prioritize customer experience.

Most organizations have not yet fully come to terms with the implications of this shift, and still exhibit a product mindset while delivering services. They structure their teams around specific features and pay most attention to launching new functionality, but customer insights (drawn from research or analytics) don’t feed into product development. Marketing focuses on communications and campaigns that are tenuously connected to the product, with more emphasis on building awareness and traffic. Customer service and support consist of overworked front-line employees who do not learn of changes to the service until they hear it from customers. These departments are siloed, connected only at the most senior levels.

At the heart of any service is the relationship between the company and the customer. Understanding and delivering on that relationship distinguishes great services. This is why journey mapping has become so crucial—it illuminates the experience a customer is having and encourages insights for improvements.

Journey mapping also suggests that design teams should be organized by customer journey. For example, if you have a marketplace model with buyers and sellers, discard the old approach of embedding designers in product teams. Instead, have one design team dedicated to buyers and another to sellers.

This approach is gaining traction outside the design world. Ken Norton, a product management thought leader who advises the companies in Google Ventures’ portfolio, wrote on his blog:

“Organize your product managers around customers, not code repositories. Connect product management (PM) areas of ownership to users and their product experiences. Maybe you have a buyer PM and a seller PM instead of back-end and front-end PMs. Or in a healthcare company, you’d have a PM responsible for the patient experience and another for the medical providers. When each PM has discrete ownership over an experience end-to-end, they can understand the customer problems more deeply and go all-in on representing their needs.”

This is a deep foundational shift in how companies organize their teams. It requires recognition that in a services world, the relationship with the customer is the most important thing. It makes “customer- centered” literal in structuring the org. For design teams, one of the clearest implications is that it no longer makes sense to separate marketing design and product/UX design. Marketing experiences and product experiences (and sales experiences, and support experiences) are all simply way stations along the customer’s journey. They should be orchestrated and coordinated through one design organization, with teams structured by customers and their journeys.

Design recruiting, portfolios, and showing work

Jared Spool tweeted about hiring designers and requiring portfolios a couple days ago:

As a design hiring manager. I require a portfolio. In Org Design for Design Orgs, I wrote:

The most important representation of a designer’s career is not their résumé, but their portfolio. Design managers end up reviewing dozens, if not hundreds, of portfolios for any role. For those designers who do not have public portfolios, ask to see one. Any designer under consideration must have a portfolio. No portfolio means no job.

As with any discussion started on Twitter, there exists greater nuance than can be comfortably communicated.

His blanket statement that “the best designers don’t have them” is wrong–many great designers do. But, yes, many great designers don’t have an updated portfolio handy, because they’re busy.

As a hiring manager, I am willing to start the recruiting process without a portfolio, if there are other positive indicators in play—their resume shows they’ve worked for companies with high design standards, or there’s a strong personal referral.

I advocate for 2 screening interviews before an on-site. In the case of someone without a portfolio, my first discussion would be to vet them as professionals, as people, their career, their trajectory, and if they seem to be a fit for the role I’m looking to fill (appropriate skills, seniority level, interest). The second discussion would be a detailed discussion of their work. While this wouldn’t need to be a formal portfolio, they would need to be able to walk me through 1-2 projects, even if that means pulling up working docs from hard drive folders.

But, and this is the key point: no designer is coming on-site without having shown their work in the screening process.

It’s also worth mentioning that when they ARE on-site, I do expect a more formal portfolio presentation, to be given to the interview panel and possibly other members of the design team. So if this person is serious about the role, they will need to find time in their ‘busy’ schedule to pull this material together.

If they claim to be too busy to do so, that’s a sign of disinterest, and it’s best to move on.


Customer-centered is the optimal org model in a world of services

In Org Design for Design Orgs, we argue that design teams should be organized by customer journey. Let’s say your service is a simple marketplace. Instead of having designers embedded in the different product teams that make up the marketplace (a fully decentralized and embedded model), or instead of having a single monolithic team (a fully centralized model), to instead have one team dedicated to the Buyer Experience, and another team dedicated to Seller Experience.


This reflects our belief that design works best when focused on customer journeys and their end-to-end experiences, in contrast to focusing on the products and features that make up those journeys. It’s a subtle distinction, but powerful–features are simply a manifestation of the relationship between customers and the business, and organizing this way helps a team pay more attention to the whole relationship, and avoid the trap of being so focused on specific features that they can’t see the forest for the trees.

I’ve been presenting this model for a couple years now, discouraging design teams from organizing the way engineering and product management teams do, because those functions have different operating models. Product management often organizes around, well, products, which are discrete entities whose success is determined within the bounds of the product. Engineering teams organize either by product, or by platform/codebase, in order to realize efficiencies and promote quality.

So I was surprised when earlier this year, product management expert Ken Norton shared his perspectiveOrganize your product managers around customers, not code repositories. Connect PM areas of ownership to users and their product experiences. Maybe you have a buyer PM and a seller PM instead of back-end and front-end PMs.”

He then published a response from product executive Noah Weiss: “Just like it’s ideal to organize your PM team around customers and use cases, the same goes for engineering. Otherwise, you risk having a PM responsible for a use case having to work with half a dozen engineering teams to ship a feature: server, web, iOS, Android, infra, etc.”

So, what’s going on here?

I think these perspectives have aligned as a reaction to a broader shift in business, from products to services. Microsoft and Adobe once made boxed software sold on shelves, and the teams that worked on them were rightly focused on what went in their box. Now these companies sell subscriptions to access across their suite, and so coherence and coordination is crucial for success.

The key distinction between a product and service is that the service is predicated on a customer relationship. And in these networked services, these relationships must be maintained 24/7.

As companies embrace what it means to be a service firm, they understand that what’s most important is the healthy maintenance of that customer relationship. And so they realize they need to move away from old methods of organizing that were anathema to a customer’s end-to-end experience, and towards customer-centrism.

I believe design, because of it’s empathetic stance, and relatively smaller team size, has been able to sense and react to this shift ahead of other teams’ awareness. But whereas I used to think this orientation was perhaps specific to designers, I now believe we’ll see entire companies reshape this way.




Centralized vs Decentralized UX orgs… over 20 years ago

In Org Design for Design Orgs, an entire chapter (Ch. 4, The Centralized Partnership) addresses organization models for design teams, specifically centralized, decentralized and embedded, and the Centralized Partnership, our preferred hybrid approach.

After I spoke at the Big Design Conference in Dallas last week, an attendee, Randolph Bias, pointed me to a paper he co-wrote in 1995 (“Usability Support Inside and Out”, PDF) about about whether or not usability engineering teams should be centralized or embedded. It turns out our book echoes many of the themes in this 20-year-old paper…

On the benefits of centralized:

Regarding the objective of maintaining usability engineering expertise, one primary advantage of the centralized model is it facilitates maintaining a human factors “critical mass.” The “care-and-feeding” of the human factors professional is very likely to be monitored, and good, under such a model. Relatedly, it is easier to hire new human factors professionals into such an organization, and the department manager is likely to know how to evaluate the professional’s contribution.

And the benefits of “mainstreamed” (their term for embedded):

The beauty of being a mainstreamed human factors professional is being, and being seen as, a team member. The clear buy-in of someone in the development group per se helps with communications to and from the rest of the product developers.

Plus ça change, plus c’est la même chose.

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.