Q&A With Scott Himmer

Scott Himmer at UXDX Community: USA East. Video: https://youtu.be/8whKczGDizU

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.

Making time to look ahead

[00:00:00] Host: Hello, how are you today?

[00:00:02] Scott: Great. Your talk has given me a little bit of heart palpitations when I visualize how to change a tire on a moving car. We're not technically doing that, but I think there's something to be said about it: the train, or whatever the vehicle is, has to keep moving. How can we instrument change amidst that motion? Because certainly the ship can't stop moving.

[00:00:28] Host: Yeah, it's a really good point. I wanted to start off by asking you about a challenge people often raise, which is that they have no time to look ahead. They're always focused on the current deadline. How do you carve out that time to look ahead?

[00:00:48] Scott: I rely a lot on my product management partners, who are typically always looking ahead, unlike the engineering teams that don't have breathing room to look ahead. Generally, when I start looking ahead with product management, doing future envisioning, I tend to pull in people who are stuck in the now but who are really creative thinkers. They have different views on things, so I like to bring them into that picture and have them work with us to imagine what that future might be. You find that when people have a little bit of breathing room, they can actually allow those creative juices to flow. Otherwise they get stuck in the here and now and never really get ahead.

[00:01:33] From a creative standpoint, when you get stuck that way, you get caught in this mode of thinking, and it's hard to get out of it. That's why they have these lateral thinking exercises. I think those are good opportunities to draw people into that space: give them opportunities and room to be creative, give them space to actually think ahead.

[00:01:54] Host: Yeah, it's a very good point, thank you. In your talk you gave some examples of opportunities arising. How do you keep up to date with all of that work happening all the time with teams?

[00:02:10] Scott: Across engineering teams, that's tough. I go to several sprint exits, because there are multiple teams delivering, just to see what the latest things are that they're working on. And usually when we're planning ahead, as I mentioned in the talk, working with the director of platform at Renaissance, we created a radar, which allows us to look ahead, think about the things that we're looking towards, and prioritize those things.

[00:02:42] At the same time, I have to see what we're delivering now. I think there's a level of persistence: we're looking ahead, and we have to see the things going on around us to work towards connecting the dots. I would say the director of product is really good at saying, "Oh hey, this team is working on this thing. This could be a springboard towards this other thing that we've been thinking about." So I'll start reaching out to people and connecting the dots. It's a very collaborative effort that way, but I think the key is always just being persistent and being aware.

Convincing teams to take on extra work

[00:03:16] Host: Great. Teams are often wary of "it's just a little change," the comments they get asked to act on that expose complexity. How do you convince teams to take on board what they would see as extra work?

[00:03:38] Scott: One is that I try to make it as clear and concise as possible, so that they don't get too worried about the scope of what this change might mean. I think that's the most critical step, because the more complicated and the more ambiguous it is, the more resistance you're going to get. Plus, I do try to tie in data that we know about, whether that's input from the sales team or input from support tickets that are coming in, recognizing that this little thing, even though it seems so insignificant, could cover a lot of support cases that we've been getting in the past, as well as head off some of those support issues in the future. Another way is just leaning into that team and again collaborating with them: "Hey, we're thinking about making this change. Talk to me a little bit about this area that you all are working in, so we can figure out how we can slice this and fit this kind of work in."

[00:04:36] Host: Great, I love that. I have a question here from Rory: how do you schedule time with the team you've built? They've said they've worked in a place where every meeting needed a charge code. When you're getting to that level of bureaucracy, how do you schedule time with that team?

[00:04:58] Scott: Yeah, that would be tough, I guess. The closest I've come to that is at Delta Air Lines, where there were many, many teams working on this giant initiative. I wasn't directly involved in the product management side of it, but I would assume they all had charge codes, because it all had a roll-up to finance. We did still find ways. The team that I worked on was called a base team, and they were essentially a team focused on the core of what we were building out. That accelerated and fed all the other teams that were doing the specific product features that were going to be needed for the platform, while we were working on the core.

[00:05:43] But even when we were working on the core, and I think I mentioned this in my talk, we knew what needed to be done, but some of that stuff wasn't on the roadmap yet, because they were still trying to prioritize it. We knew what needed to be done as a team, so we found ways to get together, think about the things we knew were going to be needed even though they weren't prioritized yet, and slowly start chipping away at those things. We got pretty creative at it. But I think there is this tendency in a culture to be top-down and feel like you control that, even though there's a ton of risk in doing it that way. You really have to find ways to empower your teams to think outside the box and yet still work within that structure. I think that's easier said for some companies than others, though.

Advice for getting started

[00:06:33] Host: Absolutely. I'm going to hold off on a few questions I have for you on empowering high-performance teams; we'll talk about that on the panel. Around this, from your talk: is there any advice for a team looking to get started?

[00:06:50] Scott: I guess it might be a question of how I would define a team. To do what I was pitching, and I'll reference it from the platform radar, there needs to be someone who's thinking ahead, and it definitely needs to be cross-functional. Even as a designer, we have to keep the vehicle moving, so there are certain features that I have to work on, while there's someone else who's always looking ahead, and we're feeding information back to one another. In fact, it's great that they can say, "Hey, this thing is going to be upon us soon and we need to start thinking about it." "Okay, go figure it out." "I'll start digging into it and I'll report back." It's very collaborative that way. But then we might also find, oh, that person has a piece of the puzzle, and that person has a piece of the puzzle, and I may just find five minutes here and there.

[00:07:40] Yes, there's work that I have to do. But if we're really claiming that we're agile, there's a percentage which is now and there's a percentage which is future, and if we're not thinking about the future, we're not really doing agile, because we're not really empowering teams to think ahead. So I would say get someone who's a visionary. But you have to be persistent in that and always be looking ahead, and you also have to be open to collaborating with people. I would say it's not a team that is defined by a cultural norm. It's a group of individuals, call them guerrilla tacticians [?] or mercenaries if you want, who want to solve problems and be creative about how they solve them. They might not actually do the work, but they have answers to some of the puzzles that we're going to have to work through. I don't think I have any silver bullet other than finding people who want to collaborate and who are willing to be lean in that process, to always look ahead and start chipping away at that bigger picture.

[00:08:43] Host: Yeah, I like it. You kind of work in tandem, and it's personality as well. It will be a little messy sometimes.

[00:08:51] Scott: Yeah. The idea that product teams work in this beautiful, perfect environment is a dream, I guess. There isn't a product team out there, Spotify or whoever it is, that I know of that isn't striving. If you're too perfect, you're almost not doing enough, maybe.

Building relationships with developers

[00:09:15] Host: Annie has a question here from the audience: any tips on developing a healthy relationship with developers as a designer?

[00:09:22] Scott: That's a very good question. I'll say one thing that has worked for me. The question is healthy relationships with developers as a designer. I'm the kind of person who wants to live what I believe, so I'm going to eat my own dog food. If I have to work in collaboration with developer teams, even teams that I'm just placed into and I've never met this group of people before, that could be tough sometimes. There's this whole new dynamic. What I used to do was shy away from it, and I learned that that's not successful. So that would be a tip: don't shy away from people that you may find resistance with, but lean into them.

[00:10:10] Some of the ways I have found are just learning about the technology. If there's a constraint that they're facing, "Well, tell me about that constraint." Certainly it might be over my head when you start talking about really deep APIs and database querying, but I need to be curious to know what makes them tick, what they are passionate about, what their strengths are. Because I might find, and I have found, that there are really great partnerships with these people, and that actually this is a very creative person who just needs to be pulled out into that creative space. So I, as a designer, need to lean into those people.

[00:10:44] Another way I've done it is that I actually go sit with the team. I was at a company where we were on two different levels: product management and design were on the second floor, and the engineering team was all down on a lower floor, and just that physical space created a barrier to collaboration. When I started recognizing that, and the more I leaned into the team to understand what they do and their strengths and weaknesses, I actually decided I was going to sit with them. I asked if they could set up a desk next to them, and I made a commitment. I needed to work with the product management team, but when they were working on UI-heavy sprints, I made a point of sitting there at least three days a week and having conversations with these people, just physically putting myself in their midst and learning from them. That's also a way that they can learn from me, and it has spawned a lot of great partnerships.

[00:11:40] Host: Yeah, I love that. I'm going to follow up, because I'd like to get Theresa's thoughts on physical space. I think that's an interesting one, so I'm going to hold off on any comments on that. But overall I think it's a really good question around designers and developers and the relationship there, and a lot of people have a lot of cliches there.