Engineering Productivity & Culture at Netflix w/ Kathryn Koehler

**Dan** (0:03)
Hey, you're listening to Dev Interrupted, the podcast made for engineering leaders who want to continuously improve. From DVDs to streaming to movie production, Netflix and their engineering organization has been revolutionizing how we consume content for over two decades. But what is it like to work there as a developer? And how do they think about culture, their customers and engineering productivity?
In this incredible episode of Dev Interrupted, I bring in Kathryn Koehler, the Director of Productivity Engineering at Netflix, to chat about what makes Netflix so unique and why they are standardizing data-driven engineering today.

**SPEAKER_2** (0:46)
This episode is sponsored by LinearB. Give your dev team the power to improve with team-based metrics, high-risk code alerts, and the world's first project board based on real-time Git activity.
Sign up free at linearb.io.

**Dan** (1:00)
Kathryn, thank you so much for coming on the pod today.

**Kathryn Koehler** (1:04)
Dan, thank you so much for having me. I can't tell you how excited I am to be here and talk about one of my favorite topics, which is productivity.

**Dan** (1:13)
So you are the Director of Productivity Engineering at Netflix, which is just like a badass title to me. I love that.
I love that title. I don't think I've ever seen it at a company that I'm working for, but I have seen it becoming more and more popular. You got it at Netflix, maybe Spotify, GitLab, those types of companies. But could you just tell our audience, what does it mean to be the Director of Productivity Engineering and what are the problems you're trying to solve?

**Kathryn Koehler** (1:49)
Yeah, absolutely. Productivity is a central group within Netflix. We recently reorgd about six months ago to form this central team and to really bring all of the groups together that are responsible for making our internal developers' lives easier. And I, with my peers who are developer productivity in delivery and in the operate space, we run this group that effectively abstracts away all of the Netflixisms that developers would have to deal with day to day and makes it easier for them to focus on their specific domain of expertise. So we are sort of like the nerds' nerds, if you will, right? Enabling them to use our platforms and tools so that the work that they're doing is focused on studio and streaming without thinking about everything that's under the hood to get going. So for my particular team, I run the develop group within developer productivity.
And again, my sister teams are delivery and observability.
And develop does the inner loop of development. So we focus on coding, bootstrapping people, testing, debugging, debugging, code maintenance, and then handing that off to the next domain within the life cycle, which is sort of that CI CD delivery. And then the operations piece, which is the third bucket for insights and metrics and things like that. So yeah, we're really reinforcing this Pave Path concept within Netflix, where we want to get people using tools that help them out day to day, using platforms that help them out day to day, and keeping people on the Pave Path.

**Dan** (3:36)
A Pave Path, that's what you're saying?

**Kathryn Koehler** (3:38)
Paved Path, exactly. There's so many metaphors here. Yeah, absolutely. Like we want to on-ramp people under the Pave Path, and the Pave Path is smooth and it's wide, and people can get to where they need to go quickly.
But once they fall off the Pave Path, it's a little bit buyer beware.

**Dan** (3:54)
Gotcha. Totally makes sense and really cool that Netflix is focused on this and has this role and you can be in this role.
It shows me that you all really care about developers and making sure they have that smooth road to, I guess, go fast on. I love the role and I think it's a really good segue into the next question that I wanted to ask here. And that's around, how are you measuring productivity at Netflix? I want to first start with outcome versus output.
And so, you might think of measuring customer satisfaction, that might be an outcome that you're looking for versus something like agile velocity, which is maybe an output for engineering. Which of those two do you think is more important, the outcome or the output?

**Kathryn Koehler** (4:53)
Outcome, 100%. Maybe 0.0001% activity.
Early in my career, I got really wound around this metric about team velocity. But if you're running around a track super fast, but you're on the wrong track, does it matter? So really, what are you delivering?
How you're delivering is important, but if that thing that you're delivering is ultimately doing what you want it to do, that's the most important thing. It's super hard to measure, and you can have a bunch of measurements around that, but it's super, there's no unicorn measurement in terms of effectiveness and outcomes. But that's all, most of all, what we care about. Everything else is just sort of noise, in my opinion.