Episode description

The O’Reilly Design Podcast: Collaborating with engineering, hiring for humility, and the code debate.

In this week’s Design Podcast, I sit down with Randy Hunt, VP of design at Etsy. We talk about the culture at Etsy, why it’s important to understand the materials you are designing with, and why humility is your most important skill.

Here are some highlights from our conversation:

This is a hilarious debate at this point, in my mind. ... I could very confidently get on one side of it with a lot of arguments that I think are quite valid, but you can look at other products, at other organizations, other teams that don't work that way and are also making great products or experiences. It's not like there's one way.

The sentiment in it, though, is that deeply understanding how things are put together, how they function, and why they work, makes you better at making them. I really believe that. I think this is true from a business standpoint. I think that you can stretch this metaphor to a CEO of an organization.

It's like understanding how bricks can reveal to you the potential that you could take one of those bricks and turn it 90 degrees and create a design element out of the thing that sticks out of the wall a little bit. If you don't understand how that modular system goes together, you may not see the opportunity in how to manipulate the medium. I don't buy the argument that a pursuit of understanding technical implementation is somehow in contrast with or precludes the ability to think about things conceptually or otherwise. I think there's a dichotomy of, ‘Oh, the designer who codes is somehow not user centered.’

One side is about implementation and production, and understanding how things are built; the other is understanding why and for whom you would build those things. These are complementary sets of knowledge. This is an externalization of my own internal experience. I feel like I've been a better designer for this reason. ... I think it is an indication of other personality traits that are also good for designers to have. There is a degree of self-education, really. I think these things are basically learned by doing. You have to. You repeatedly fail when you try to build software, essentially, until you don't fail. It’s a commitment to gaining knowledge over a long period of time, a really applied effort—an ability to switch between sort of procedural logic in a way, A-B choices and understanding things like that, and what something looks or feels like more emotionally. I think that kind of well-roundedness is an indication of success in the kinds of experiences we're trying to create.

When we're talking about how design and engineering work together at Etsy, the connection point for us is product design and engineering. A culture of change, being comfortable with change and adaptability, is one key factor. The other is a spirit of collaboration and openness. This happens a lot in engineering cultures anyway. It's very much like the DNA of the open source movement or something. The sense of the generous giving and sharing of learnings and things like that is shared across these cultures as well. So, because both those teams or functions have some common cultural themes, there's this natural bridge that helps them work together kind of in spirit. Then how does it actually work in practice? Well, as we built that product design capacity, we initially oriented toward a heavy focus on the designers delivering the pixel to the screen. Designers were executing front-end code, a part of the testing and deployment process that engineers were using. I mean, right down to designers using our deployment tools we've developed in our continuous deployment process, and chatting in the same chat channels with engineers, queuing up their changes to go out to the production servers to be live on Etsy.

We really embedded designers in the same delivery workflows, which forced them to develop a shared vocabulary, use the same tools, appreciate the same constraints and lack of constraints in those cultures. You have the shared culture, then you have shared language, right? That helps them work well together. That continues to be true. Many of our product designers continue to work that way.

The third part, I would say, is how the design and engineering teams are structured—like where the sense of team alignment is or team identity. They're effectively structured the same way. An engineer and a designer would as much self-identify as being part of the core seller platform team as they would being part of the design or engineering team, if that make sense. The logical chunks of the business or user experience that designers and engineers are assigned to—they're part of cross-functional teams that have an identity and an area of focus. They sit together. They fail and succeed together. It's in those relationships that a lot of the details of, ‘How does design and engineering work together?’ get answered. One of those groups may be much more, sort of, ‘We do these two week sprints, and we structure things this way,’ and there are designers and engineers together in that process. Another team may work a little different, but there's the designers and engineers together in that process. They have a lot of affinity, I'd say, for those kind of business teams in a way that they're a part of. I think that brings them together around shared goals, around shared user needs, around shared impact on the business.

I would say the biggest thing culturally—and it's funny because this feels to me like it trumps anything else—is really humility. In the nature of how customer-centric we need to be and how collaborative we need to be, and often how little we know until we've tried some things and learned them, I find that humility is a strong indicator of success in our culture. It can be easy, I think, to interpret that in some kind of soft way, but I actually see it as quite the opposite. It's a strong attribute to be comfortable with things like patience, and to be one of many voices in the room, not the voice in the room, and to operate in a way that is primarily listening mode for a long time before you go into answering mode. That tends to work well culturally for us, and I believe it tends to work well for creating great experiences at the end of the day as well. The nature of how we work is very, very much like a team sport. So we're looking for those kinds of characteristics.

The nature of the roles I'm interviewing for and the people I'm hiring personally, versus what other leaders on the team are hiring for, has changed. I like asking people to teach me something I don't know. Like, "Okay, you've got 10 minutes. Teach me something I don't know." In that question, and in those constraints, I think are a lot of interesting things. One, it gives them the opportunity to introduce a topic that may or may not have anything to do with the job or the role they're interviewing for, or our company, or our domain of things. You learn a little bit in how they respond to that. Do they try to position it as being about the business or the role? Which is fine. You get to learn a little bit about their personality. Or do they pull something out of thin air that's probably some topic of interest to them or happened to be the thing they were thinking about that morning? Who knows what it is?

You learn a little bit about someone's personality, learn their ability to think quickly. You learn about their communication skills. How can they take this thing and process it quickly, and turn it back around and present it to someone else in a way that will help them understand? It's like this quick, on-your-feet thinking, communication skills, and knowledge transfer. It’s the "What things are you into?" question that I find both fun and illuminating. I also like the time constraint part of it to see how people deal with it. There's this other thing that only a few people have really tapped into, I think, but there's the opportunity to be inquisitive back.