At LinearB, we like to think we spend all our time figuring out how to unlock developer potential. To find ways to let devs do more of the work they love and reduce the amount of time they spend dealing with needless hurdles, idling and churn.
We’re not the only ones thinking about how to do this, though. At our recent INTERACT panel, we assembled amazing engineering leaders from Netflix, FloSports and the Refactoring.club newsletter to give us their inside knowledge on how they increase productivity and promote creativity in their own organizations.
One of the highlights of our INTERACT conference, this panel conversation is filled with real wisdom and takeaways we hope you can apply to your own teams the moment it’s over.
Enjoy - and don't forget to fill out our very first listener survey!
Episode Highlights Include:
- (2:38) How Netflix defines developer productivity
- (9:00) Cultural changes for remote-first dev teams
- (18:03) Why daily ceremonies are "stupid and arbitrary"
- (18:32) Creating a product mindset for developers
- (27:24) Say "no" to status updates
- (32:10) Improving non-coding time
- (38:00) Tracking idle time and cognitive reload
Our Interact conference featured content from the best engineering leaders in the world. Watch it on demand on YouTube now.
Transcription:
Dan Lines: Host
Kathryn Koehler: Director of engineering productivity at Netflix
Truong-An Thai: VP of Engineering at FloSports
Luca Rossi: Founder of Refactoring.club
Producer: [00:00-01:24] Hi, I’m Conor Bronsdon; executive producer and sometimes host of Dev Interrupted. We’ve seen spectacular growth in the past couple of months and we couldn’t be happier. To make sure we continue delivering awesome content, we’re humbly asking that our listeners fill out a brief, ninety second survey that we’re linking in the show notes. We really want to hear from you. Making this podcast week in and week out is the best part of our jobs and it would mean the world to us if you let us know what you think, what you hate about it, what you love about it, and what you want to see more of. We want to keep making it better and delivering engineering leadership content to you every week. At LinearB, we like to think we spend all our time figuring out how to unlock developer potential. To find ways to let devs do more of the work they love and reduce the amount of time they spend dealing with needless hurdles. Idling and churn, it’s part of the reason we create this podcast but we’re not the only ones thinking about how to do this. At our recent Interact panel, we assembled amazing engineering leaders from Netflix, Flosports, and Refactoring.club to give us their insight, knowledge, and how they increase productivity and promote creativity in their own organizations. If you love the conversation as much as we did, you can head over to the Dev Interrupted Youtube channel and check out our playlist of every piece of content from Interact. But if you’re going to do that or if you’re going to listen to this episode, please do me a huge favor. Just take that ninety second survey, it’s in the show notes. We’d really appreciate it. Hope you enjoy the episode.
Dan: [01:25-01:52] Hey, everyone, welcome back to INTERACT. I'm excited to deep dive into one of my favorite topics with you for this panel, Improving developer productivity. Once again, I'm your panel moderator Dan Lines on the host of the Dev Interrupted podcast and the co-founder of LinearB, and I get the pleasure of introducing our three amazing panelists. So, we have Kathryn Koehler, director of engineering productivity at Netflix. We have Luca Rossi, founder of Refactoring.club, and we have Truong Thai VP of Engineering at FloSports. Super happy to have all of you on.
Kathryn: [01:53-01:54] Thanks for having us.
Truong: [01:55-01:56] We are super excited to be here.
Luca: [01:57] Thank you, Dan.
Dan: [01:57-02:19] Excellent. All right. So, we're going to dove deep into improving engineering productivity. We're going to be focusing in on developer productivity, metrics, organizational health, growth in scale, and more. So, Kathryn, I want to start off with you. First of all, it's great to have you back. Awesome-like I was just saying, before we started, you're a legend now. So awesome to have you back.
Kathryn: [02:21-02:23] Oh, no. The bar has been set too high, guys.
Dan [02:25-03:01] For those of you who don't know, Kathryn was a guest on the Dev Interrupted podcast last year and also part of an incredible Dev Interrupted Continuous Improvement Panel event. But probably most excitingly, Kathryn, you are the director of engineering productivity at Netflix. Obviously, a famous company, maybe sometimes infam-infamous for its ruthless independence, high impact, high performance dev culture. So, can you define what developer productivity means for you and what you think makes the Netflix approach to development so successful?
Kathryn: [03:02-05:18] Yeah. Thank you for that question. Developer productivity at Netflix is it's a very interesting concept because Netflix, you've mentioned the ruthless independence, the autonomy we have to build things that people actually want to use because there's no top-down mandate. You must use everything that we build. We have to create things that really separate out those Netflix systems so that developers can get on their day-to-day activities much faster. And so, you know, shielding folks from certain sort of the security implications for performance implications optimizations all of those Netflix isms that go along with very complex ecosystems. So we're-we're paving that road for folks, but people don't want to be on the road. Right. The road has to be nice. It has to be smooth. There has to be a good way to get onto that road. And it has to take you to the place that you want to be. Otherwise, folks can opt out and they can use whatever they want. So for us, we the carrot has to be pretty remarkable for people to use what we're building. Otherwise, we're dead in the water. And there's-there's no reason for people to-to want to use the productivity offered. So, you know, we have two primary languages that is Netflix with heavy reliance on node, heavy reliance on Java. And those two application frameworks are very, very paved but there are a lot of languages out there that we haven't paved. You know, Scala, Cortland, Go Rust, etc. And for those types of things, can we create tooling that enables people to be able to work in a polyglot environment that's super important to you? And what makes Netflix so successful? Honestly, it's our talent density, and we all hold each other to a higher standard. There's no way you can show up and not bring your A-game every day, which is a little exhausting at times. If I'm honest, and sometimes I feel like I can't bring my A-game today, maybe I should just take a day off. I'm kidding. Kind of. So, yeah, I mean, Netflix tremendous success. Awesome development. The productivity team sits right at the center of that, and I consider ourselves to be the big lover to make developers at Netflix that much more successful.
Dan: [05:19-05:22] Luca and Truong, how does that compare to your approaches?
Luca: [05:23-06:10] Where I think it totally resonates with my own experience. I mean, when you have a players and talented engineers that want to, you know, spend time on boring stuff, they want to feel efficient, productive. So good and high-quality tooling makes an extraordinary difference in people mind. You know, even if you save like it a little piece of time. But that by the time is would be spent on the way seen and thinks it would be boring, you know, that makes a huge difference. So sometimes we I think we-we just think that easy to measure how much productivity gains we have you have to some the time that you save but it's not that easy and all the time is mental energy. And in my experience too, great tooling makes a ton of difference.
Dan: [06:10-06:27] Yeah, you know what I mean. It reminds me of what we're doing with WorkerB and kind of this really interesting product that we've created here. And what I'm always asking myself is how much time are we saving how much time can we save every single developer trying? Does that resonate with you or what are your thoughts on the topic?
Truong: [06:28- 07:46] Yeah, absolutely. So much you can really unpack your right. So, you know, it is a hard thing to measure engine productivity. I think that most of us and truly know what being on a productive entering team feels like, you know, we're-we're shipping, we're focused, customers are happy, we're happy. Right. So, to me, it's really about leveraging the culture and the process and the tools to really positively impact product development. So, I like to frame it as what might ruin a developer's day. And I don't mean like, you know, they're going to off the table necessarily, but, you know, through many meetings, the distractions might make Jenkins deployment it wrong. Right. Release is taking 30 minutes to deploy waiting on the PR stuff for four days. Right? That's where they need to be. And what becomes it? It's very helpful there. You know, something that we've worked with as a team being a bottleneck for releasing. Right. Needing a virtual environment for developers who want to bring up the servers then they have up and coming back four days later. So, it's really hard to you know, we talked about how to optimize productivity. And I just want to jump in also say like Kathryn's role with developer, I guess developer platform, you know, whether it's for delivery or I think you got you think you're focused more on the development.
Kathryn: [07:47-07:48] That develops side.
Truong: [07:49-8:15] Okay. They develop side. So, it's amazing that you do that because without even realizing it, part of my role at the team at FloSports is on the delivery and flash operations side, right? So, we build that IP into a developer platform. I feel like we can just go back before this all day long. But yeah, you know, the real cost up path, I didn't even realize that until you made that point and I'm just really resonate with me there. Right? As a developer.
Kathryn: [08:15-08:18] Oh, my gosh. It's like the missing piece. Yes. Yeah.
Truong: [08:18-08:23] Yeah, yeah. All this resonates a whole ton with me.
Kathryn: [08:24-08:50] Yeah. You mentioned not flipping the table, but everything you've listed makes the hair on the back of my neck go up. Right? Like, each one of those things is a death by a thousand cuts for our developers. And in aggregate, it will make somebody flip the table and people leave they don't feel satisfied. They don't feel productive in their job. If they're stuck doing all of these menial tasks over and over and over again, that we within productivity can abstract away right? That's our remit.
Dan: [08:50-08:08] Most of us now are in a remote mindset where I can see, but I think all of you are from a home space here. Developers are working from home. Have you all found that remote-remote first teams have had to adapt culturally to being productive, and if so, how?
Kathryn: [09:09-10:36] Well, man. Yeah. So many thoughts on this one. All right. I mean, if not, don't my I'll go first. And Netflix was ruthlessly co-located before COVID, and I actually joined during the middle of the pandemic. I had to interview remotely. I had to do all the stuff remotely. And Netflix was very new to that. And it showed during the experience, and I was very new to it, too. I think my son streaked one of my interviews accidentally. So that was awkward to say the least. But what, you know, what we've had to deal with in productivity is realized. You're not going to get the same kind of support real time. You can't just walk over and say, Hey, what's going on? Our team has been inundated with requests because there's no longer this this other team dynamic of asking the person sitting next to you the question that you would have. And so our team has had to really, you know, develop the context around what our customer teams are doing even more stringently. But we're also a memo-based culture and thank goodness for that because we've been able to lean into memos a lot more and work asynchronously a lot more powerfully than in the past, which is something that's super important for non-co-located or people who are distributed across the different geo locations. But our stuff just has to work. And if it doesn't work, we get hit with support, we get hit with support, then that reduces our own productivity because we're the folks who are holding the pager for a lot of the work that we do. So, we've really had to like clean up our game a lot more working remotely.
Luca: [10:37-11:36] Yeah. And if I may add, I mean, this totally resonates with our own experience because we also went from being 100% co-located to one of the percent remote in other aspects. That became something we had to work and we work on. I mean with purpose, that self then before felt more automatic was to build relationships and team bonding with people and in a different way and still keep doing it. I mean, while we were in the office, this one was mostly serendipitous let's say why now? We found remote. We realized that especially for new hires and people who didn't know each other very well, it became very, very hard. So we, we had to redesign processes not just for, you know, a synchronicity and then with them first, like Kathryn said, but also to enable, you know, a stronger relationships between people that were easier when we were back at the office.
Truong: [11:36-12:17] Yeah, I that makes sense to me a lot like there's level connectedness and happiness that's so important, right? So, we I remember in our office, we-we had a one of those popper-shot things, right? And it just things that there are-a ping pong table, it just it just invite people to like, you know, it's okay to talk about non-work stuff, right? So yeah, I-I feel like we can stand up. What will we kind of do is, you know, ask me what, what's, what are you stuck on? But also, like what how is your weekend, you know, give it tells the story about your weekend. So just making it explicit for people to be able to, you know, not just share and connect beyond just cycling, I think.
Kathryn: [12:17-13:10] Yeah. And as we approach this hybrid world, the next phase where, you know, a percentage of people will be hopefully going back to the office at some point in time. And now we've done a bunch of remote hiring. How do we carry that forward so that we don't have these two systems of like, well, these are the local people, the local people get all the benefits and then the remote folks are left out called? Yeah. We started ordering lunch for people once a week. Within my team, we have like a little DoorDash corporate account where folks can have a team lunch together even if they're remote, which is really, really awesome making that space ahead of meetings. Just to have that chit chat and icebreakers and learn. I mean, there are people on my team that I've still never met, which is a little bit bizarro land because I want to be able to connect with folks on that. Human level so they trust me, I trust them, etc. You know, all good things flow from that. So, it's been really challenging.
Luca: [13:11-13:50] Yeah, I think I think the crucial part is that like you both said, we create like structure for and permission to people explicitly to share these kind of charts. About, you know, icebreakers, hobbies, fun things, because otherwise people don't know that they can even do them inside. Instead, the regular, of course I mean, as long as we are in the office, you know, there is their day coffee corner or the kitchen, you know, you can go there and have a nice burger chat but when you're in a meeting, it isn't natural. I mean, you as a manager, I think you have to step in and create a process that is just.
Kathryn: [13:50-13:51] Being on video is just.
Luca: [13:51] Top of.
Kathryn: [13:51-13:54] Terrible. It's just so exhausting.
Luca: [13:55] Terrible. Yeah.
Kathryn: [13:57-14:21] Yeah. I always turn off my self-view. I mean, I'm present on the video, but I don't want to stare at myself all day. Like, that's ridiculous. It's just exhausting, right? Like, as a manager, you should be able to walk around, have hallway conversations with people you leave your laptop at your desk, can go to a one on one and just have that face time. But now, you know, there's all these distractions and. Yeah, well, it's just a nightmare.
Dan: [14:21-14:49] Yeah. You really have to be intentional about it when it comes to culture. Now for developers and Kathryn, I have one last question in this section that I'll point to you, but anyone can-can jump in when you're thinking about tooling and developer productivity, and you know that you know your developers are asynchronous or remote. Is there anything that you're doing with tooling differently that helps promote someone that's working from home alone or anything like that?
Kathryn: [14:50-16:06] Yeah, well, we're, we're trying to evolve to more of an in-place help model where discovery and-and help and self-help are right there. In your face when you're trying to figure out and you've got the sea of tooling to choose from. Again, really reducing that dependance on support and like human-to-human support in the moment. But we're also, you know, pulling together some more friendly like front doors, user front doors for people to come in and have a more curated experience when owning and operating their own tooling. Let's see, what else are we doing gosh. I mean, we're-we're boiling a frog in a pod, honestly, like we're trying to we're just taking these incremental improvements where we can where we see friction because overall, we just want to simplify and accelerate somebody’s experience. And I would say one other thing that we need to be getting on more of the bandwagon. We are not a remote development shop. We-we did not start doing that early. And so we have a little bit of technical debt there to become more of a remote development shop. And what that means for our remote employees is they would hopefully have the same sort of performance and experience that we would have if we were working a little closer to the backbone. So that's something that we're considering. But that's a little ways out for us.
Dan: [16:07-16:15] Very cool. Luca, Truong, anything else to comment on there with async tooling or anything that you're doing to help developers there?
Luca: [16:16-16:56] We try to do a few things more on the side of making a few processes more asynchronous. And so, we try tools to turn things like stand ups, for example, that we used to do like in person into more asynchronous versions of the of the same thing because I think some, some ceremonies just don't work the same way when they are on video, and they become really unbearable to everyone. And I didn't exactly why, but I mean, this is like a common-common concern by everyone. And so, we had some success. We send ups with some specific tools and our tools and retros and check-ins.
Kathryn: [16:56-17:04] I know why it’s become unbearable. [Laughing] This is my hypothesis. We have to-
Luca: [17:04] Please.
Kathryn: [17:04-18:01] We have to-while it’s great manners and it's very inclusive to speak serially, people move on from the point and no one can weigh in. How many of you have played like hands Bingo, right? Like everybody's got hands, like who's got a hand on this point and who's got a hand on a new point? Okay. When do we take the hands? And then when do we cut it off? So that's all like organic genesis of conversation and Curiosity just gets shut down right? And then people get distracted. They've got somebody slacking them over here and they're like, you know, checking out a PR over here. It's just a hot, hot mess, right? You can't stay focused. You can't stay in the moment. You can't have these conversations in real time and where you feed off of each other and you I mean, even this is this is hard, right? Doing panels in person, it's much more like, hey, you know, let me look at you. I raise my hand and I'm going to you know, I'm going to talk over you because. No, yeah, I know. But it gets so much harder to do it this way.
Luca: [18:02-18:32] Yeah, I agree. I mean, why not? Another and other reason that we found out is that when you are all remote, this just encourages everyone to work at their own time. So, if you have like daily ceremonies, things like that, that before was natural to have, let's say, all day at 10am and now it feels like a completely arbitrary and stupid. So, if it's better to just, you know, leave a message on and on-on Slack on the asynchronous tool.
Dan: [18:33-18:46] Creating a product mindset for developers that's kind of gaining more prominence as of late, Truong, that's something that I know that you're passionate about. Can you unpack that for us and explain why you think it's important?
Truong: [18:47-20:52] Yeah, yeah. You know, it's really probably my third really tech. You know, I love tech with a purpose, right? It's not really a strategy or software development method, kind of way of thinking about putting my project moment that being built for your business, right? We don't hire coders, or they you know, product engineers, right? And they work in product teams. So, you know, I find that most dads, they, they want to be part of something bigger than themselves, right? They don't want to be told what to do. We don't hire code monkeys. You know, they ask, why? Why are we doing this? So, eleven of the core values that for sports is make stuff the fans love, right? It's this it's about the customer experience. So, you know, kind of inside being a little bit like the A team that doesn't have the product mindset. And I've been there, and I've done that is not to be like, what is the requirement you know, you might say something like a roadmap. So, we have to do it right. This ticket says, and here's something I find it I've heard around is it's a front-end problem. You know, we're in the back end. It was not ours. So, you know, you-you shift that sort of product mindset. And then now the question become like, you know, how do we improve user engagement, improve ARPU, right? Revenue for media, you know, did our testing reach that thick statistical significance? Right? How do we make it easier for our customers to get through the lifestyle? And so, I feel forced to be a lot like me. Yeah, those are kind of questions. Do you see the difference? Right. The first one feel that limiting. It feels like it's checking a box where the second is like more is more stimulating, right? It's to show that developer care so that team cares. So, yeah, and-and I got to pull this reference in because, you know, Kathryn made a point about, you know, again, I'm star-struck with Kathryn and thought about how she is doing it, she made a reference about-
Dan: [20:52-20:53] We all are.
[Laughing]
Truong: [20:55-21:08] The train running on time. If it's on the wrong track it doesn't matter. Right? And I love that. Right. So, it's really something that we-we value at FloSports. It's really been the right move for the customer.
Dan: [21:09-21:14] Yeah. Well, Katherine, how do you look at it at Netflix when it comes to this this product mindset?
Kathryn: [21:16-23:21] For a long time because of talent density and-and having more senior developers on-on staff. You know, the product was born by the developer and engineering manager to some extent and we have very consciously and intentionally over the last 18 months pivoted to a product driven organization within productivity and so hiring people or moving people into those product roles who have that that product mindset and that is so important to have alignment with the customer. The customer knows what they don't like, but they don't necessarily, or they cannot necessarily articulate what they really need. And so having those product folks, (and we still do this with engineering too, it's not all abdicated) the product folks go out in the while, do the interviews, you know, make those-those insights into customer pain hypotheses, and then we all work that into requirements and it's not check the box requirements like Truong mentioned, right? Where you-you sometimes can-can say, all right, I've got this nailed. And then you go into your little hole, and you develop and then you ship it and you're like, Ta-Da and it's crickets, right? Because folks are like, well, that wasn't exactly what I wanted. But with product, you're staying super close and super aligned with the customer. Throughout that process and you're testing that hypothesis. This is really what they what they need. Is this really what they need? And then when you ship it, you're, you're super aligned like this are some of the tenets of Agile, right? These tight iterations, customer feedback, etc. That's the product mindset. And I love the fact, like if you imbue your teams with this way of thinking, you're empowering them to make even better choices and decisions for our customers than I could from a top-down perspective. Right? So, you're really scaling that product capability throughout the team. But-but we think it's so important that we're investing in a product organization to help us really drive, not drive more, really set the North Star for where we need to be headed. And then it's up to us as the engineers to drive.
Truong: [23:22-24:24] And I want to follow up on that real quick. Like with Kathryn, she's speaking about an internal customer, right? So, you know, a full thought, you know, with-with the external customer the customer experience. You know, we've done a lot of practice over-over the years and with the testing where it needs to research a full support. You know, we transition that dev ops team into more of a packed program. Again, that's where I will come you with Kathryn and all these things about like, you know, how do we train our engineers as DevOps to build a product good. A platform that caters to our customers, the engineers there. So, I think there's a lot of perils by coming up next week. I'm just really excited by like how do you satisfy the developer needs, right? How do you get them to adopt the features you're trying to build the engineers to like this? Okay. I believe we need that we can build, you know, build features X, Y, Z, but you don't really know if to put in the hands of the customer, the developer.
Kathryn: [24:25-25:01] And thank you for calling that distinction Truong like the interesting thing about being an essential engineering organization is we don't really have the benefit of AB testing because we don't have statistical significance with the number of people were catering to. I mean, some of our tools are kind of bespoke and only a hundred or dozens of folks, right? But we have a captive audience where we can go out and be like, so how's it feel? How's it going? What's it look like? How's it going? How are you doing today? What's going on? Right? And you can build those relationships with the customer or hopefully you're not turning into a nag, but you can get that real time feedback from people to see how effective your-your tooling is.
Truong: [25:02-25:19] That reminds me of building, you know, product. You know, at startup, it's like you try to go out and find the first user that really loves you. And I think that is something with internal developers. You can just walk over in, you know, or slap them and say, “Hey, yeah, try this out. You love it. What do you think?”
Kathryn: [25:20-25:27] And you don't want the friendlies, you want the people who are vocal critics like ones they're not afraid to speak their mind and give you the feedback, right?
Truong: [25:28] Yeah.
Dan: [25:29-25:47] Luca, I know that you've been a founder a few times and have a really cool organization going out with Refactoring.club. What are your thoughts around this as a developer and thinking about the product mindset and how to like really focus in on that?
Luca: [25:47-27:13] I mean in the startup world, I think this is especially by the I mean being able to shift you know, engineering mindset from thinking that the value that they bring is about building stuff to thinking that the value is around empowering customers, empowering the product that changes so much about the culture of the company, so much about conversations. So, I think that when you have to, you know, negotiate and discuss engineering tradeoffs there talk between the engineers and the product, I mean, everybody's on the same page about why we are doing this. Otherwise, if it's if it is not. So engineers think we have to just build the best engine, best technology, you know, because that is my goal. One is that if your goal is empower the customer in the product, that shifts completely the perspective and also makes it more natural to have, like Kathryn said, and Truong, a communication between product and engineering that is more-more like a partnership and not like, top down. Yes, I'm the designer, I come, these-these are the requirements, you have to implement this. And then engineering goes into a hole and we see each other after two weeks. It doesn't work like that. But this is only possible when-when you bring that shared mindset, I think about the value [crosstalk 27:12] of being, you know.
Dan: [27:12-27:30] You know, sometimes we get a few opportunities, like leveraging our team meetings, maybe to highlight wins or learnings or things that we think are important. How are you all leveraging team meetings to highlight, you know, kind of what's important or important learnings?
Kathryn: [27:31-28:01] I'm a big fan of retrospective right? Or even pre mortems, how could this go wrong? But retrospectively, they were really powerful just for that constant introspection improvement for the next time around. I, you know, being in eleven, twelve, thirteen, thirty meetings a day, I am not a fan of meeting just for the sake of meeting and providing status updates and other things like that, like “no agenda, no attenda” That’s one of my favorite sayings. Like make it useful!
Luca: [28:04-28:06] That's good. I know write it down.
Dan: [28:06-28:07] I was thinking, what's the point of this meeting?
Luca: [28:08] Fantastic.
Kathryn: [28:08-29:14] Yeah, exactly. If you haven't clearly articulated the goals, if you can't do it asynchronously, then sure, be or, you know, because we're a memo driven culture, if you start to have a memo that sort of falls on its side because the comments are like way out, way the actual content of the memo get to talk about it. But other than that, right? Let's try to keep it. Let's try to keep it as meeting late as possible so that when you are meeting, people are fully engaged and not 100% checked out. Keep people on their A-game. Right? Come prepared, have pre-reads. If people don't have time to read, totally get it, spend the first ten minutes, turn your cameras off if you don't want to see all the lip readers, you know, turn the cameras off, read the memo, get together, then engage and have it be really a good use of time when everybody's together, use it as brainstorming, use it is like a creative opportunity and also it's team building, right? Shared experience. But if you're meeting for status updates, oh my God, like, oh, there's just no, no, please, no.
[Laughing]
Luca: [29:17-30:18] Yeah, totally. I mean and I think today that that's been useful for us for this project. The mindset in engineering is to make engineers track usage of features that they own. I mean, keep them a little bit, you know, owner and accountability on the product side and say, you know, sometimes it's easy because then tracking how much feature issues can be disguised as, you know, tracking performance metrics and other things that the engineers had to be up anyway for has. And so this way, you know, keeping them paying attention about what's the impact of what they've just done and then really try to turn meetings like Kathleen said, not about status updates, but more like if you have to give updates about some feature release or some feature usage, doing more like a celebration to create momentum with the team to get something joyful that carries the momentum forward because otherwise you just there and with the numbers and share something that could be any magic moment.
Kathryn: [30:18-30:40] Cake moments. What are the cake moments? Right? Like what can you celebrate? Because we're all use a negative feedback loop because we're all engineers, right? Sometimes that positive feedback loop is yes, it's super nice, right? And tied to be impacted. Knowing, you know, so and so just skip something. No, the thing that they shift had this tremendous impact on our customers. That's what you should be celebrating.
Truong: [30:41-31:19] Yeah, exactly. I love that. And you can kind of sprinkle that in in a small way. It's only like so we, we do tech all it's biweekly it's not enough to kind of spread, you know, you can something you're currently working on or in progress. But you know, asking in in context of my thanking the developer it's your first day before you demo this talk about, you know, why do we build this? You know, what did we learn from doing this right before getting to the solution or showing the code behind it. So just, you know, those small, small things that you can sprinkle along the way that invites and you know, it pushes engineers to-to practice that communication as well. Right? So.
Kathryn: [31:20-31:41] Yeah, yeah. I'm trying to wrap our because we're now a product driven organization or transitioning to one, we're trying to wrap our heads around the 140 different things that we offer. And we need to make that footprint smaller. It's just that's not scalable. Right? And so, instituting that wheels up party where we deprecated something folks like this is fantastic. That should be celebrated too.
Dan: [31:44-32:33] Truong, love the Dev Interrupted shirt by the way. One thing that we're seeing in the industry is something that upset LinearB we call non-coding time so there's been I don't know, thirty years of tools that are helping developers like code faster or do something really specific with code to be more effective or productive. And we're seeing now that there's a shift where coding time has becoming more and more efficient. But this non-coding time sometimes focusing around the PR process is not as efficient and that's actually where the bottlenecks are. It's when we're not actually coding, the code is stuck. Truong, what are you doing around coding or tooling to help with this kind of non-coding time?
Truong: [32:34-34:15] Yeah, absolutely. And yeah, for anyone who wants a Dev Interrupted T-Shirt. I'm sure you can hit up, Dan. They’re great. Or become a customer. Then be I believe that's how I got the shirt. But yeah, so you know, you mentioned all, you know, non-coding time you know, PR pick up time. So, one of the cool things that we, we, I didn't realize until we buying dinner B was back in May our pickup time was about 20 hours. Right so the time between we've very much in that call until it gets picked up and reviewed right. Yeah. And then we started turning down and where we're seeing today a couple months into the museum choice, we're at just about 10 hours pickup time on average and this is across all of our developers. Right? So not only do we have the metric to kind of see that and recognize and celebrate that, but also understand, you know, how do we get there, you know, so waiting for a pass right sort of work to be tool symmetrical. That would be it. Help automate that. Right? I myself as managing for the working teams. Hey, developer, you know why are we pushing this PR why are we looking at PR? It feel like I'm the bad person anymore, right? It's just kind of handled automatically. So, it's really helpful tool. There you know and I'll see there's there's-there's not coding stuff about meetings and both things that could be distracting. So you can actually solve those things through batching up time, batching up work that's related batching up PR review time in a given day. So, there's-there's a lot of things you can do that's opposing using tools are just not pushing engineers on a process.
Dan: [34:17-34:40] Yeah. Awesome. Thanks for the shout out on the WorkerB’s stuff. And Luca, I know that actually it might have been before you even started refactoring that club. You were writing about some PR stuff and I know you have knowledge about non-coding time. What are you seeing in the industry on this like non-development time and the bottlenecks there? What's going on from your perspective?
Luca: [34:42-36:29] I mean, I mean could be of use and the-an obsession of mine because if you think about it, I mean we, we spend an incredible effort to, for example, shave 10 minutes off our size by pipeline and then we have like code sitting with nothing to do for 20 hours later on said I'm waiting for someone to read it. So I'm of course I'm a big fan of code or reviewing code, but I think in many companies the process is wildly inefficient and we can, I mean we can make it faster while not compromising on the quality of the review. So having the tools incredibly helps, like Tom said, because it enables you know, to and to create celebrations, to create goals, to create momentum towards that, improvements. I think there are many tactics and for us it has been very successful to try to keep the smallest possible, you know, like 90% of our standard, you know, say 200 lines of code that really makes a ton of difference because it makes the reviewer need to allocate this smaller chunk of time, you know, for the review itself, because when you have a large review, it's not just the review time is that the reviewer needs to-to block a big chunk of time and that maybe cannot happen until a number of hours from now. Well, instead, if the review means a faster turn around and then I mean that all the approaches that have been successful like peer-programming, which is not used by many people, but when you think about it, when you do peer-programming, you don't need code-reviews because the code is automatically reviewed by your peer. And but I really think this is an area that where we can have a lot of impact and a lot of impact on shipping more.
Kathryn: [36:29-37:28] Yeah, there's the tooling to highlight where things are getting bottlenecked. And so, you can report back to the team saying, hey, the average bill requests and standing 20 hours folks, what's going on? They love what Luca’s point. You know, there are so many aspects to code reviewing and incentivizing that as you know, this is part of your job. This is what builds team capacity; this is shared experience and gives you familiarity with other parts of the code that you may not have otherwise had. And improves your skills and utility as a developer. Yeah. What's interesting dynamic at Netflix because we have a lot of identity and overachievers and stuff you know, sometimes too many people in a whole request like can you-can you stop helping out so much and go do your other stuff? And these five people have got it. You know, we have a very strong impulse to hop in there and help out sometimes to our own detriment. So we kind of have like the opposite problem in some cases.
Dan: [37:29-39:15] Yeah, that's really interesting. There's something to be said around, just like kind of the coordination of it. Are we optimizing this non-coding time if someone's already reviewing the PR, maybe if you could just see that. Oh, actually I can actually move forward. Another piece of work in parallel I don't also have to be there and I think exactly probably it's gotten harder async. I remember, you know, when I was developing, we weren't remote. So, you can also kind of just see what people were doing. We were all sitting in a similar room. Yeah, but times have changed, and you know, we've really been highlighting a few and we'll get to some actually metrics in the next section. But at LinearB we've been talking about idle time and cognitive reload time. Idle time is when work. It doesn't matter if it's waiting in the PR stage, but we do find a lot of the time actually when companies say this idle time is work, that's not moving forward or progressing. It's just sitting there; it's waiting for someone else. And our data science team have seen like, okay, the idle time seems to be increasing here right now. And the other thing is the reload time or the cognitive reload time of developer, someone that starts a pull request review. But as Lucas said, the PR is really, really large and it's over those 300 lines. And actually, I can't even finish it within a half an hour and now I have to like I'm going home or I'm going to lunch or I'm starting my next day of work now I have to come back into that PR and do this and then reload. Like, what was I even reviewing and those two metrics that are actually been something that we've been tracking and very useful? Now, I kind of see there's like a next generation of metrics almost to look at. What do you all think of that?
Luca: [39:16-40:08] Yeah, and I mean, we were talking about that. I thought that we want to what you want to minimize is the context which of people and we've put requests this is like the most important problem because when the developer submits the request if she expects not to have the reply within like a number of hours, she will move on to another task and she will lose the context. And then she has to go back to review the comments by the reviewer and then she and maybe there is another round of review. And the same goes for the review and not just for the submitter so the short you you're able to-to make all of these and the less rounds of context, which the better. I mean, sometimes the best thing really, I think it is to jump on a call and get the quote together once. Yeah. And stop and you're done, and you don't have to, to, to go back and forth and you don't have to move between all the tasks.
Kathryn: [40:09-41:09] And that's a huge flood prepare programing. I cut my teeth in extreme programing. Yes I did. And it was just so powerful. And you can do that remotely so easily. There's so many different like code or pad sharing mechanisms that you can leverage in just for even particularly critical systems are really complex code. Just getting somebody else in there and talking through it as you go. It's fantastic. And you never want to have just one expert and one area. Right? I can't speak to that redundancy thing. You no, not redundant is like excessive, but you want a couple of eyes on these different areas that are more in depth in what a code review can provide. Because if you're looking at a code review asynchronously, you're not getting the context here. It's superficial context. Sometimes you're looking for some tactical or more like organizational things. You're not really digging into like, what is this doing and why are we doing it? So, I think that's really, really powerful.
Dan: [41:09-41:45] Yeah, we are kind of living in this async world right now. So, you know, a lot of the times developers want their heads down or don't bother me. But there really is and this is something that I've kind of been pushing for in the dev interruptive community. And there are times that synchronizing, working together in a pair can actually accelerate how long it takes to get a piece of work out. And so, you know, I'm definitely a big proponent of that at the right time, particularly if we can't do extreme programing or peer programing, maybe just in the PR process itself, let's get together and get this done quick.
Kathryn: [41:45-41:57] Yes. Ironically, interrupt the developer. Dev Interrupt. Yes, interrupt the developer. Get in there. Don't let them go to their little corner and, you know, lock the door and then have that hero work surprise.
Dan: [42:00-42:31] So, you know, it's great that we've been able to talk about how to make our developers and our teams more productive. And we've had some nice insights and actionable things that, you know, the listeners of this panel can take away. I do want to talk a little bit about balance on the other side and burn out and some other interesting things here and actually I have a note from you Kathryn. You've said something like “No good work happens after 45 hours of work” I’m assuming you're meaning in a week.
Kathryn: [42:31] In a week. Yeah.
Dan: [42:32-42:37] Yeah. Can you unpack that a little bit for us or what does that mean to you?
Kathryn: [42:38-44:23] Yeah, this is something I actually stole from Joel Stein, I believe back Joel and Software. It is. I mean, he was a font of information. If you are really in there using the full powers of your brain and applying that to work, you start to get super crispy around 45 hours and even push it to 50 hours in a workweek. Nothing good happens after that. You start to make mistakes. You start to-to become less efficient, in my opinion. And I think it's so important to-to keep that balance in your life. Read this really great article a long time ago about like how the making of the corporate athlete and it's not like you have to be super fit but every 60 minutes need to take a break and go do something else. Or you need to like walk down to the kitchen, go get a, you know, a cup of coffee, go do something else. Just let your brain rest, relax and reflect and then come back. A lot of professional athletes do this. You know, folks on the PGA Tour super focused on they need to be within they're able to take a step back and relax when they're not necessarily on the grid. These things are important for people to not burn out. But if you're just sitting there in your chair staring at Zoom all day long, cranking, working, I mean, zoom for managers, hopefully not so much for individual contributors, right? There's only so much that you can do with your brain power where you're not going to start making mistakes and start to like that. That efficiency curve just drops off. I think after about 45 hours in a week I do believe that I try to hold myself accountable to that as well. It doesn't mean that I'm not constantly checking on the weekends to make sure stuff is, you know, on track. Nobody's having problems and things like that. But man, at the end of the day, I got to turn it off or else the next morning I'm going to be a disaster.
Dan: [44:26-44:39] Luca, Truong, how does that sound to you? How do you think about developer burnout or, you know, actually what came up for me is saving developers time. There's only so many hours, productive hours. How does that resonate with you both?
Luca: [44:39-45:50] I, I think, I mean, it totally resonates, and I think this is one of the things that, that is made it harder with the remote and hard to spot. And because I mean, this is one of the areas where metrics don't really have. Right? I mean, you have to connect with people and have conversations with people where-where they feel comfortable at sharing, you know, their-their problems their signs of burnout. And this has been harder, of course, for me to have this home than been co-located at the office. And I think it's also not easy because, I mean, people, engineers especially, you know, interests and they don't like sharing, you know, personal issues and-and also, I mean, many people and might interpret, you know, their own signs of burnout as signs of weakness. You know, they don't want to share them because it feels bad maybe to your manager. So you have really to I mean, to put intentional effort to-to have conversation with people, I mean, how do you feel how do you feel this week specifically? How are things going, which is way hard? I mean remotely.
Kathryn: [45:50-47:05] But even modeling that yourself. Right, and just saying, wow, wow, I'm-I'm pretty fried. I'm going to take my day off. Right. And I make it very clear to people that I'm taking time off. And when I take time off, even though I may be working for some of it, I don't have folks see that. Right. Like I'm going to set my send it night and I'm morning kind of stuff and I want people to know it's okay to unplug and something I've done for my org. The first Friday of every month, I give them an organized rejuvenation day, and that's probably going to persist for as long as we're still working from home. Pandemic, etc., because people were not taking vacation and their work was blending into their home life. Like it's hard to commute and unplug when you're already home in my bedroom. All right. Like they sort of like the work life boundary has been so blurred. So that first Friday people feel like they can take that time off if everybody else on their team is taking that time off too, because there's no, you know, urge to check email or other things and it's been very, very helpful for the team to feel supported, recognized. And we're actively trying to combat burnout.
Truong: [47:05-47:55] And I just want to add, like, you know, seeing work in progress helped a lot as well, right? Yeah. That's something that we try to pay attention to. Whether it's on the common board or how we you know, you look at it taking time off. I love what Katheryn said about, you know, recognize for yourself and then, you know, follow your team members. So, you know, we-we do a lot of live shooting and a lot of events over the weekends and, you know, escalations having incidents happen. So, and really the best thing there is just to say, hey, you know, if you had to spend 5 hours of your Saturday, had only this incident to dedicate it to the team take that Monday or Tuesday off. Right. And that and that's what we want to make sure like our team understand that and-and it's okay and I've done that, and you know I've made it clear, you know, for my team that hey, you can do that, right? So yeah, really helpful.
Dan: [47:56-48:18] Truong, you mentioned the metric there with right typically associated to combine teams, but an important metric I think for any developer. How much work do I have in progress or how much team does they have on their plate right now? More generally, what metrics are you using to understand the success of your engineering organization?
Truong: [48:18-49:07] Yeah, I mean, metric wise, again, we can go super deep in this, but it's these are general purpose we can see, right? But ultimately, you want to look at outcome. And, you know, and I think that in part might as well just that's what we're looking at. So, every two weeks you want to look at it that way. It's what do we deliver to your customer? How do we impact them? Right. Metrics, you know, everything about math technique goes back to my earlier days when I was in Tucson. Unit path to our founder. And next thing I know, the next couple days at trial, I mean, it's tough to do. We have I mean, I today I got fed up and I was like, well, we're going to need a test. I'll just search through and all of them and you see green checkbox, right? So, it just got to be really careful how we're tracking their metrics, right?
Kathryn: [49:08-50:00] Yeah. There's so many toxic bias stories of like butts in seats on the weekend lines of code hours working, all this other stuff. It's just like that could be an indication of a very highly motivated team or that could be an indication of a team that is on the struggle bus, right? Like, what are you-what are you trying to solve for as long as we are meeting the needs of the customer and providing a functionality for them that makes them more effective and more satisfying in what they're doing, and we're meeting our business objectives, we're a successful team. We’re preform-and we're not burning out, if we're doing this in a sustainable way. Where is a healthy culture where people want to lift each other up and provide that sort of academic environment and help each other out? Then you have nailed it, right? Like, that's it. That's-that's the pinnacle.
Truong: [50:00-50:09] Yeah. People are learning and growing, and you know, they're being promoted. They're taking on more responsibility. I think those are the more the long-term things that you look at.
Dan: [50:10-50:31] Thank you so much for coming on today. And talking developer productivity with me. I think it's really important for the community right now to save our developers time and make sure that they're not working over those for the hours. And there's been a lot of amazing tips here that our audience can take away. So, thanks for coming on the panel today.
[Music fades in]
Kathryn: [50:31-50:33] Thank you for having me.
Truong: [50:34] Thank you
Dan: [50:33-51:00] And of course, we thank you to the Interact audience for letting me be such a fixture for all of you today. It's an honor to be a part of all of these incredible sessions with these amazing people and stellar leaders. Until next time, you can catch me every Saturday on the Dev Interrupted podcast that Truong is wearing the t-shirt of interviewing the best and brightest names in the engineering leadership community and have a great Interact, everyone.
[Music fades out]