Building bridges between engineering and product

“I don't think engineers have the most empathy for product managers”

Rafe Colburn, Chief Product and Technology Officer at Depop, joins the show to talk about his journey from a computer-loving kid to a seasoned engineering leader. We talked about the biggest lessons he learned from his time at Etsy, management by instinct, the interesting dynamics between product and engineering teams, and his biggest priorities right now at Depop.

Below is a transcript of this conversation, which has been edited for clarity and brevity. You can subscribe to PriorityZero on Spotify, Apple, Pocket Casts, and YouTube.

How did you get into engineering in the first place?

Rafe: I entered the industry around 1995 and I was a kid who loved computers, I think that was a common background in the very early era of the internet, where it was more of a hobby, less of a like profession. I'm definitely in that generation. Messing around with computers was what I did with all my free time anyway. It seemed logical to get a job there. I started with some QA tech writing, system administration, and just a bunch of different stuff.

I'd actually gone to college to study journalism. I had been the editor of the high school newspaper, and I was really into it, but when I started college, I thought I didn't want to be a journalist, mainly because I didn't want to interview people, so I switched to management information systems, which is what you choose if you're too lazy to take hard math classes.

1995 was an interesting time for the industry, how was that for you?

I used the internet a lot in college, but there was no web, really. We used IRC and other things. We were into FTP sites, if anyone remembers those. The Netscape browser came out just when I started my professional career, so I got into web stuff immediately. I had no way of knowing it was going to be this huge thing, but the company was eventually bought by Netscape. I didn't go work for Netscape, which honestly was a huge career mistake. Instead, I went to work for a web design firm, so I did that for a few years and gradually got more into the application development side of it.?

At the same time, my side hustle was writing computer books, which was not very lucrative, but I learned a lot because I would go home and learn subjects deeply after work. I won't say my work-life balance was particularly good, but it was really educational. I had worked mostly at consulting firms through 2000. Then, a company agreed to buy the startup I worked for...they then bought a Super Bowl ad, and then basically shut down and canceled the acquisition the next day. That was like a mortal blow to the company I worked for. It was a tough time economically.

What did you learn along the way?

You have to be willing to both discard and acquire skills in this job. You kind of had to pick up the skills you needed for the client. That said, deep skills were not demanded. I don't think the apps were very complex back then, and scalability was generally not an issue, but it was good training to acquire skills and figure out how to apply them to problems rather than developing some deep specialization.

I didn't really think too much about management. Back in the olden days, there wasn't really an IC track either – you're a consultant, or you're a senior consultant. I really was an IC for a long time before I became a manager. Probably the first 10 or 15 years of my career, and then I switched to management.

Did you eventually pursue that track, or did you get thrust into it?

After the first .com bust it was just hard to get a job. I certainly wasn't looking for management jobs; I would have taken any job that would pay my rent. I found a job. It was really, really boring, doing security code review for the US Postal Service, which was such a drag.

I did that for about six months, and in the meantime, a friend of mine was involved with a tiny startup that needed a Java developer, so I did that part-time and then got laid off from the post office – which was great – and joined the startup full-time. Then we hired a couple of other people, and I was kind of the tech lead. I had been the lead developer, I designed most of it – I hesitate to use the word architect – so when we brought other people on, there was some management-esque stuff there. I wasn't really in a hurry because the individual contributor work was really interesting. Then things changed at that company and I took another job that had some management responsibilities, but really because the work seemed interesting, so I was interested in the project. So, I found myself in management because this was the job opportunity that looked most interesting to me.

How jarring was the actual management aspect of it when you got there?

I mean, I was terrible at it, if I'm being honest. As you said, we really went through this transition with engineering management that I would put as a pre-Rands and post-Rands era. Maybe in Silicon Valley and in Seattle, there was a proper engineering management function, but in the rest of the country, we just had no idea what was even going on.

Can you explain pre- and post-Rands for people?

Yeah, absolutely. So there's this blog Rands in Repose. He eventually wrote a really famous book. He really laid out in real detail what people need from their managers, what engineers need from an engineering manager, and what the job really is. He explained it as a real craft, a job you can be good at. I think before that, it was like you're also an engineer, but you tell other people what to do. That was the approach I took to the job in my first couple of management roles.

There was a Cambrian explosion from that point. It was the great heyday of blogging. People really started writing about engineering management in these blogs, and there was such a hunger for it because the tech industry was growing again, and people were moving to these management roles and wondering what the actual job is.?

When I started in management, I just really struggled. The thing I struggled the most with was what should I do myself? What should I delegate to other people? How much guidance should I give people? Am I here to tell people what to do? So I feel bad as my early reports were my early human experiments. I tried things, some worked, some didn't. I was probably going by instinct, trying not to do what bosses who had annoyed me in the past did. It was a lot of trial and error and reading.

To be honest, unless you've done it for a while, it's hard to apply the literature. I see this all the time, where brand new managers are trying to follow the literature, but they look like someone who's following the literature rather than someone who has a feel for the job. I 100% was that person.

There's a spectrum there. You can either do it by the book or by instinct. I think a good manager probably wants a little bit of a mix of two.

I had a manager I really liked working with, but he wasn't an engineer; he was kind of the product leader and gave me full autonomy on the engineering front. He brought a really personable approach to that job that I appreciated and was a manager as a collaborator, rather than your boss, which I really liked.

You?mentioned autonomy and being a little bit more connected. Are those still things that you take as your management thesis?

1,000% on that. Generally speaking, I don't love being told what to do. I always tell people I can channel the inner staff engineer when I'm feeling skeptical. Even though I haven't been an IC engineer for a long time now. I take a much more coaching-oriented style. I often find myself saying: "You've probably already thought of this, but what if we tried that?" The truth of the matter is, 80% to 90% of the time, people have already thought about that, and so I'm not bringing them anything novel. I just want to make sure that the idea is getting a hearing.

I'd much rather have some kind of North Star, some kind of vision, some kind of goal we're aiming at, some way to measure it, and then give people lots of autonomy in terms of how they pursue that goal. Then, I'm a tool for them to achieve that goal. What do you need? I'll be happy to help.

My job's not to drag you there, you're going there already and bring me into it when you need to is always how I prefer it. Of course, performance management is real. Sometimes, people need a lot more help than that. Sometimes, you have to say, "These decisions are not that great to me, please explain them to me," or "Here's what I think you should do instead." But I see that as a last resort, rather than the opening way to go about it.

How have you adapted to those more uncomfortable parts of the job?

So much of it is practice. One of the classic examples that is so hard for new managers to deal with is people wanting to talk about their salary or getting promoted, but especially salary.?

For me, always, I do not want to talk about my salary with my boss, under any circumstances. I hate it. If I bring it up in a 1:1 and they could read my mind, they would know I've been mad about this for months. Early in my career, there were times when I wasn't sure I was being paid fairly, and I wouldn't talk about it, and when I eventually did, I was already frustrated.

A lot of management is projection, and I know I hate talking about this so I know they're [my report] probably already upset, and I don't really know what to say. Because I don't have the answers from HR anyway so I can't give you an amazing answer right now. ?

I know it's hard for people to talk about, so I eventually just got to the point where I would tell people, "If everyone on the team is talking to me about their salary once or twice per year, it means I talk about salary every week, so it's nothing to me, I'm happy to talk about it."

But you can only say that once you've talked about it with people dozens of times, it doesn't trigger you anymore, and you can have a rational conversation about it. A lot of that is just getting the practice of these things in and knowing it's hard for everybody at first.

Do you default to transparency there?

Absolutely. Also just knowing how people react to things. I did get into the good habit of if I can't really talk about it right now, I need to do some research, and bring it back up at our next 1:1 without feeling the pressure to give an answer right away. The flip side is that how people react at the moment is not the real way they react to any kind of feedback, whether it's they're not getting the raise they want, or they could be doing better. Even if they seem to be getting a little bit triggered at that moment, I try not to get triggered myself. Time helps in a lot of cases.

Patience helps as a manager. I think when you're early in your management career, you want to be able to fix every problem. You want to be able to solve everything and for everyone to be happy the whole time and you have to get a bit comfortable with the fact that it can't always be the case.

Of course, you want people to be happy, but it's probably biological that the experience of making someone unhappy is so stressful. When you're in management, it feels like you're always making somebody unhappy. "We're gonna prioritize" means one person's happy because their thing got prioritized, and one person's unhappy because theirs wasn't prioritized. Or "we're promoting this person" and that person is happy and probably at least one unhappy person.

I do my best every day, and I forgive myself every night. You have to make decisions, and I think it's a hard transition from an IC where, basically, you have tasks to do, and if you do them in a timely fashion, everybody's happy. That's what you've been asked to do. Management is kind of a trade-offs job. So there's always some unpleasantness to process.

Sometimes, I tell people that my real job is just to minimize aggregate disappointment.

How did you land at Etsy?

Of all the things I did in my career, it was probably the most significant. I wanted to get a job at a company I really wanted to work for. It's funny, I didn't actually know a whole lot about Etsy as a business, I don't know why they hired me in the first place, because they were really into people who were into Etsy.

But I knew some people from the engineering team, and at that time – around 2011 – Etsy was really at the forefront of continuous deployment, observability, so many tools that people just use today, whether it's LaunchDarkly or Datadog or some of these other things. Etsy was doing that in practice before anybody else. I was fascinated by that because my old company had a quarterly release cycle, and I wanted to push into production every day.

It just sounded like a lot of innovation was happening there, really on the "ways of working" front, almost more than the technology front. I took a job as an IC there, and they had very few engineering managers at the time.? I wasn't even sure I really wanted to be an engineering manager. I had done a couple of management roles and gone back and forth, but I really wanted to work at Etsy, and the IC role was the one that was available, so that's the one I took. I was there for 10 years and moved to Depop at the end of 2021.

What's the biggest thing you learned at Etsy?

We could do a whole podcast about that. But I think two things. One is I learned a lot about diversity when I started at Etsy. I think out of 100 people in engineering, there were two women out of the whole group, 2% and when I left, it was probably more than a third, maybe close to half, on the gender split. It was really interesting to see how the company evolved as it became more diverse. I think that was all positive.

There was a guy who was a VP of engineering there named Marc Hedlund who's a pretty famous person in the industry. He just made it his priority. Just setting that from the top and saying, like, we are going to be a more diverse engineering team. It just puts it in people's heads to try to make diversity a concern when you're hiring. There were no quotas or anything like that. The expectation was that if you brought in a series of non-diverse candidates, you were not doing your job well.

The biggest impact of that was it just diversified the communication styles across the team. When it's all guys that have come up the same way, you get a real monoculture of communication. Just having people who bring different communication styles, I think really opened things up. Also, you don't walk into a conversation with people and make tons of assumptions because there's a more diverse group. I know there are real studies, and people have lots of academic things to say about it, but I will say that I felt it very strongly. Diversity was just kind of an aspect of the business, and not something we constantly had to chip away at.

The other funny thing I learned from Etsy was that technology choices weren't as important as I thought they were. Etsy was so much about "can you do things fast, and does everyone do them in a consistent fashion?" We use some technology for it, but so many people would take a job at Etsy, and they'd come in and say the tech stack here is terrible. Then they became really productive engineers at Etsy on a terrible tech stack.? I wouldn't say, don't put any thought into it, but I think being really good at using the technology you use is vastly more important than choosing technology A over technology B.

What's your priority zero right now?

My priority zero right now is reaching for a higher level of execution across product and engineering. It's not because things are going poorly; things are going well. I spent my first year at Depop really learning the product part of the business and learning how to work with product managers every day, and not really engineers. I really tried to stay in my lane and not annoy the engineering team, because that wasn't my job. I think I finally have the headspace now to say, okay, how do we get the whole system really working well together? What do we need from each function? What can they be doing better? How can they better collaborate?

Focusing on that intersection between product and engineering?

That, and at the same time really taking a deeper dive into how we do things in engineering. We have this discussion in the industry around engineering productivity. People are talking about it everywhere. How do you measure it? And all these other things. It really is like the layers of an onion. I can give you a bunch of different ways to get to it, but at the end of the day, if you really want to know what's going on, you have to look at pull requests and see what people are really doing.

Where are you seeing the biggest friction points?

We do have some long-term things we need to address in engineering, whether they're about scalability or observability or some other things. Or migrations that go on for a long time. How do we balance that with our product priorities? The reward for doing well is greater expectations. It's just that prioritization that is a source of friction between product and engineering.?

The other thing that is really hard, and it's a little bit between product and engineering, a little bit between teams, is Depop has an Android app and an iOS app and a website, and we're not big enough, and it wouldn't be efficient to have backend engineers, iOS engineers, web engineers, and Android engineers on every team. There winds up being cross-team things. That inevitably leads to some inefficiency with people waiting getting a little frustrated.?

We didn't even talk about how you ended up becoming a product person.

This may be the weirdest part of the whole story. I had been working at Etsy for a really long time. I was a VP of Engineering and was managing three or four directors. Etsy had just acquired Depop, and they asked me and three other people to go and consult with Depop and figure out what they could learn from Etsy and how they could build things better. They were hiring a CPO, so they had a search on, and someone suggested that I would be a candidate for that job. I talked to their CEO, who has since left, and they were late in the recruiting cycle with another candidate who was a product person. The real product person dropped out four days before they were supposed to start, my boss calls me and asked if I wanted to take this job at Depop. It started as a six-month interim thing, and then it became permanent in April of 2022.

The funny thing about it is if a recruiter had pinged me about it, I would have never applied in a million years. I'm thankful to the Etsy executive team that they saw something that I probably wouldn't have picked for myself. I do appreciate that. It's been really fun.

Do you do that as a manager and leader too?

I've definitely asked many people to do things they're not sure about.

I think the tension between engineering and product can be a little bit overblown. Have you found that?

To some degree, I think that we come by that tension, honestly. I think there are two misunderstandings that drive it. One of them is that most product managers, unless they come from an engineering background, they don't really understand the field. It's a little bit like a person going to a mechanic when they don't know their car works, and you have to take their word for it.

Product managers feel a little bit like they're flying blind, even though they are accountable for delivering these outcomes, but the engineers are really the people who have the power to do it and write the code. So there's a big trust question there. Do you trust engineers to really focus on building the thing you need, or are they off playing with new technology or playing foosball? Because you don't know yourself, it's hard to really trust them.?

The other side of it is that I don't think engineers have the most empathy for product managers either sometimes too. They just tend to be very outcome-focused.

Actually, I've really loved working with product managers because they are so oriented toward value creation. You give them a goal, and you say, this goal is going to help the company succeed, and then they go try and find ways to achieve this goal. What they need is help from all the other supporting functions to choose the right way to achieve that goal. If they go on their own, they just don't know enough. They may not be a designer, they're not analysts, they're not engineers; they're not data scientists. How do you build that whole squad with the product manager responsible for prioritizing the outcomes that they have, the information they need, and the input they need to actually make good choices and understand what's really involved?

What needs to happen for this to no longer be your priority zero?

When teams have become more self-sufficient. If I really narrowed it down to one thing, it would be that we have way too many interdependencies and things that slow people down. Whether it's technology choices we need to make, or ways of working choices, or whatever else it is. When teams can really operate in a more self-sufficient fashion and go as fast as they can under their own power, we will be better off. That's kind of what I'm looking for.