Structuring Teams and Portfolios for Success

Richard Dalton at UXDX USA. Video: https://youtu.be/vlxBWEjK4pE

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

From cash to an experience

[00:00:00] Richard: I've spent the last 25 years or so, which makes me feel really old when I say it that way, leading design teams at some of the world's largest organizations. The challenge, though, has always been the same despite the differences in those organizations, and that is how we get from cash to an experience. As a design leader I have a budget for my design team, as do my product management and technology partners, and using that budget we need to create an experience. When you're in a smaller organization or a startup, you can just hire a couple of designers and say, "Hey, design me an experience, design me a website or an app," and that kind of works. But as you scale organizations and as your ecosystem becomes more complex, you need a little bit more framework to that.

[00:00:47] As I've looked back over the 25 years, I've been in four large organizations here in the States, and I've seen some patterns emerge, and that's what I want to walk you through today. I've dramatically, overdramatically, created what I'm calling the ziggurat of impact. These are the different layers that frame up the different systems and programs that we put together, and I'm going to walk through each of these from the bottom up this morning.

The taxonomy of systems

[00:01:14] Let's start with the lowest layer, the taxonomy. I think it's important to recognize first that one does not simply design experiences. In fact, I don't think we design experiences at all. An experience is something that somebody has, not necessarily something we actively make. As one of my colleagues, Alexa Curtis, who's here in the audience somewhere, Alexa, where are you? There she is. Alexa, you're going to see a lot of your work in this presentation. As she is very fond of saying, an experience is the sum of a person in a situation interacting with a bunch of systems, and then they have an experience. The experience is the outcome.

[00:02:03] So what are those systems? That's where we put a taxonomy together. At Verizon, those systems start with our consumer products, the things we make that people buy and use. They can be physical things like routers and gateways and watches and soundbars. They can be virtual products like our cloud storage services or call filter services. They could even be our data plans, the mobile phone plan that you use for your connectivity, or your home data plan.

[00:02:36] Those products are interacted with through touchpoints across channels: digital ones, websites and apps; retail ones, stores; call centers, where people call in and talk to associates. These are the moments where interactions happen between our customers and Verizon. Sometimes these can be internal employee touchpoints; we're responsible for the design of those too. We also have shared capabilities, things we've identified are common to many products or touchpoints that we just want to design and code once, like authentication and personalization. Even our Verizon design system, the Lego blocks that we build digital systems from, is a shared capability.

[00:03:22] The final piece is our customer activities. This is a newer piece, and it's something we're doing to really help us stay very customer centric. These are the jobs to be done, if you will, from a customer perspective. They wake up in the morning and think, "I'm going to do X with Verizon. I'm going to get the new phone with Verizon because the new one just came out, or my old one's broken. Or I just got paid, so I'm going to pay my bill with Verizon today. Or I just moved, so I'm going to change my address at Verizon." This is our inventory of customer activities. Actually, these are just the sales and service customer activities. We have a whole other set that we're building of use customer activities, where people are using our products on a daily basis, like using our cloud storage services or call filter, or using their data to receive a text, make a call, doomscroll on TikTok, whatever.

The story of Dr. David Dao

[00:04:17] I do have a confession to make, though. This taxonomy is still a work in progress, and it only really represents the top 10% of the iceberg above the water when it comes to doing customer experience in a large enterprise. There's an incredible amount in the rest of the enterprise that still has an impact on the customer experience. To drive that point home, I'm going to tell you a quick story about Dr. David Dao. You're thinking, who the heck is Dr. David Dao? When I remind you of the story, many of you will remember what happened a few years ago.

[00:04:52] This is Dr. David Dao, and he was trying to get from Chicago O'Hare airport to Louisville, Kentucky, on the last United Airlines flight of the day, back in 2017, I think it was. That flight was completely full, and the issue was that United also needed to get four crew members to Louisville from Chicago so that they could crew a flight out of Louisville the next day. So they asked what most airlines do: would anybody like to get off the plane? They were actually boarded at this point. Would anybody like to get off the plane and take the next flight the next day, which is 20 hours later? We'll put you up overnight in a hotel, give you a meal, and give you $400 in vouchers for travel. Crickets. Nobody wanted to get off. How about $800? Somebody please get off the plane for $800. Nope. Everybody wanted to get out of Dodge and get out of Chicago and back to Louisville.

[00:05:44] Then they said, "Okay, we're going to pick four of you. We're going to use an algorithm, and you'll have to get off." So they used an algorithm, and I'm pretty sure it didn't select any Platinum club members or anything like that, and they said, "You've got to get off." Three people got off. Dr. Dao did not. He said, "I'm a doctor, I have a practice in Louisville where I live, I've got people I'm seeing the next day, I can't get off the plane." So United sent onto the plane some members of the O'Hare Airport aviation security force, one may say thugs, who essentially assaulted Dr. Dao. They dragged him off unconscious and bleeding, because they smashed his head against the armrest as they were dragging him off the plane, in front of everybody on the plane, who were recording it on their phones and frantically posting to social media.

[00:06:36] I think we can agree this is not a great customer experience for anybody involved, particularly Dr. Dao, nor the other passengers, nor the staff, even for the CEO and chairman of United, who at first blamed Dr. Dao for being the one at fault and then the next day had to completely recant that and issue another apology for that as well as for what actually happened.

[00:07:00] The interesting thing is that none of this was really the fault of the touchpoints, the customer products or the shared capabilities. It was a failure of process, business rules, policy, maybe even training, deep in the United hierarchy. United's policy was to not go above $800 to incentivize people to get off the plane. Because of this incident they've actually changed that, and now the gate staff can offer up to $10,000, which they've offered a couple of times, never when I'm flying, to get people off the plane if they need the seats. So it's worthwhile remembering that the taxonomy, as good as it is, and as foundational as it is for what I'm going to talk about in the rest of this morning, is only the top 10%.

Measurement

[00:07:47] Okay, back to the ziggurat. That's the taxonomy, we know the systems. How do we know whether they're any good or not? We need a measurement layer. Oh, so many acronyms. In order to meet my Verizon acronym quota I had to include all these on the slide. We've got NPS, Net Promoter Score. We've got DIS, we've got RIS, we've got product interaction score, which I've been told under no circumstances to make into an acronym. We've got customer satisfaction, and we've got customer activity score.

[00:08:20] Hands up who knows what NPS or Net Promoter Score is? Or keep your hands up if you'd recommend it to a family member or a friend. Now, so many detractors. For those of you that don't know what NPS is, you ask a simple question: on a scale of 0 to 10, would you recommend this product or service to a family member or a friend? Those that score you 0 to 6 are detractors. Those that score you 7 to 8 you ignore, because they're neutrals. Those that score 9 or 10 are promoters. To get the score, you subtract the number of detractors from the number of promoters, creating a theoretical score of negative 100 to positive 100.

[00:09:00] I'm not going to get into the validity or usefulness of NPS as a broader business tool, mainly because we're already behind and I don't have all day here. What I will say is that from a CX and design perspective it's not that useful, because it's a trailing metric and it's huge. There's a lot that goes into it, so figuring out the impact of your actual experience and designs on your NPS is very difficult. In fact, Jeff Gothelf, who has a lot of great articles and commentary on this, and I've included one of his articles up here, is much more fond of saying: ask yourself what the behavior is. What do satisfied customers do in our product? Measure that instead. Do they buy more? Do they tell more people? Do they spend a lot of time in your product or a little bit of time, depending on what's good for your product?

[00:09:54] I'm also fond of asking the inverse question: what do dissatisfied customers do in our product? Measure that. Do they leave quickly? Do they complain a lot? Do they hop channels? They're trying to do something on digital, they can't figure it out, so then they call you. That's what our DIS and RIS, the digital interaction score and retail interaction score, try to do. They take small pieces of the experience and ask people, "Were you able to do this task satisfactorily? If not, why not? Give us some feedback." And we can use that to gauge the health of our experience.

[00:10:27] Same thing with our product interaction score, which is a newer measure that focuses on the use aspect of our products. Customer satisfaction is a similar thing, but in the call centers. And then the customer activity score: we're trying to create these dashboards for our customer activities. This is a work in progress, a fake one obviously. They reflect how easy it was, or how satisfied people are, trying to do that holistic activity that they wake up in the morning thinking about, like "I'm going to get the new phone from Verizon."

The portfolio

[00:10:59] So that's measurement. Let's think now about the work, the portfolio. Who knows what this is? A Risk map. The game Risk, world domination. You put your armies and your cavalry and your cannons in the countries and you go to battle to see who can dominate the globe. You can put one army in a country, or you can put a big stack of armies in a country if you're going to do a lot of work there.

[00:11:30] This is our Risk map at Verizon. This is our portfolio coverage. All that stuff on the taxonomy, the touchpoints, the products, the capabilities: touchpoints on the left here, products on the right, capabilities towards the bottom somewhere. We've broken them out into more manageable portfolio chunks, and this is what we work on. This is our universe. The color coding indicates how well staffed a particular area is. Black: there's nobody home, nobody paying attention. Red: we've got somebody keeping half an eye on it. Yellow: it's okay, we've got a couple of people there. And green: fully staffed.

[00:12:06] You can see there's a lot of black and red and yellow on our map at the moment. That's okay. The goal is not to turn the whole thing green. For one, that would create a huge design team, and it would generate way more design than the rest of the organization could handle. This is useful to get alignment with our product and technology partners about where we're putting people. It's useful for prioritization. As a leader, when one of my colleagues comes to me and says, "Hey, I just got this customer escalation complaint about this thing that's happening," I can pull this out and say, "Well, that's in one of these black boxes and we've got nobody paying attention. I could put people there, and then we'd have to put product management and engineering people there too, but we'd have to pull them from somewhere else. So let's have that conversation." It's also useful to help show the impact of increased design funding. I can now show black boxes going red, red boxes going yellow, yellow boxes going green over time.

[00:13:03] The other aspect of the portfolio is what type of work we're doing. All the work in those boxes is not the same. Sometimes we're doing visioning work, sometimes optimization work, sometimes execution work. Again, that's helpful for setting expectations with our partners about how long it takes to do these things, helpful for understanding the skill sets we need to do the different types of work, and even helpful for understanding the type of money we can spend. My design team is funded from both OpEx, operational expense dollars, and CapEx, capital expenditure dollars, and they show up very differently on the company books. If we're building assets that can show up on the balance sheet and be depreciated over time, we can spend capital dollars on that, and that gives us a lot more flexibility in funding. It's mainly this work in the middle that is capitalizable work.

Process and ways of working

[00:13:52] So that's the portfolio. How do we get that work done? Let's think about process. I'm a big fan of the Baby Bear methodology of process: not too much, not too little, just the right amount. We've been spending a lot of time, Alexa has been spending a lot of time, helping put practices in place not just for the design team but for the product management and engineering teams as well, on something we're calling our ways of working. There are many different things to consider. I'm just highlighting four here.

[00:14:29] We've been very much adopting a product model in our way of working. Back in the day there was a big list of projects and a big pool of resources, and we used to assign the designers to the projects. When the project was finished, they'd go back into the pool and be assigned to a different thing. Not very agile, not very product thinking. You don't build up institutional knowledge, and you don't allow people to form relationships with their partners in product management or engineering. So now we have a product model organized around the portfolio and the coverage map, the Risk map I just showed, which allows people to have a bit of stability in what they're working on and build up knowledge around it.

[00:15:06] We've also done work around who has the ACTs, the agile collaboration teams. These are our teams that actually put their hands on the code and change the code. Until we made some of these changes, everybody had an ACT and they could change anything they wanted. So we'd have a web page, an ACT would come along and change something on the web page, and then another ACT would come along and undo that thing on the web page, or change something else, or two ACTs would try to do the same thing to a web page or a mobile app. It was very wild west. Now we've got much clearer ownership around the product model, so each box on the taxonomy has an ACT that can change it, and only that ACT can change that piece of the experience, that piece of the system.

[00:15:54] What that has also done is meant that we need to put some prioritization governance in place, because we want to empower our ACTs and our product teams to have ownership of the pieces of the system that they're working on and to improve them. Let's say we've got one focused on the checkout process. We want them to be able to spend some of their capacity making that the best online checkout process they can, from a local optimization perspective. We also have to make sure that they've got some capacity to do broader global things. Let's say we've got a big product launch for a new product coming that needs some changes to the checkout process to accommodate this new product, as well as changes across a whole bunch of other parts of the ecosystem. So each team has to juggle these global versus local priorities, and we've put some governance in place in order to do that.

[00:16:41] One of the biggest pieces of feedback we get from our teams when we ask them for feedback is about clarity of roles and responsibilities, so we've done a lot of work there too. For example, understanding what the role of a customer activity owner is, from a product management perspective, versus a customer activity design lead. Who does what? Who builds the service design blueprints? Who gathers the information? Who identifies the points of pain? We've done some work to tease those things apart so we can have better collaboration. We've also thought a little about role ratios. There's no point having a bunch of designers if you don't have any product managers or engineers, or vice versa, which is probably more common. So we need to get those ratios correct.

People

[00:17:24] All right, so now we have ways of doing stuff. Let's finish by talking about arguably the most important layer, the people. I know it's the narrowest in the ziggurat, but if you don't have great people, the rest of it doesn't really work at all. There are many different facets from a people perspective; I'm just highlighting five or six here. Diversity, obviously, is hugely important for us. Not only is it the right thing to do from a human perspective, it's actually proven to create higher-performing teams. We think about all aspects of diversity on the team.

[00:18:00] We are challenged from a diversity perspective in different ways in our different geographies. In India, for example, we have a large design team, and the thing we are most challenged with there is gender diversity, ensuring we have equitable representation of women in the design team and at design leadership levels. In the US, of course, we're still very concerned about gender diversity, but on the design team we're very well represented there, so that's not our major focus. Our major focus in the US is on racial diversity across the design team and the design leadership team. So that's what we focus on.

[00:18:36] As I mentioned, we're geographically dispersed. Here in New York we have teams right next to Freedom Tower, and teams out at the Basking Ridge headquarters. In India we have teams in Chennai, Hyderabad and Bengaluru, which is the new name for Bangalore. And we have some contractor teams down in Costa Rica as well. So we think about how we leverage the global workforce, what each team specializes in, where our centers of excellence are. In India, for example, a lot of our teams have deep institutional knowledge about our employee experiences, those internal-facing experiences and systems, so a lot of that is done there. We also have tremendous front-end development resources there, so a lot of our design system engineering work is done in India, for example.

[00:19:21] Labor types. We leverage full-time employees, contractors and agency resources. We are underrepresented with full-time employees right now. I could tell you the exact percentage, but my communications colleagues who reviewed this deck before I came here said I would have to kill you all if I told you, so I'm not going to do that. I'm going to say it's below 30%, how about that. We think that is unsustainable for an internal design team. Fortunately, our leadership agrees, and we've just started to flip that. We want to get to 70%, probably by the end of next year, maybe 55% by the end of this year. So we're hiring 180 designers in the US and India by the end of the year. Lots of reqs open, just saying. Come find me or Alexa, Isu [?] or Andrew in the third row here. We'll be here all day. Résumé on a postcard, please.

[00:20:25] Skill sets. We have the full range of skill sets you'd assume for an internal design team: visual design, interaction design, information architecture, content strategy, front-end development, research. Service design too: because of our customer activity work, we're hiring from a service design perspective as well. Again, just saying. We're not just building a team, we're building a culture of design. Verizon is a big enough organization, and ours is a big enough team and growing, that we want to build a thriving design culture, where people can be curious and experience different roles and different products. We have a vast range of different things: we build hardware, we build software, we build services, external and internal. So we want to build that thriving design culture, and we put a lot of effort into that. It's very important, and we invest in programs to do it.

[00:21:13] And then performance management. I was once told by one of my best bosses, way back at Vanguard, that feedback is a gift. I think he might have been giving me some feedback at the time he said it, but it still counts, and I still very much follow that philosophy. The challenge with large design organizations, and large organizations of any discipline really, is that when you've got dozens of people managers, you need to ensure that the feedback you're giving and the expectations and standards you're holding people to are consistent and unbiased. So we put a lot of effort into creating systems for ourselves that use anonymous data to calibrate our people managers to have the same expectations. So when a lead designer is being led by Adam over here and a lead designer is being led by Alex over here, they are both receiving the same set of expectations and being evaluated against the same criteria.

[00:22:09] Indra Claven [?], my former head of design operations, did an excellent post on this a couple of months ago. I put the link here, it's well worth a read. It's 100% true; we're still using it today. I think I have time for a quick anecdote. One of my cousins, who isn't in the design space, works out in Portland for a company, and she texted me: "Hey, I just saw this article on LinkedIn that you were referenced in, about this calibration thing. Normally I would just attribute that to complete LinkedIn BS, but since you're in it, is it true?" I said, "It's 100% true, and we still use it today." She said, "Wow, I found an article on LinkedIn that's 100% true. It's great."

Design operations makes it happen

[00:22:52] So that's how we get from cold hard cash to an experience. We inventory our systems, we unpack them so we know what we're working on. We put measurement on top of them so we know what's good and what's not good. We build portfolios of teams to do that. We give those teams processes and best practices, and we staff them with awesome people. Now, since I mentioned design operations, one last thing. None of this happens by itself. It takes effort, it takes work. You've got to build out an effective operations team, and you've got to invest in that. Yeah, woo, hey for design operations. That is an investment that pays back multiple fold. It really multiplies the value and the effectiveness of your teams, and honestly, it keeps the designers doing what they do best, which is designing, which is what we want to try and do. Thank you very much for listening.

Q&A

[00:23:56] Did I hit zero right on the mark? That's pretty impressive. I'm impressed.

[00:24:02] Host: I feel like you're trying to hit their bar, not my bar.

[00:24:04] Richard: I hit the bar.

[00:24:08] Host: That was phenomenal, thank you. In the time that we have for Q&A here, what I'm personally interested in is fairly similar to what's here. I think there are a lot of people interested in that 180 number you threw out there, which is going to keep you busy here today. I'm curious, at a high level, where do you think UX is headed compared to where it's been, as a role, as a discipline?

[00:24:48] Richard: Where UX is going over the next five years. I'm not going to say AI, because there's too much conversation around that.

[00:25:00] Host: Even though you legitimately just said it.

[00:25:02] Richard: Well, yeah, I won't talk about it then, how about that. What I will say is that the United story with Dr. Dao is, I think, symptomatic of what happens a lot in organizations, maybe not to quite that extreme. So from a UX and design perspective, it behooves us to not just design the UI, not just design the products and services, the things people use, but to design the organization at a deeper level, and to really think about the influence we can have on everybody else in the organization. Within Verizon we have about 100,000 employees, and currently 300 or 400 in the design team, but every single one of those employees has an impact to some degree on the customer experience. Raising that level of awareness, that everything everybody does ultimately has a domino-like impact on the customer experience, is, I think, where design and UX needs to go. Otherwise we're just going to be fighting with our arms tied behind our back.

[00:26:11] Host: So it sounds like it's more about getting woven into the fabric of the company at large.

[00:26:23] Richard: Exactly.

[00:26:23] Host: Love that. I also love any presentation that has a pyramid in it. I'm kind of a sucker for that, I don't know about y'all. As far as the 180 slots that are open, there's an interesting question about how that number was pegged. Can you talk to us a little about some of the math associated with that?

[00:26:51] Richard: Yeah. We know the design team has been growing over the past couple of years, so we know what our total budget is and how we spend that across our labor types. We know the target we want to get to, 70%, so we did the math of how much of the contractor or agency budget we would have to flip into headcount in order to get to a 70% ratio of FTEs, and what we think is achievable this year. Candidly, we had hoped to have the full 12 months to achieve 180 people by the end of the year. We only opened reqs last week, so we've now got seven or eight months left. We think that's aggressive, so we will be going into next year to try and get to that 70% ratio. But it was really just math in terms of how much we have to flip over, because we're doing it, by the way, at zero incremental cost. It's not costing us a penny more, and we're actually getting 20% more labor, more resources. So the coverage map that I showed with the black, red, green and yellow is going to improve just because we're switching the labor mix. It's got multiple benefits, not just to the design team but to the organization as well.

[00:28:04] Host: I loved all your slides, but my favorite was the portfolio mapping. I really loved the color coding there. And it sounds like your response is a combination of CapEx and OpEx, and trying to recalibrate based on the needs of the business.

[00:28:21] Richard: Yeah.

[00:28:21] Host: Wonderful. Ladies and gentlemen, Richard. Thank you.