Empowering High Performance Teams with Better Work Practices

Teresa Cain, Scott Himmer, Catherine Madden at UXDX Community: USA East. Video: https://youtu.be/y6_gMvEfAM0

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.

Getting feedback before and after release

[00:00:00] Audience: Obviously you're not always able to get user feedback, but how often are you incorporating that before your release cycles? I was just curious.

[00:00:08] Scott: It has varied. I think there's a general practice, but usually it varies with the company. We actually have a team of UX researchers at Renaissance, and we do a lot of studies beforehand, especially if it's a very complicated space that we're going to be digging into. But in terms of feedback, are you referring specifically to after a release, or feedback from designs, like user testing of design concepts?

[00:00:35] Audience: Yeah, and I have my question typed in there, but are you doing any additional changes after you release? Are you getting additional feedback once you go live?

[00:00:47] Scott: We are, yeah, we definitely are. I think sometimes the barrier to that, for some companies, and I think some companies are getting better than others at it, is that it's not this big bang: ship it, and then we pat ourselves on the back and think we're done. There's always this ongoing work that needs to be done for improvement, pruning, and that was the crux of the talk that I had. When we don't do that, all that stuff is building up, and that's all going to contribute to debt. It's going to slow us down. That was the whole idea behind the talk.

[00:01:19] We definitely are getting feedback afterwards, and we're tuning as we go. But what we're trying to do is put that research effort up front, and then when we have design concepts we'll do A/B testing, we'll do user testing, so that we have more confidence and reduce our uncertainty before we release. But then, as you're pointing out, following up on what additional work needs to be done once it's really out in the world is important, and we do do that. I do think that there's definitely room for improvement there, though.

[00:01:50] Audience: Yeah, that's great.

Skill sets on high-performing teams

[00:01:53] Catherine: To shape the start of this conversation for people tuning in: the topic is around empowering high-performing teams with better work practices. There are three areas that I'd like to focus on, and I'd be open to your suggestions on others. One would be around skill set, another would be on motivation, and then structure. The first one I'll talk through is skill set. For high-performing teams, is there anything that you feel is needed in the skill sets area? Do skills or talent matter when it comes to high-performance teams? Teresa, I will ask you that question first.

[00:02:43] Teresa: Sure. Usually when I'm building a product and UX team, I like to have a mix. We're really big on personality profiles, so I usually try to bring in a mix of personality profiles, and then, from a skill set, a combination of analytical and strategic thinkers. What we found is that combining that together covers all your bases, everything from our two-hour design sprints to just how we go and perform on different products and solutions.

[00:03:20] Catherine: I love that. And Scott, what about you? What's the skill set you look for?

[00:03:29] Scott: It's probably a cheap answer, but I would agree with Teresa: having a variety of skills is important. In fact, it has come in to be detrimental [?] in some cases where you have a strategic thinker, and they may not be the strongest visual designer, but they're thinking big picture, all the way around end to end, in a future vision. But they don't have the polish that a very creative visual designer might bring to the table. I've seen really awesome collaboration between those different skill sets, and they're actually cross-pollinating, because you're taking your visual designer who's working to be a strategic thinker, and they're building skills from one another.

Onboarding people while leaving room to shape the culture

[00:04:15] Catherine: Yeah, I like that. This whole skills piece reminds me of a talk that was done by Netflix around onboarding new people versus current people working in the team. You look at better work practices, you create a structure that you feel is right for your team, then you get a new person coming on board who has worked in a different structure in a different company, and you hired them for a reason. Teresa, first, how do you manage work practices and processes, and at the same time allow people the autonomy to come in and shape the culture of the company?

[00:05:00] Teresa: That's a really great question, and I'll say it has changed. We'll have been remote for two years in March, and we're not going to be going back to the office until a bit later this year. So it's definitely changed since we've been remote. How I've countered that is, first of all, I think there's usually a pretty large asset in why we've hired someone, and we want them to bring that outside knowledge in to help shape where we're trying to go, both from a strategic and an analytic standpoint, as mentioned earlier.

[00:05:31] Usually what I do from a team training standpoint is, every time someone new comes in, I set up a list of about 30 individuals across the entire company, and I have them meet with them for 30 minutes to an hour to learn about their role and also knowledge-share their background. I also do training. It used to be monthly; it's gotten a little more challenging with meetings because our team is growing, which is always a good thing. But usually we do at least monthly or quarterly training on different product or UX or design topics as a group, and team building.

[00:06:04] What I try to do there is allow that person to take their background and bring that knowledge as we cultivate new roadmaps for both product and UX. And we've really seen it firsthand. We've actually had a number of new product managers come in, and the amount of ideation that we've been doing the last several months has been amazing, to lift several-year roadmaps, which is what we're working on right now.

[00:06:31] Catherine: Wow. And have you tried anything that hasn't worked?

[00:06:36] Teresa: In onboarding and bringing people in, I think the thing that is always lacking... I mentioned our use of two-hour design sprints, not just for technologies but also processes. I think documentation has been something we've always needed to improve as a team, because we don't have time for it. We're always busy in client meetings or with engineering or on sales calls. So we need to be better at documenting and creating more documentation around the training, which we're working on putting some time towards. But that's the one thing that hasn't worked: documenting it.

[00:07:13] Catherine: Documentation debt should be a whole talk in itself. Scott, how about you? How do you look at getting people involved in their processes?

[00:07:26] Scott: I think there are a lot of similarities with what Teresa is mentioning. I would say at its core it's putting some framework in place, and it can't be too rigid, because for me that has never been successful. Having some framework gives them a frame of reference for the space that they're now going to be working in. In addition to that, it can't be so rigid that it doesn't allow them to bring their creativity and bring their ideas to the table, to help maybe better support that framework. I think bringing people on board is like the product experience: it's always evolving. How are we always working to prune and make it better?

[00:08:09] At Renaissance we meet twice weekly, just connecting, because there are different designers working on different things, and we just want to share what we're working on. Not only do we do critiques of our work, because it actually helps us to be better presenters, it helps us formulate our thinking. Besides just the design, there's also this influence or presentation skill that we're trying to build up in people, not only the researchers but the designers as well.

[00:08:34] There are different workshops that we might do together. We do a round robin in our group for doing presentations. It's like a UX training, but it's individual designers presenting on whatever topic they have at the top of their mind. It may not even be UX related, but it may be industry related, and we're in the ed tech space. That's another opportunity of giving people room to grow within the space of the framework that they've been presented. Because there's nothing more crushing than taking a really creative person and putting them into this framework where they have no room to have any influence at all. That's just so soul-crushing, and I've seen it before, and it's not a good place to be.

Building skills when an area is lacking

[00:09:23] Catherine: No, it's not. I have an audience question here that I'll ask you, Scott. How do you build the skill sets within teams when a particular area is lacking?

[00:09:32] Scott: That's a very good question. Skill sets within the team when a particular skill set is lacking. I think they might be talking about not even just the skill set, but probably short on resources. When I was working at Delta, we had a bunch of designers coming in, and they were always looking for very specific skills. You have this balance: do you hire people for the specific skills that they have, or do you hire a generalist? You can argue one way or the other. But at Delta, in the beginning, they were trying to hire generalists, but what they really needed was really strong interaction designers who have more of a technical understanding, because it's a very complicated technical space they were working in.

[00:10:24] They also had this tendency to want to hire visual designers, which is great, we want the products to look awesome, but we know we're also in IT with a very highly complicated system. What we recognized was, as a team we got together at least once a week and we identified the direction that the platform is moving in, just being at a high level and working with the architects and all the high-level stakeholders. There were certain areas where we needed to learn to balance as a team: where do we put our emphasis on visual design, and where do we put our emphasis on the interaction design and the behavioral side of the user experience?

[00:11:06] I think that was good in helping the team balance. Am I spending too much time here doing visual design? Because it might look great, but I completely missed the point when it comes to the behavior and the desired goal that we're designing towards. As a team, when we began to see that, I may be a jack of all trades in that moment as a designer, but I needed to figure out where I really should be digging in. Maybe I don't understand this space well enough and I need to do some research and get a better understanding of the problem space before I spend all this time doing visual design. Because I've seen it on the flip side, where you might have a visual designer and they do this beautiful design, but you're completely missing the mark on the understanding of the problem.

[00:11:46] That's where having those exercises and continually bringing the team back into that awareness of the space that they're working in helps: when do they need to pull the right levers and press the right buttons to balance out their workload? Over time we began to see where people's strengths and weaknesses were, and people began to realize, "I'm not as strong in this area, so this is something that I want to work on," or vice versa, "I'm really strong in this area." Someone actually realized, "I really like doing the research side of things." I think that helped the team recognize, not just as an individual but as a group, because sometimes other people see strengths or weaknesses that we didn't even know we had.

[00:12:26] Catherine: Yeah, I like that. Teresa, did you have anything to comment? I have another question for you otherwise.

[00:12:31] Teresa: Sure. No, that was really great. The only thing to add to that would be, I really feel when hiring the team, when you have those missing skill sets, sometimes you look for those gray areas and see who can grow into them with additional training opportunities and learning. We take a similar approach with that, and look for additional training opportunities. Then ultimately, if it's not there, making the case for growing the team a bit more, with a front-end developer or, to your point, an interaction designer that could have a more focused area for that.

Motivation and tying the team to the mission

[00:13:07] Catherine: That's great, that's really good. I wanted to move the conversation to motivation, because often motivation in a team environment is the biggest driver for success over anything else. Teresa, I'll start with you, because you shaped your talk around the sprints. How else do you ensure the team is motivated and that they're heading in an aligned direction?

[00:13:37] Teresa: Sure. I really think in today's age, where you have a lot of attrition and a lot of remote and virtual work, tying employees back to the company mission and strategy is really important. That's really what I've done with my team, and what we have tried to do as an org to combat attrition. With our company mission we've set our strategy for the next several years, and what I've done with the team, both product, UX and design, is tie the mission to individual product roadmaps that then tie back to the company vision. So that's one way.

[00:14:14] The other way, still being remote: I'm really big on team building. Before the pandemic I was known for bringing in surprise improv folks to do little events, and I've tried to keep that same mentality with team building, little events together, whether it's that or maybe going out for some coffee or some drinks on a quarterly basis.

[00:14:39] Catherine: Coffee and drinks, it can be as simple as that. Scott, how about you? What do you do for motivation?

[00:14:48] Scott: I think vision is a really big one, and certainly team-building exercises are always good. What I have found personally is that people who want to be creative generally aren't really given permission to. You're in this box. I'll take a front-end engineer, for example. Front-end engineers especially are rock stars. They want to solve problems, and they have better ideas than I do on how to solve the problem, because they understand the technology better than I do. But they're not really given permission. Typically they may be doing middle-tier engineering or even some of the back-end engineering, but really their passion is on the front end.

[00:15:34] When I identify those things in people, I want to try to find them opportunities to step out of their lane and give them room to begin to think. I have found that really inspires people, not only to want to be more creative and be involved in that creative process and solutioning and understanding the problem space, just digging deeper: "I'm not just building a widget and shipping it. I'm actually solving a problem, and I believe in the mission of what we're working towards." I've found that to be extremely powerful for people, and it has been a huge motivator that I've seen in people.

[00:16:11] Not only that, but the more that I see people given the freedom to do that, they will often come to me with solutions that I had never even thought about before. There have been many instances where an engineer might come to me and say, "Hey, I was remembering that research that we looked at, the video we watched of a certain customer, and I was looking into this defect that came up, and I think we should solve it this way." It had never dawned on me. But had you not given the person the space to actually think and to step outside of their lane a little bit, you probably never would have had it.

[00:16:45] Again, it's one of those soul-crushing experiences. I used to joke about this with a co-worker: you're taking this really creative person who has a tremendous amount of passion for solving problems, and then you put them in this rigid structure and you just squeeze the creativity right out of them. It's sad to see that.

Changing the culture from the bottom up

[00:17:04] Catherine: Yeah. And at a management level, what can people do, and likewise at the individual level, what can people do to change that if they feel like they're being squeezed and not given the freedom and flexibility?

[00:17:21] Scott: I want to preface anything that I say with: I'm not that higher-level person. I can contribute to the culture, but usually the culture should start at the top and should permeate, and then you can have these microcultures within the bigger culture. I hear a lot of companies talk about how we need to be more collaborative, and as I think Jovi started out here, we should collaborate because that's how teams are more successful. I think a lot of companies say that, but then they forget that it's not actually happening. So I think it needs to start at the bottom.

[00:18:01] Yes, it has to be supported at the top, but I think it needs to happen at the bottom, organically, with people just organizing. I'm not talking about protests, I'm not talking about any of that. People need to recognize there is a ton of value here, and they need to circulate that to management. And if management really believes that, then they should find opportunities to put that into practice.

[00:18:27] I can certainly be a contributor to that. We're working on a product, or a feature, right now which is pretty big, probably multi-year, and I'm pulling in as many people as I can from all different kinds of departments. It's not because management says whether I should or I shouldn't; I just know that that's the right thing to do. And I'm doing that through the partnership of all these various stakeholders, so that they all have a say. It may be said at the top, but it's not the top coming down and saying, "Thou shalt partner and be more lean." It has to be something that we contribute to individually, not just come down from on high.

Engaging a seasoned expert in new ways of working

[00:19:07] Catherine: Yeah, find opportunities and be accountable, I guess, for your own direction as well. I have a question here from a member of the audience: how can you engage a seasoned expert, a rock star, who can't accept the new work models, for example an agile process?

[00:19:26] Scott: Is that a question for me?

[00:19:28] Catherine: Actually, sorry, I'll give that to Teresa. I have that in my hand for Teresa. Sorry, Scott, give you a break.

[00:19:34] Teresa: Sure. That's a really great question. I think we've all definitely had or have rock stars on the team that started all the way back with waterfall, but not even just with that: just any process, whether it's agile, lean or any adaptation. That's a really solid question, and I think it really does tie back to the engagement. If there's an issue with the processes, make sure that there's something tying them to the vision and strategy, how they're a part of it and what really drives them and their passion.

[00:20:08] I've had similar instances of this where I got them involved in hackathons and additional client meetings, and, even though they weren't really wanting to be a people leader, learning more about leadership and different opportunities. So there are different ways to supplement. Ultimately you're not going to be able to change them unless you're able to change the process as a whole and have them provide that feedback and grow with them. You want to provide those additional opportunities to supplement while you work on that adaptation of the process, to get them to feel more comfortable.

[00:20:43] Without too much context on this person's question, I always find with a rock star, or a seasoned person that's been in the company maybe a long time, it might be that that individual is almost afraid of change, and I think that can be a problem too. They've been known as that expert, that rock star, so you need to be very vulnerable to let that go. So it's almost a mindset, in my opinion, and changing that by showing the positives of actually not knowing everything, and getting them on board from that end.

Team structure, co-location and ratios

[00:21:18] Catherine: Really great. Scott, I wanted to go back to what you mentioned on the physical space creating a barrier between teams, and this is more bringing Teresa into this conversation. If you recall, Teresa, Scott just mentioned that he physically sat in different teams because there was a barrier between them, and it worked better. Teresa, do you find that, in terms of team structure, people that work together physically in the same space, and that are traditionally on different teams, will work better, or does it make a difference?

[00:22:00] Teresa: Yeah, that's really great. Again, this has really just changed and adapted for us during the pandemic, going from being in a physical space to remote. But before the pandemic we actually co-located all of our engineers, product, design and UX in different space areas. It was a large space, but we co-located the teams together with all the groups, and they were one team, one mesh team. We've tried a couple of different processes for how we replicate that while remote. We'll have either Slack or Teams channels where everyone sits on there all day. We've tried little tiger rooms where, maybe if there's a really big project, everyone's just live on their video camera all day.

[00:22:48] I really think, in order to build up that type of mesh team, you do need that cross-collaboration, to get everyone to become a little closer. Otherwise you could have some conflict if you're not able to develop that close relationship.

[00:23:05] Catherine: Okay. And Scott, is there an ideal team makeup from your perspective? Is it similar in terms of the relationships?

[00:23:14] Scott: I think relationships are a big part of it. But fundamentally, when I think about agile, and don't quote me on this structure, I think you have to have a certain number of engineers, a certain number of QA. I don't remember what the exact number is, five to seven?

[00:23:30] Catherine: Yeah, something like that.

[00:23:31] Scott: Right. And then ideally you'd have one designer and/or some researcher. Pretty much every company I've worked at always starts with the engineering agile structure, and then they sprinkle on UX where it's appropriate, where they have resources. They may be shared resources. But I think that would be ideal: at least one designer and one researcher. There have been cases where we've had projects that were just so big that we had to stagger the research, because there was a lot of discovery needed in the beginning, so they might have paired together. As we went forward, maybe there were two different designers working together; it might have been a visual designer and more of a strategic thinker bringing their minds together. But I think there is an ideal structure of having at least one designer per team, and typically researchers could probably be shared, depending on the volume of work.

[00:24:33] Catherine: Do you currently have one designer and one UX researcher dedicated per engineering team?

[00:24:39] Scott: Right now we're structured by what I'll call pillars. We have assessment products, we have practice products, and then we have platform. I'm primarily on platform. We do have a number of designers that are dedicated to each of those pillars, and we have researchers that are dedicated to those pillars as well. There's still some question: my manager, Jonathan Mann, is the vice president of UX, and he's looking at whether that's an effective structure or not, or maybe he wants to mix it up a little bit, but I'm not going to speak for him.

[00:25:12] I think it's been working well for us, where teams can really dig into an assessment space or a practice space or just focus on the platform without getting interrupted. If you're working on a wide variety of products in a suite and you're constantly switching tasks, it's really hard to dig into a problem space and really get to know it.

[00:25:33] Teresa: I would love a dedicated designer and research team. We have a large engineering team, so we're on more of a two-to-one or three-to-one model for that. It really depends on how much flow of work you have coming in. But no, that's really great, I would definitely enjoy that.

[00:25:51] Scott: Yeah, that's where we are too: one designer to a couple of teams. Me being on platform, I'm dedicated to maybe four teams, but most of them, because this is platform, are doing a lot of the back-end work, so my focus is largely on the teams that are doing front-end work.

Q&A

[00:26:08] Catherine: Awesome, great. We've had a lot of questions, in fact too many now, and we are running out of time. I have a comment here: the managers and staff don't support fixing those issues. And the other question here is: when you're hired as a UX for a web app, and the accessibility evaluation shows a million errors, and when they show the report to the manager, they decide to kick you off the UX. Sounds like somebody is quite frustrated there. Has anyone a comment on that? You're shaking your head, Scott.

[00:26:51] Scott: I'm just thinking, ouch, because you're just the bringer of bad news. But that is the reality: "Hey look, we did an analysis." At Renaissance, over the past couple of years, we have a senior accessibility professional who came on our UX team just last year. She's doing a fantastic job, and the company is really taking it to heart. If we really believe in improving and accelerating learning for everyone, literally everyone, we cannot discount that. The company's really taken that to heart over the past couple of years.

[00:27:26] And now when we bring those sorts of reports to the teams, they're like, "Okay, we need to do something. We need to address this. We can't keep kicking that can down the road." At other companies that I worked for, that is something they kept kicking down the road. Now, I say that being aware that it's one thing to kick that can down the road versus kicking the person down the road because you don't like the message that they're giving.

[00:27:52] Catherine: Yes. You always have to take the individual out of it and assume good faith. And Laurie asked: how have inclusive design and accessibility fit into your team and process? We're running out of time, so if you could answer that very quickly. Teresa, you first.

[00:28:12] Teresa: Sure. In terms of how it fits into the team and process, we've actually been building up our UX and design team over the years. When we first had the team several years ago, a lot of the product managers were doing low-fidelity designs in Balsamiq and so forth. So depending on how far along your organization is in the journey, it really depends how accessibility fits into the greater organization for product and technology. Now we were basically able to build up the need and use cases for those teams.

[00:28:47] In our research team we have a head of UX at TreviPay that performs about 20 to 30 research projects a year that we do on use cases and studies involving designers and product and our clients and users. We also have an international design hub in Australia as well as in the US, in a couple of states. So in terms of inclusive design, you grow with it on your journey with your product and solutions. As you continue to expand those and get more clients and gain that traction, you grow the team with it and fit that demand. Next up for us is maybe getting more front-end developers, of which we only have a handful right now.

[00:29:33] Catherine: Perfect. I have to cut this short. It was absolutely amazing to talk to you both. You are legends, is all I can say, and thank you very much for an enlightening session and Q&A. Thank you all, and I'll hand it back over to Jovi.

[00:29:50] Scott: Thank you.