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.

focused-on-user-types

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.

 

You probably don’t have enough designers

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!