As the VP of Engineering at GitHub, Dana Lawson’s team makes decisions that change the development workflows for millions of people at a time. On this episode of Dev Interrupted we chat about the role of technical leadership, how to implement continuous improvement, and how positivity relates to dev team culture.

Episode Highlights include:

  • The real role of technical leadership
  • What engineering metrics Dana tracks at GitHub
  • How to implement continuous improvement workflows
  • How positivity relates to productivity in engineering culture

Watch a highlight on the Dev Interrupted YouTube

Episode Recap & Transcription

Dan Lines: Dana, thanks so much for joining us today.

Dana Lawson: Thanks for having me. I’m super excited to be here. This is one of my annoyingly favorite topics to talk about. So excited.

Dan Lines: Yeah, awesome. This is an amazing topic to talk about and if we’re kind of going to just jump right into it. You know, I’ve been really excited to discuss, you know, positivity and productivity in dev team culture with you. I think anyone who has either heard you speak or maybe, you know, read one of your interviews or something that you’ve written, what jumps out is kind of a combination of your positive personality and humbleness. And so, you know, I think it’d be good to just kind of hear your views on how productivity and positivity relate to each other and maybe how they affect team culture.

Dana Lawson: Well, I don’t know. You know, I think that it relates to more than just our work. You know, the work life balance is just a complete blur for a lot of us, especially now where the majority of people in technology are working at home. Right. And so I just try to wake up and really approach life that way. I know it sounds cheesy, and that’s why I said, you know, annoyingly talk about it, because I truly believe all this. You know, you think about the fundamentals of life, right? Like what gives people the reason for getting out of bed in the morning? It’s well, at least for me and I’m only going speak for me. It’s like the opportunity to influence a positive change in our environment, you know, and having that blend in to work and doing it in a way where there’s low stress, low distress, you produce more. And as a developer or a maker or a creator, I think when we get into that flow and our mind is on the prize because we’re feeling good, we’re feeling positive, we have all of these things to help enable that vision. Like you suddenly get some fulfillment in your life. You remember why you’re getting out of bed in the morning and why you’re living. And I think it just translates to almost every part that you do. And it doesn’t mean that, you know, you’re always like, I don’t know, super pumped in jazz and happy. No, it just means that, you know, that everything will pass like, you know, stuff is momentary and that if you really think about the things you’ve overcome, I think most people just don’t give themselves credit for what they’re capable of doing. You know,

Dan Lines: If we were going to get maybe like more specific to what would it mean to be in flow for a developer? Some of the things that I’ve seen, it’s like how fast could I get feedback maybe on the thing that I created even better? If it’s not just, you know, it’s always cool getting feedback, collecting feedback, but I always kind of liked it when the person I was creating the thing for is telling me something about it. Usually that’s a customer for a lot of us. So kind of having that fast feedback loop was always a thing that made me feel really good. And I guess on the other side of that long feedback loops, long cycle times, even though my first job out of school, I think I think I worked at this company and my coach never made it. I’ll tell by the whole time I was working there like six months. So that’s a negative feeling, right? Is that kind of the way that you look at it from a developer standpoint?

Dana Lawson: Yeah. I mean, I think it kind of carries on through the whole lifecycle, right? It’s it’s it’s like it is almost like gamification. Right. That developed that feedback, that customer experience feedback is so good, especially when you’re like in the zone, you’re feeling really awesome about stuff. You’re cranking it out and like you’re like, OK, am I hitting the mark? Because it doesn’t matter until somebody interacts with it. It just doesn’t. It really it really doesn’t. It’s tough. And like you said, like, you know, I’ve been guilty of sitting on a pull request for a very long. Time and then you finally get it out there to review and they’re like, what is this like 800 lines of code? You suck and you’re like, I don’t want to do that. So I think it’s not just like it’s the part where you’re putting hands on a keyboard. It’s the part when you’re going through your review, it’s a part, you know. Right. Because who doesn’t like to get a good code review, like where you actually learn something? I love it. Right. Like I’m a terrible front end developer, so I’m always like, oh, like I feel much more comfortable not working in that space. So, like, getting a code review, I always felt really awesome because I’m like, I’m going might be better. It’s going to be quality, but getting it in a quick time so I can turn it around and see how people interact. And I do. I think we all get that little kind of like high of getting the feedback, even when it’s not like the best feedback. You’re like, I got it. I’m going to figure it out. I’m going to see what really I miss the mark with. And I think that’s the challenge that we do to ourselves. And so it’s just that creative moment and how you’re framing what you’re building and what the outcomes are. Right. Because I think it’s just finding that passion and what you do no matter what you do.

Dan Lines: You know, that’s absolutely right. I mean, you brought up kind of a few specific examples, you know, like large prizes, like something that’s like 800 changes. Who, first of all, who’s going to want to review that? That’s that’s really tough. But the other thing that you mentioned is kind of getting that even that quick feedback from your team that always made me feel more part of the team. So if I’m putting up a PR and then I hear like crickets around here, nothing for a week, that kind of makes me feel like down like I’m not really I don’t know if I’m part of this team or people care about, you know, the shit I’m working on and then not fight, but vice versa. Right. If you see someone put up a picture and you’re maybe a developer, you’re able to jump right on that. It’s kind of like a team bonding thing, right? So, you know, kind of just bringing up maybe, you know, a passion that that I have, you know, one of the reasons that I built LinearB actually is to help Dev teams become more productive. And like, one of the things that we’re doing is visualizing those bottlenecks. You know, where are things going smoothly in the PR process? Where are they not going smoothly? You know, you’ve probably heard of the door on metrics and cycle time. That’s kind of the output. But there’s all these little stages in between. You really interested in hearing from you? What are you tracking? GitHub, you know, from a metrics perspective and even better. Do any of those metrics kind of relate back to teen culture in any way?

Dana Lawson: I mean, I’ll just say this. There’s not one metric to rule them all. We’ve heard it over and over. Like, I think somewhere somebody was pitch this, like idea that they’re going to be able to find this golden number that’s going to tell you and unlock the secrets of productivity and performance. It just doesn’t exist. Right, because people are humans. And I feel like it’s really a menagerie, a menagerie of metrics that really make up the output that you see, because it’s not just this collection of activities. We can get lost. The problem the problem is when you’re, like, really immature and you’re kind of understanding of what success looks like, you can sit and say really into qualitative data and say, like, OK, like here’s how many pull requests we had. Here’s even our, you know, Pull Request review cycle time. And here’s, you know, how many actual changes happened. That means we’re hitting the the mark. You just can’t do that. Not ever say people are going to. I keep talking about games. I guess I need to play video games today. Game-ify I find the system. But really what it is, it’s like, are you being honest with the measurement of what success looks like? Like have you really given it critical thinking? And so when I think about metrics and what we think about a GitHub is like we do the standard one, like I get the honor and privilege to work with Dr. Nicole Forsgren. So like, I’m very like all up in her. Like, I go, what does your research say about this? And then my peer, Rachel Pottman, like she led developer research at Google for like, I don’t know, like a decade. And so, like, these two amazingly smart humans that have done, you know, almost their entire career thinking about what drives productivity. You know, it’s really is that Menagerie, that collection. And so we use, you know, quantifiable and quantifiable data sets. Like I think you have to add, like, the things that you know and hold are true. Like we know, right? Like if you’re review time is really long probably. Or people are probably getting anxious. Right. They’re getting imposter syndrome because then we bring the human back into it’s like they’re getting imposter syndrome. They don’t think they feel a part of the team. Or maybe you have a global team like I have a developer. I hope he listens to this in Australia. That’s always like going up. We need better reviewers for Australia because we have, you know, people in APAC. But we need to rethink and think better how we can support them because like review time is like break some connective tissue, right? Even when you don’t, like, consciously think about it. So I think that in conjunction with surveys and reviews and looking at like people’s performance in, like the career ladders, and there are progression because people want to work hard, they want to have fulfillment, they want to feel good about it. They want to see the output of their own personal changes and then that will help manifest like the products that you’re making. So I think it really all goes together. So we do coming back to the question at hand, you know, we use we use the door, but we also use, you know, see stat piece that internal customer satisfaction. We all do surveys. But then you look at different data sets that you may not realize because engagement is just a really hard thing to measure. Right. Engagement is so hard to measure, but you can engage, you can measure engagement by this collection of other things. And so I think it’s about meeting the goals and not being short sighted. And there’s not one size that even fits all for a particular team. I think it has to get down to the team level because I’ve seen it over and over where, you know, some smarty pants executive like myself comes in and is like, OK, everybody, we’re going to go to a two week sprints. You’re all going to do it. And your dev cycle should be this. And then the data science team looks at you like you’re crazy. They’re like, do you even know what we do? You’re like, why would we do that? So I think it comes down to really putting the agency within the teams, having a standard set of tools. Right. Because that’s where it becomes important. You do need to have some single pane glass views into the organization that you all agree upon. But then you have to get down in there, really see what’s the problem, what’s the execution, and then take those in together. It comes with just like really, really transparency of like how you’re being measured and what success looks like.

Dan Lines: Yes. Wow. Some really good points there. Some of the human nature that you brought up. I think, you know, when things get tough for. We want to see improvement, we would like there to be one metric that rules them all, but there’s not because it’s more difficult than that. And, you know, we have a lot of technical leaders who listen to this pod every week. And one of the kind of see if I could pick your brain here to see what do you think kind of the role of technical leadership as it relates back to that continuous improvement and up into the right, you gave a really good example that if you’re in a larger organization and you’re, you know, the VP, let’s say let’s say perhaps you’re the VP of engineering of GitHub and you just said everybody is going to now work on two week iteration cycles because I think that’s going to make us go up into the right. You’ll probably get a lot of pushback there, right. So it’s hard for us as technical leaders. Is there anything that you’ve kind of found as a technical leader that that works or doesn’t work?

Dana Lawson: I’d be like, I’ll tell you what it work. Tell a whole bunch of people what to do when you don’t know any of their business that don’t work. You know, like don’t make a big broad statements, can’t back it up with some kind of facts, like we’re engineers, OK? Like, I think we’re more creative than people give us, you know, credit for. But at the end of the day, I want to see facts or see science. I want to see some of data like I do. Right. We have to balance that out because hello, that’s our job. Right. We think in that kind of way, because that’s how we build these systems. But what I do feel is like, listen, you take all the good parts, right? There’s so many amazing frameworks out there, like, yes, you can be a trailblazer. And then I’m like, but share them. But I think you have to really understand your teams and really understand the objectives and define what are the the single points that need to be unified. Right. So you have foundational practices that should probably be not very deep, but can take care of the masses. And then you really leave it up the situational practices down to the right level of organization. And I know I’m speaking really broadly because the shape of your organization really is dependent upon it. And now, you know, adding in extra variables that a lot of companies, at least the ones I’m seeing where, you know, maybe they’re remote friendly and now they’re remote first, or they have this hybrid model and just these all these different things, like I know everybody’s sick of talking about it, but you have to take that in consideration, right. Of like now how do I have continuous improvement? And I think at the end of the day, as leaders, really, it’s about creating those foundational points. Right, to keep alignment. And that could be a communication tool sets that use, you know, just practices in architecture. I’m a firm believer of, like Azar’s like have some standards around that, not because you want to, like, put everybody in a walled garden, but because you want to make people’s jobs easier and you want to have the ability to measure stuff so that you know what continuous improvement looks like over time. You have to have sat points, right. Just like experiments. Right. You have to have you have to have your medium to determine really what am I going to measure. Right. What am I measuring against? And so you have to define that. And I think really it’s it is your job of balancing. Right. Where are the parts that are causing improvements versus the parts that are just working and then weighing that against. Right. Like your business initiatives. Because if you look at over time, let’s say you have. A good metric set and your second cycle is just you’re just getting loose in the market, right? You just know it because, like, you’ve got good features out, your feature release time is a lot further out than it used to be. You really have to sit and say, well, if we do this work, this will pay us for the future. And I always say be kind of your future self. Right. And I think as leaders, that’s what you’re looking out for. How can we, you know, continuously improve by making the systems better? Because at the end of the day, the reward payoff will be better because teams are aligned and you know what you’re working on. And when people know what they’re working on, they get back in the flow in the zone and they’re probably hopefully happy and positive about doing what they’re doing because it’s in a low stress and distressed environment.

Dan Lines: Yeah, yeah, I mean, the thing that’s like I think really tough about continuous improvement is sometimes you have to change your workflow or break a workflow that maybe your entire engineering organization was used to doing. And sometimes as a technical leader, you might have an insight, hey, you know, OK, we’ve been talking about peer review. So just use as an example. You know, we know that data shows if you can move through the PR lifecycle faster, customers will get value into their hands faster and developers will get feedback faster and we’ll have more positivity. But for example, you know, a lot of engineering teams might have a way that they’re already working. And you’re kind of coming in and saying, hey, would you mind adapting that or breaking the way you work, but just feel so painful. Do you have any experience and how to, like, change a workflow if you’re seeing something that could be improved?

Dana Lawson: I mean, that’s your job. That’s your job. I mean, it is. And I think you have to. That’s where I was coming back. Like, you know, you better you better have your data to back up. Right. Because here’s the deal. Right. If your team it’s about building trust. Right. Knowing what your role is. Right. I try really hard. Like I, I see my role as keeping greater alignment, ensuring everybody knows their business objectives and continuing to do that by lifting people up and ensuring that they’re getting the best experience in their career so that they can continue to go on and hopefully make, you know, humanity even better for all of us. And so when you boil that back down and people understand your role, why you’re there, you should be backing up your your your experiment, your science. So when I call and say like, hey, look, here’s what the data says. I’ve talked to teams I’ve surveyed. It’s a it’s a trap, though, because you’re not trying to build consensus. Right. You’re trying to explain and keep people informed. My job is to inform people of decisions and outcomes. And obviously, if new information comes in, I’m a growth mindset. Informed decisions change. Right. And so you have that opportunity to talk to those team members because one, check yourself. Right. Validate your information, especially if you’re twenty thousand. But above, like, yes. You’re looking at a broad do your homework, make sure that you know that. But at the end of the day. Right, like nobody likes their cheese being moved, as they have said forever. Now, nobody wants their thing changed if it’s working for them, but maybe they don’t realize what’s up on the horizon and what got you there. Is it going to get you there? And that happens a lot, right? It’s like this was fine. It’s awesome. Well, maybe there’s a piece of insight that they’re missing of. Well, maybe it’s not as awesome as it could be because we do get so hyperfocus in that little carved out piece of the world that we’re doing. And that’s where I come in and say, you know, I don’t even know yet how to crack some eggs. Right, to make a cake. Well, I want to make the best damn cake there is out there. And like, sometimes you got to crack eggs and it’s tough because it GitHub, right? All we think about is developer workflows. Right. And we make any change. It’s just like, oh, let’s go break some of these workflow. That’s going to Change always workflow. And you trust me, the internet will let you know when you break their workflow, they’ll be like, what the hell? You just broke my workflow. I’m just as picky about it as well. But then I’m like, we’re going to demonstrate that your workflow sucks. Like, I don’t know, sometimes we just deal with stuff because we have it locked in there. It’s like, is it really an awesome workflow? Was that really serving you? Is that going to serve you in the future or is it just serving you right now? And I just come at it with transparency and clarity why we’re going to do it. Does everybody always love it? Absolutely not. In fact, have had many, many, many engineers over the years, like be like Danny Suck. You know, I’m like, yes, I did suck. And sometimes I suck long term, but sometimes I suck only short term. But then it’s like growing and learning together and seeing what we accomplish. And I really think it comes down to trust. Right. Well, you got to trust the people around you to be able to change these workflows. You have to because you can’t be a bull in a china shop. You’ll affect people’s lives and you’ll affect their livelihood. And then that in turns to, you know what? We started talking about getting out of bed in the morning.

Dan Lines: Yeah, yeah, I totally hear you on that. I think the trust is like if you’re going to ask to break someone’s workflow or if you’re going to just break someone’s workflow, you better have the trust to go along with it or bad stuff will happen. And one of the things that we’ve seen within the linear B community actually is in order to increase that trust, visibility and data, the combination of those two things together go a really long way, because if you do have some insights or metrics to back up what you’re saying to your team in an area that you want them to improve and the team can see that you have put in the effort in the research to get educated measure suggests a change that would, you know, result in an output that goes up into the right. That’s a good way to get by in. But where I think a lot of the teams, you know, maybe struggle are actually a lot of technical leaders struggle is when you want to make a change, but you’re not providing the visibility. You don’t have that data. You go to make a change and you get pushback. And so, you know, I think that if we can just kind of combine what you’re saying with, OK, let’s build that trust trust with visibility component. I’ve seen that go along.

Dana Lawson: It’s it’s tough because you don’t always get like it sounds like. Oh, yeah, if only I could wave my magic wand because sometimes you just get told to do stuff. I mean, straight out, that’s the way the world sometimes. But that’s why you have to establish a track record of trust, because when those moments happen and they will happen and you’re going to go in there and be like, listen, I got all the answers because one of the greatest superpowers of leaders working through ambiguity, you ain’t going to have all the answers like shit like last time on my own now. But it’s like telling them what you don’t know as well. And then, you know, finding that track record of like when you’ve had circumstances that you’ve always made it out the other side. I think that’s that’s a key part of it is like they’re not always going to be, you know, a plus is not always going to be huge wins. Sometimes they may be a B, and that’s OK. But you are clear, conscious and humble about like what you learn from that. And you don’t before you said, tell me, don’t repeat the same mistake twice in the same way. It doesn’t mean like you can’t screw up, just don’t do it the same way because it erodes trust because then it’s like decision making. Right. And then you start questioning somebody’s decision making. And decision making is different than trust. It’s a very different skill set, but it’s not easy. And I think it takes a culture. Right. Coming back to the bigger, bigger thing you have to have, you have to have a culture that develops that kind of like, honestly, psychological safety for people to be bold and do the job and fell. But like I think you said it, best rate has to be transparent. Clear communication and communication is harder at the larger scale, but with the data to back it up. And sometimes even when you have that perfect trifecta, it could still fail. It could still fail. And and and you just have to pick yourself up and say, you know what, every failure I know it’s cheesy makes us stronger. And what did we learn? And the next one we’re not. And I think what I like to just, you know, grab myself on is like that wasn’t the end of the world. We felt it was OK. I learned how I felt, because sometimes you get in these situations where everything does feel like it’s the end of the world when you have failure, especially, you know, when you have a whole bunch of smart, smart people like my team is. So I mean, I work with some of the smartest people in the world and I say, no, I’m like, oh, man. And they expect me. He’s a brilliant, brilliant engineers to come up and lead them. And it’s like, no, that’s my job. That’s my rule. Let’s be transparent. Let’s take that feedback. Let’s go for it. You know what? It’ll be all right in the end. It really will be.

Dan Lines: You’ve touched on another important point here. You know, a lot of us are working with really some of the smartest people in the world, like legitimately. And not only are engineers smart, they are those builders, those creators. And I think I’ve heard you kind of talk about the creative mind or kind of that creative mindset. The types of people that we work with in our industry kind of want that. They have the creative mind. They want more of the creative mind. How do you make sure teams that get are being, you know, challenged or I guess unable to use their creative minds?

Dana Lawson: I think you have to you have to expose opportunities. You have to show the willingness to let people change jobs like it’s top. Right. Like we built so much affinity honor squads and teams and we like, oh, we all in those product verticals, it’s like, you know, I am known as the person that does, I don’t know, like audit logs and I love audit logs and I’m not a person. And it’s like, that’s awesome. I think though, you have to have a culture that says, well, how does this play into the bigger system? And then we have more experience. Your skill sets deep in. You know, you don’t want to have somebody with this creative spirit have all their identity on this one thing they’re building. You have to build the identity up. You have to you have to make that identity be much larger. And that comes with impact and opportunity and challenges. And so I really feel as leaders, once again, I’d like to keep people engaged and give them the opportunity to be in the flow. You balance out the stuff you just got to do with the opportunities to do something new you haven’t done before.

Dan Lines: What an amazing kind of final message to to end. You know, giving that opportunity and providing opportunity for different types of people is totally the way to go. Dana, thank you so much for coming on the pod today. This has been an unbelievable conversation. If our listeners kind of either want to learn more about you or, you know, get interested in some of the things that you’re doing at GitHub, where could they go?

Dana Lawson: I you know, I’m not really on a lot of social media because, like, I don’t know, like you just weirds me out. It just says, but I am on LinkedIn is not super deep, but like, I connect with everybody. People are like, what are you doing? I mean, come I will find time, maybe, like, send me a message, maybe a couple of weeks. I want to be real, but like, I try to like, really, you know, if there’s anything I can do to help people, I really want to do it. And if people don’t come talk to me and just talk shop, I’m always all for. So hit me up your.

Dan Lines: Ok, awesome. So if you want to talk shop with Dana, you can hit her up on LinkedIn and she will get back to you at some reasonable amount of time. Also, be sure to join the Dev Interrupted Discord community. That’s where we have this type of conversation continuing all week long every day for everything that we talked about in this pod. And you can find more information in the links below. Have a great weekend, everyone, and thank you again.