Activating engineers during
discovery & design

Full transcript

Intro

Lauren: And I think there's a special relationship between design and engineering. We're all problem solvers, we're all trying to take what's being asked of us and turn it into something finalized and coordinated and singular. So if everybody is coming from that lens, and designers in particular, with a lot of skills to facilitate and to coordinate, I think it just becomes a much stronger team in a more collaborative environment.

Jay: I spent the first big chunk of my career as a software developer. And as I shifted into product management, that gave me the perspective and understanding of what's important to an engineer, especially when joining group conversations around the design and experience of products and services that they're being asked to create.

Over these last few years of my career, working in the innovation space, I realized how important the ideas that engineers have, but how difficult it can be, to get their voices as part of the conversation.

Well, Lauren Von Dehsen is joining us today. She's been a design leader working across Nest, inside Google, and most recently at SoFi. She's coming on today, to not only talk about activating and empowering engineers within workshops and sprints, but she's bringing the added twist of managing multiple rungs of engineers within hardware teams, where the timelines and constraints are often even tighter than your average software team. Let's check it out.

Today’s episode

Jay: Hey Lauren, how are you?

Lauren: Good! How are you?

Jay: Doing great. Lauren, you and I have this topic that we're going to dig into today, about design and working with engineers. And I was thinking about it, I was a former software engineer, then I became a product manager, and people are surprised by that, because most of the time I'm spending it with groups of researchers and designers, I'm talking about design thinking and human-centered design.

I'm excited because today you're gonna come and talk about, not only working with one wiry engineer in a group, in a workshop, in a sprint, but multiple. And on top of it, you're going to talk about the really tough constraint of managing and shaping design with engineers in a tight timeline within hardware, of building hardware products. Which, I imagine is very different than building software products.

Lauren: Definitely I'm also very excited to talk about this. Currently I'm a Design Director at SoFi, which is in the FinTech space, so actually not a hardware company. Very much a software-focused, product and experience-based company. But prior to that, I came from Google, where most of my time was spent with the Nest team. And I came to Nest from working on Nike+ FuelBand and the Nike+ suite of products.

So my love is really seeing these experiences come to life and things that people use, not just by way of their phone, but by way of their daily life, in environments, on the go, in these different situations that I think become very important to how we decide what we're gonna make and how we're gonna make it. And that's true of software products too. I think it just gets more pronounced when you're dealing with a hardware product.

The difference is that software is perceived to be very malleable and very changeable at any given point, right? That the teams can generally, many ideas, they can go back and revisit. They can try something and then they can change their minds. In the case of hardware, you're stuck with what you put into the physical world. You're stuck with the parts and pieces. You can't go make an update to something that's sitting on somebody's wall. Of course you can make another generation, and you're always going to constantly improve and learn from what was done, and embrace new technology that's available. But you're still having to maintain that piece that somebody bought a couple of years ago.

Jay: Yeah. So how does that change the conversation, in terms of bringing design and iteration into a group of engineers that are tasked with building a physical device like that?

Lauren: What I've found & what always kind of shocks people, is that if I counted correctly, we were working with at least seven different engineering disciplines at any given time. And this is everything from the physical, the engineers dealing with the physical realities of the product, from the electrical engineering and the body and shape and componentry of the product. There's a physical interface on products that is part of the interface decisions, the buttons, the turnwheel of the Nest thermostat, for example. And so those are being handled by engineers that aren't thinking about software on a day-to-day basis. And then you get into, because of you're dealing with both a device and an app, you have the application on both ends. And then of course the networking and the cloud in between.

So there's all of these different expertise coming to the table, and everybody is trying to make the best decision for their piece of the puzzle. But of course, some of those best decisions are in conflict with each other. The right thing to do from a software perspective may be the wrong thing to do from a physical perspective. So, you never get it right the first time, and I think when you're working with a new group of people, there's all of those kind of communication challenges. But as you go through a couple cycles, you really start to learn the sequence of decision-making, the order of operations that need to happen, and you also learn where to make an educated guess.

Jay: So how did you get those engineers to take steps forward and trust the design process and bridge the gap with your design language, and the things that they talk about and care about?

Lauren: I think what you find is that everybody is playing a bit of an architect role. And I personally find this really fascinating, 'cause I don't know if all designers think of themselves as architects. That doesn't mean they're the only architect, by any means. What is really important, is everybody brings a view of their world to the table as they have it.

As a designer, I felt like one of the things that was not necessarily my responsibility by job description, but was very helpful, is to create areas of conversations, forums, discussions, where I and the team, we're bringing that information in, but we were doing it in a way that all of the seats were filled, as opposed to what people think of as often being the most efficient, is going to the software engineers with the software plans, and going to the hardware engineers with the hardware plans, and never the two shall cross. Well, no, that doesn't help, because everybody is influencing each other, and so you have to have places where you take the hit of an expensive meeting, but you have so much more clarity and alignment because everybody is seeing the ultimate picture of what they're contributing to.

Jay: So you, in a sense, took on that role of facilitator and shaper of conversations.

Lauren: I think in a very design-oriented company that tends to happen. Now, that doesn't mean that the product manager isn't playing that role also. I think the misnomer is that it's enough to have one person playing that role. And in reality, you need multiple people playing that role, because everybody is looking at it from a different perspective. And I think there's a special relationship between design and engineering in that we're all problem solvers. We're all trying to take what's being asked of us, and turn it into something finalized and coordinated and singular. And so if everybody is coming from that lens, and designers in particular, with a lot of skills to facilitate and to coordinate, I think it just becomes a much stronger team in a more collaborative environment.

Jay: That's a really interesting dynamic. I'm seeing this almost like a shape of what you seem to have done here. It's like you managed to bring the team together, in order to break down all those one-off, sidebar, siloed meetings, but then you also opened it back up to make design and the conversation itself owned by everyone. Which is, really, it seems like it would be really empowering and cohesive.

Lauren: Well, that's the love-hate relationship I think many of us have with the title "UX", and I'm sorry if I offend anybody in the community, but the user experience of a product, of something that a company is putting out, is impacted by everybody. The experience goes all the way down to who's answering the phone call when you have an issue and you're calling support. It's not owned by a single team. And to think that the single team is going to be able to control it and make all the decisions on their own is a little bit crazy.

So it becomes more of an ethos that the design team is championing, and is uniquely positioned to be focused on. I think the designers are the ones coming to the table, helping everybody refocus on the ultimate goal, the ultimate thing we're trying to do, but everybody's decisions are contributing to that user experience.

Jay: Well, I'm sure you didn't figure this out and knock it out of the park on your first try, when you were just getting started with design. So for the person that's being, kind of like looked at to bring a group together, whether it's seven types of engineers, or just these cross-functional groups that we have, what would be your one golden nugget for them to think about?

Lauren: I think in terms of specifically communicating, let's say you've gotten everybody into the room, but everybody is speaking a different language and you can't quite get the conversation on the same page, it's really important to ask questions and double back. But what you'll find is that if you ask questions multiple times in different ways, or if you ask, "Did I just make sense?" Or, "Did you understand what I'm saying?" "Is that clear?", you'll start to elicit more, people will actually answer. If you say, "Does that make sense?" People will actually say, "Well, actually, no, I don't understand." It's an amazing phenomenon that you wouldn't think people would give that up. But given the opportunity to explicitly say, did it make sense or not, they will tell you.

And so you start to see these cues of when people are just agreeing to agree, versus when people are agreeing because they've really processed the same information and they're on the same page. If you can crack those fundamentals of communication and teamwork, then the next iteration is going to go that much better. And that's ultimately what you're trying to do. You're trying to learn and iterate as a team, not just on the product, but on how you work. So you'll get there.

Jay: Yeah. Learning to ask questions, super. But you also, what I got out of your phrasing of it, was some humility to it, which I think is much more inviting than, sometimes people are scared of being asked a question, 'cause they feel intimidated. Like, "Am I not smart?" "Do I not belong here?" But the way that you phrased it is really, I think, humble. It's, "Am I hearing it right?" Did I get this right? Does this make sense?"

Lauren: Yeah, I like that insight, I didn't even realize I was saying it that way, but yes, and there's a fine point, particularly for women, when you're saying this type of thing, you don't want to say it to the point where you're self-deprecating yourself, right? In that, "Well, I'm not sure I understood." But there is a humility amongst team members, where you all have to be willing to have gotten something wrong.

And so I think there's that kind of sweet spot, where you leave openings for other people, and you clarify without just assuming that the way you've dictated it to the world made sense to everybody and we can move on. You have to leave that room for the other person to get on the same page with you.

Jay: This has been great, Lauren. Thank you. Thank you for coming on and sharing all these good things, especially for the engineers that feel confused and want to be part of the discussions upfront. There's certainly an invitation and we definitely need your good ideas. So, thanks to Lauren for sharing these ideas.

Lauren: Thanks so much, Jay.

Jay: Thanks, Lauren. Lauren: It's been great chatting.

Jay: Thank you.

Join the conversation

Jump in here (link coming soon) to share your ideas and ask related questions.

< Watch Episode 22 Watch Episode 24 >