Episode 21 | How to Hire Engineers & Build Inclusive Teams with Dana Lawson from Netlify

Eiso: [00:00:00] Welcome to Developing Leadership, the podcast where I, Eiso Kant, and my co-host Jason Warner share our thoughts and lessons learned on engineering leadership through the years.

Today we have Dana Lawson on the podcast. Besides being a ball of energy, Dana is the VP of Engineering at Netlify. The cloud computing company helping teams build high performance sites and apps. 

Dana joined with a proposal to reinvent the interview process by making it more human and embracing each other's uniqueness. We answered questions like, what signals should you be looking for while you're looking to grow your team? Why technical take home exercises sucks, and how can you build inclusive teams? We also chatted about how software development teams have changed considerably in the last 10 years and what that means for companies building software today. 

Today's shout-out goes to K. Schmidt Dev, who left a five-star review and a very nice note for us on Apple Podcasts. If you enjoyed the episode, leave a review on Apple Podcast or Spotify, and share it with another engineering leader. As always, this episode comes with accompanying show notes featuring our favorite moments from the chat and a deep dive into today's topics, find them at developingleadership.co or link in the description.[00:01:00] 

Hi, everyone, we're back again with another episode of Developing Leadership. Today we have with us Dana Lawson, Senior Vice President of Engineering at Netlify, a product and company that a lot of us engineers love and use. And previously with Jason at GitHub. When we were just chatting, Dana was throwing a spicy topic on the table, which is the interview process, and I'd love to maybe kick it off before we talk about process and take home tests about what does it really mean for you to successfully bring someone on board to your organization? 

Dana: Well, thank you for having me. This is a topic that I love. What does it mean for me to successfully bring somebody on board in my organization? Really, it means that people come in with the right set of expectations. They know the job that they're getting into, and you're not full of surprises. I think it's a terrible experience where you have such a strong... I mean, it can go either way, you have such a strong interview [00:02:00] cycle, and it's super rosy, and you're like, "We're the best team on the fucking planet, and you're gonna come and be awesome." And then they get there, and it doesn't quite meet those expectations.

And so I think there's a lot of opportunities to be real about your circumstances, be real about the work that you're doing, but also show where you're investing in your company values, and don't sugarcoat it. Too many times, you see the sugarcoating of like, "Oh, we're the nicest team ever." And then it's like, "WOW your team is spicy?" You know what? Humans can be spicy, and so I like to bring reality into that process. And I think it should just be continued, you know, to really look at it through this lens of, "Are You Being human-centric?" Because at the end of the day, you're bringing in a collective of humans that are different, even if they had shared affinities from around the world, to create something magical. There's gonna be rough moments. There's gonna be rough problems, but it's gonna be good, and I think you have to accurately depict that in the interview loop. 

And I think it has to go through the entire cycle, not just that first touch [00:03:00] and that first take and really bring reality. 'Cause what success is, is not getting somebody hired. It's really that, that thing that we've been seeing over the years, the 90 days. Do they feel like they are able to do the job they signed up for? Do they feel supported? Do they feel like they're enabled? Do they feel like they're gonna meet their own personal goals? And if somebody can't say that with a resounding yes, then you probably failed, and you're probably not bringing people on as they should, and you got a lot of work to do after that.

Jason: I think it's funny, there's that meme that goes around that we see on Twitter all the time now, which is the scene from King Kong Vs Godzilla, whatever, where they're fighting, and they say, "This is the technical interview," and then they show the job. And it's like the, the watered down by 15 levels version of that, and that's like true in so many different scenarios, if we talk about all these, these different tests that people have to take, and all that sort of stuff to get into these companies. And it's just... that's not the actual job looks like, 90% of... like, half the jobs out there are crud applications, it's just taking [00:04:00] data from the database and putting on the screen and then taking input from the fields and putting it back in the database and et cetera, et cetera. And I think, you know, the irony of those situations is not lost on people who have had to go through these things themselves.

Dana: Oh, totally. I've said it before, people probably have heard. It is like, I- I'm not a huge fan of like, "Take home technical exercises, go do this thing, and then come back and we're gonna do a, a, zero run. Yes, you failed, or no, you failed, or yes, you passed. Yes, you pass." I mean, because at that point, I wanna ask like, "What are you actually looking for? What do you wanna understand?" I love the technical exercise, that is a technical conversation, because to me, the most important thing that you can have on a software development team is collaboration and cooperation. How are they gonna be able to effectively demonstrate how they contributed to that project? Are they effective in their communication? Do they talk about the impediments that had happened?

I mean, I think now that so many people openly share [00:05:00] all of their stuff on the internet. I'm gonna tell an interview, take, um... literally 5 to 10 minutes and go haunt somebody, go read their tweets, go look at their GitHub repository, go look at where they worked, go... And then ask them questions about cool projects, they did get into the details. Get into the details. I think it's a lot more user-friendly, and there's a lot more empathy when you're having somebody replay a situation or scenario. Now, I know there's a lot of engineers out there that are like, "But how do you know that somebody is just not BSing their way through it?"

How can I really understand. I'm like, "Do you..." I really love actual pair programming as a technical exercise more so than a test or take home. I don't know about y'all. I got teenagers still at home in the afternoon. They still bother me, occasionally. I don't have time in my life after work to go spend X amount of hours. But that doesn't mean I don't have any commitment into this job that I wanna go into, and I think there has to be some bidirectional trust, and [00:06:00] it has to be catered and curated to that skill set that that person has.

'cause, you know, there's both sides of the equation, people say, "If you don't have a standardized example, how are you being fair?" I'm gonna just tell you, life ain't fair. There you go. Life ain't fair. People are unique. What gap are you filling in on your team? What level of technical acumen is the benchmark? And then go from there, and so I like to have them have a conversation. 

I recently was sitting in an interview summary where we as interview group got together, we talked about it, and one of the engineers is just like, "Oh, well, they didn't finish." They got to three parts of the exercise, and they didn't finish. And I was just... You know, I, I have been at Netlify very long. So this is very fresh story. And I was like, "So?" Like, I was like, "So what didn't finish?" like I'm... Like, what, what is that important? 

Are you, are you looking for somebody that finishes stuff? Like, you know, this was i- Like, what are you, what are you looking for?" And I think just elevating that question back to the top, "What are you looking for? What do you really need to understand about how this [00:07:00] person works, and the technical depth?" And to me, it comes back to, "I'd rather have a strong engineer that everybody wants to work with, versus the most badass engineer of all time that everybody thinks is jerk." Like to me, I'm like, "Now get out of here." So I think it's just being realistic about who you want on your team, and how they show up in this world, and really catering that exercise, that interview to knowing who they are and meeting them where they are. It's okay to ask the question, how, how do you best demonstrate your technical ability? I think, why don't we just start there, and have a few different playbooks in your pocket so that you can once again meet people where they are.

I think about accessibility. I think about inclusion. I'm very fortunate to get the opportunity to work with some engineers that are hearing impaired. Would you put them through the same tests that you would somebody else? Would you put them through the same... that's not... Once again, we're talking about fairness. Let's talk about being fair. So I- I'm very passionate about it, because I believe being in [00:08:00] technology now for 20-plus years, I'm not gonna say the exact number, 20-plus is scary enough that the culture has changed. We want more people to be on our teams, because we want to represent the new version of software development, and the new version of software development is different. It's different than it was 10 years ago, and I fricking love it, 'cause I've not come from a traditional background, and I think most and the majority of people in the future are not. And so we have to find a way to make it all work together.

Eiso: So Dana, there's a lot that you're saying that I'm, I'm nodding an agreement with. But I want to... I wanna ask a couple more questions and, and dig deeper here. The new version of software development. The, the new team compared to 10 years ago, list us out or, or walk us through what is really different today, and, and where do you believe we're actually heading in, in the coming 10 years, and, and maybe your utopia of the world that you'd like to see?

Dana: I mean, I'm gonna start with my utopia. Everybody's a software developer, in some, some capacity. Whether [00:09:00] they're SRE, DevOps, DevSecOps, whatever, front-end, back-end, I'm just like, listen, we as an industry... And I wanna thank Open-source and everybody out there in the world that continues to contribute, have made it possible with these new ways that we can create applications. And I think the difference that we see now is the, the... I would say the barrier of entry before where you maybe had to go, and I still think there's a lot of... Don't get me wrong. I think there's a lot of awesomeness that can come out of the traditional education and getting that computer sciences degree. 

Technology's moving faster than these, uh... at least in the United States, than these universities can keep up with. The books that are printed are out of date by the time they hit the shelves. I think we need to learn concepts, but we also need to reach back in the community and teach real world scenarios for how to be a developer, and what we're seeing here is you could still go and get your degree and be successful. But I'm also saying like, you can go and [00:10:00] self-educate, go to boot camps, do some version of that education, and still be equally as successful, because of the work the world has done. We've seen the rise in technology and the ease of use, and we think about documentation different. We think about our platform toolset different. And I'll say it, I think it's, it's somewhat technically easier to be a software developer today with the menagerie of frameworks, coding languages, platforms and tool sets, versus, you know, when I started when it's like, "Cool, you write and see, go figure it out, here's a book and a diagram."

And so we're continuing really to evolve as humans, but we're also continuing to evolve in how we approach these problems. There will always be time and space for people that go much more deeper, but if we think about the majority, the majority, I would say, of software developments this day and age, they're utilizing a set of tools that they... that they're good at, and they're applying those there. I don't think you have to be a full-stack developer. In fact, I think nobody really is a full-stack developer, if, if at the [laughs] at the end of the day, I'm like-

 ... [00:11:00] "You could do it. But can you do it well?" So I'm like, "It's okay to like, be specialized and be good at the things." And I think, in addition to that, 10 years ago, 10 years ago or even 15 years ago, right? Just access to machines, laptops, like there's been so much advancement from our networks, to our tool set that allows you to be a programmer with not great equipment. And now we're lowering that barrier, one more click, 'cause we're saying, "Cool, you can go program on a low-powered machine and be successful." In fact, how about you just program through web browser, and you could be successful. So I think that kind of changes that persona of, "Hey, I went to Stanford, MIT, here's my $1,000 MacBook, I have everything available to me," but you probably already did. And so we're just seeing this opportunity rise for people that never thought they have that [00:12:00] opportunity, and it goes across the whole spectrum of economic privilege.

Jason: Dana, I love what you're saying on a bunch of the fronts. And obviously, we have shared experience, we could talk about some of these things. One of the things that I find infuriating about the past, software development, and I... you know, from my own history, I understand this too, like you said, "Hey, you're a C developer, I was a C developer, they gave you a book, and they... Good luck," that type of deal. Classical education is where you're supposed to have been, uh, brought up for computer science and know some of the basics, and I get that. Today, we, we obviously have all those different resources, we got, you know, Copilot pilot and Codespaces from GitHub, which we both worked on together, and, you know-

 Yeah.

 ... all that sort of stuff. And at the end of the day, it's, it's one of those things where what you're after is somebody who can do the job. Somebody who can use Google to go figure out how to solve a problem, if they don't know how to solve that problem. And I've... You know, from my own past, I remember in an interview for a bank a long time ago about something, it was EJB land for... from the Java days, and they were literally asking me what like the fourth method [00:13:00] parameter was, and something. That I was like, literally, like, "Listen, if you're asking me that question, we're not having the same conversation."

So there's like that end of the spectrum. But going to the other side, how, how do we, how do we build processes or, or interview loops and, and understand if someone's capable of doing the job too, and again, ultimately, you don't care how they're able to do the job, so much is that independently, they're able to do the job. They're able to figure it out and solve it in high quality way. What have you found or what are you exploring, or how you thinking about that? 

Dana: I mean, I think, you know, really, the way that I go into it is without this preconceived notion of what level somebody is, right? I like to bring it in and say, "Cool." And not everybody has this exact model. So you know, I wanna encourage people that are listening like, "You do you. Like, figure out what works for you." but if you're in a position like me, where you have the opportunity to hire a lot. You really are looking for that baseline of, "What is your experience? What have you learned? How long have you been, a learner?" And then really looking for the values that apply on top of that, and I think the values are equally [00:14:00] as important. And that comes back to again, collaboration, cooperation, communication, the three Cs, the fourth C, which is C++, but we'll get into... That's just for me and you, Jason.

But I think you have to cater it. So for instance, you know, you bring somebody in, and you clearly looked at their background, maybe you looked at their LinkedIn, maybe you looked at their Twitter, or maybe you looked at their resume, and it says very clearly like, "Hey, cool, like fake example, I went to boot camp, I've got two years experience. Here's a couple of projects." I would not give them like, the most hardcore engineering like, "Tell me down four methods? Like what does, what does this mean?" Like cater that towards them and so then you can get an understanding of where your benchmarks against your career levels. I like to use my career levels as really my guiding points, right? You want to when you bring somebody on be able to continue their career as they work with you in the way that they want.

And most people, believe it or not, are ambitious. They wanna continue to succeed. I don't know. I'm getting to the end of my ambitiousness, you asked me in five years, I'll probably [00:15:00] be like, Junior Go Developer." I don't want to be ever senior, I don't even care. Look, I guess Junior Rust developer, I'm getting pretty good at Go. I don't want to do anything else.

 But there's not a lot of people in that category. I think a lot of people are ambitious and hungry. So I'd like to use your engineering career rubric to really understand that level of as you go through the interview process. You should be thinking about that, "Where would they sit? Where would they land? What position? Do they feel the needs that I have?" Maybe you need somebody that is more senior. So that could be one of your things, that is like, "Oh, we've gone through a couple conversations. We've realized you don't have enough depth in this area." Maybe they're a good fit from a culture perspective, but maybe you have limited headcount, like you have to make a tough call there. But I think really, it's utilizing your benchmarks for career progression, and looking at somebody's background, and then finding those examples to help you confirm your assumptions.

It's an experiment at the day, right? So if we sit, and we say, our career rubrics are based, then what does success look like [00:16:00] above or below that for this person wise, and utilize that, because when they join the team, the first conversations are gonna be "Great, what do you wanna accomplish here? Where do you see your career?" If you have a good engineering leadership, they should be asking those career questions. Because once again, I think a lot of us wanna hire people that wanna go for it. You know, like, we're all very passionate, and I, I believe it's our job to enable that passion.

Jason: I, I love it. And there's two things I'm thinking about while you're talking about that. One is, as someone gets further along in their career, we become... th- the industry becomes less bound to, way past signal. So as an example, no one ever asks me about my education, they haven't for years.

 They start looking at the last two or three jobs or whatever. So there's more signal higher fidelity, cool, so you don't have to worry about education. And so thankfully, it's just... you know, someone's had been a senior engineer for four or five times in a row, et cetera. They're not likely to look at whether the person went to CES or MS degrees or boot camp or whatever. And in- independently, that person gets hired, and when they go through [00:17:00] the process, the only thing you really care about is how independent are they? Can they solve these problems?

 Can they lead others? Can they do that sort of stuff as seniors. I've always found that it, it becomes very difficult for the industry to understand how to assess very junior people. And I think it's becoming increasingly hard because we wanna become more inclusive, as you mentioned before, we wanna hire people. We wanna take chances on them. But the signals become less clear, and I agree that we should be pushing in that way. I'm curious what you have found for signals that will help people establish and take chances on folks?

Dana: I mean, exactly that. It's, it's tougher when you're fresh, because you don't have that experience. You don't have maybe that playbook where we can just say, "Oh, look at th- this portfolio of things I've done, and these jobs that I've had in the past and all my connections that you could probably go talk to and will talk to without telling me." I don't know, I always tell people, but some people don't go fig'. I think you have to then have at least some baseline, and that's where, you know, I do in some ways think that this is where you bring in that technical exercise. But [00:18:00] should it be a day? Should it be two days? Should it be four hours? Once again, it should be catered, and so some of the success I've had is like, "Let's, let's pair program, let's get that person." Because i- Jason, you hit it right there, right?

You're not expecting them to work completely independent, if they're brand new. You want them to be able to accomplish the tasks that have hopefully been outlined for them, and as they mature in their career, they can just start outlining those tasks and their independence grows. But I think a lot of people, especially if I replay back, and it's hard to remember, 'cause I'm so damn old, I was happy to have that oversight. I was scared of everything. I was like, "I'm gonna break some shit." I think a lot of people in their first job want that care and feeding, they wanna feel supported. And so I think in the interview process, "How are you gonna support these people? Are you gonna get this... are you gonna let somebody out into the wild and say, 'Go work independent, I know this is your first year or this may be your first job.'"

So at this point, you have to take a step back and say, "What does their day-to-day look like?" And you hit it right there earlier [00:19:00] in this conversation, Jason, is what do you actually want this person that you know, you're about to hire that is fresh in the industry going to do? Give them real world examples. You don't have to share your IP, but you could definitely take an opportunity to spin up maybe a test repo, "Here's some code. Let's work on this together." How would you pair up a senior engineer with a new engineer for success? You typically, in some cases, pair or you guys suck the issue that th- this... that the engineer can run with it on themselves. And I don't think there's a one-size-fits-all, but I come back to something you said earlier, and I do too, is like, What job are they gonna be doing? Give them some reality there. If they can execute that job, they're gonna be doing and have a growth mindset, and they meet your values. Great. You just got a damn good hire on your hands.

Now, if they come in and they can't do that, and you've asked them, I like to ask the question, "How do you learn? How do you demonstrate you've learned?" Some people like to model. Like, "Do you wanna do whiteboard? Let's do a whiteboard." This is also about interview [00:20:00] training. who do you have conducting the interview? Are they flexible? I like to ensure that, you know, as you go up in your career that you can lead from any seat. So do your senior en engineers and above, are they great mentors? If they're great mentors, how did they teach people? And then asking that person, "How do you learn?" 

I think it's okay to do a little bit of interpersonal catering for somebody that is that fresh in that career. Now, as old timers, I don't know. There's gonna be a lot of evidence, like I said, everybody puts everything on the internet, like it was a good interview, you're probably four steps ahead, and you're already talking to people and looking at projects. If somebody's worked at like... I don't know, Northrop Grumman for 15 years, and they can't show any of their work. Once again, you need to carry that a little bit, so that they can demonstrate their level of depth.

Eiso: To me, what I'm really loving here, Dana, because it's, it's incredibly obvious, but very, very few in between done, just a very common sense notion of, "Let's give some people some options, let's figure out what works best for them." And like you said, life gets difficult, everyone is different, and let's go from there, and in reality, that's [00:21:00] also a great way to see if someone is a good fit for a team or not, because that's the kind of flexibility that you have in, in the real world.

You touched upon something earlier, right? You're, you're working like you said, from engineers, from, from Portugal, to the States, to Kenya. Diversity inclusion, it's a topic that's still to this date is defined differently based on different cultural backgrounds where people are at, but at the end of the day, we're all humans, we're all technologists, and that binds us. How are you finding bringing these topics in and kind of getting everyone around, a similar set of, of values in a company related to, to DII that at the same time might also vary hugely when you have such a big international team?

Dana: I mean, it's, it's constant learning. It's constant learning. You know, as, as the human race evolves, so should your thoughts on how we show up in this world, and you just can't set it and forget it. What may have been okay and in fashion 10 years ago, it may not be okay now, and I think us, we really have to have and embrace a growth mindset. I [00:22:00] know that, that word is overplayed. But I think, you know, we all have to be open to being, "Hey, I don't have all the answers and, and when I make decisions, sometimes I get them wrong, but I'm open to learn." And that doesn't matter from your behaviors to your technical abilities.

And I think that there is this push to really try to create these teams where people can feel seen, heard and be celebrated. Because that's at the end of the day, all that people want, is to be respected, to have a seat at the table, and be told they're doing a great job. Because, you know what? Who doesn't want to hear that? I don't know. Even, even the most crusty people love a pat on the back. I know I do, 'cause times get hard when you're pushing hard.

And I think for companies that really wanna take this, you can't just sit and say, "Okay, cool, we have these programs, we've succeeded." I think you have to continuously learn and listen to people, and especially when you have an international team. You can't put on your blinders and pivot it over to one way of the world's part thinking or the other way of the world, you have to find holistically, "Where is that line of affinity?" and a lot of it comes [00:23:00] from, once again, just the basics of humanity. Being kind to each other, listening, giving people space, having that opportunity to just say, "I hear you, and I see you. How can we make it better?" But I think it's really easy to say what you don't tolerate as well, like you don't tolerate some of the basics out there in life. And when you put these initiatives in place, it can't just be like an, one-time OKR right? An objective and key results.

"This, month, we're gonna hire five women." And then when you've hired five women, you're like, "Hell yeah, we just ruled DII, we're, we're awesome." Because I guarantee it the next month, that number won't even matter, because we're still unequal as wha- as we think about gender diversity, and race diversity, and then parents, and the non-parents and all of the different unique variables that make up humans. There's so many. I love it. So you have to find that, at least that basic understanding of respect, and constant learning, right? You don't just set it and forget it. I think for companies to be [00:24:00] successful. It's like, "How have you established this culture of ensuring that everybody is heard, ensuring that people can show up as their true-self?"

A lot of time is wasted for people thinking they need to fit into a perfect picture of what success looks like. And a lot of times when you're starting this journey, that picture won't look like you, if you look different, or if you show up different or if you are different. And so how do you start right now, making that be a top tier value? It has to be your top tier value. 

Because you know what? Like I said, life's too short for engineers, man, great, it's great. Like they say, the great resignation, I say the great migration. You don't have to settle. You don't have to compromise. Go to the place that's gonna do you right and make sure that it meets you where you are. And I think as a company, you wanna have those type of engineers and those type of people 'cause they're gonna make you better and more successful, especially, if you're trying to build something for everyone.

And so, [00:25:00] I don't know. I don't think there's a one-size-fits-all. I think you do have to have... Now, coming back to my example, I do think you do have to have objectives. You do have to be measured. You do have to know what success looks like, 'cause at the end of the day, once again, we're engineers we love... I don't know about y'all. I love math,.I love spreadsheets. I love freaking math. And if somebody's gonna give me some data, I'm gonna make sure that date is damn right, and you better make sure it's right too. 

So I think it's being transparent about where you're failing. Having objectives that show what you want, but in every day using that language of why it's important and why people can do their best job and be who they need to be here. But don't hire jerks. And what is a jerk? You know what a jerk is. A jerk is a person that treats people unkind. A person that doesn't respect who they are. A person that doesn't support you.

It doesn't mean you're not allowed to have a different belief system. It means you are expected to show up and be kind and treat people with respect and also make it a place where people have space, and that [00:26:00] psychological safety, to be heard. And I think for leaders, we got to celebrate even the little micro wins along the way. 'Cause I think some of the challenges with this is like you have this utopia of everybody on your team and the whole world of software developers, but are you going to the same well, for all opportunities? I mean, are you going and tapping the same engineer over and over because it's like your go-to? There's a good little signal right there that you probably aren't embracing diversity inclusion all the way 'cause you keep going at the same well. Go find a new well. Go give somebody an opportunity.

And I think, you know, talking about global diversity, a lot of language is English second language, you may be an English-spoken, you know, company, but you're hiring around the world. Like, put yourself in that person's shoes, especially as Americans that can only speak one language. These people are speaking four or five, like, how are you giving them the time and space? Are you establishing a written culture where people can feel more comfortable? Are you having interviews? Are you speaking in metaphors as in analogies, [00:27:00] euphemisms? Like, I think you have to just continue to practice, look, learn, and then check yourself. Check yourself and then own it when you get it wrong, 'cause believe me, I've messed up a lot my life, and I, I am so grateful that I've had people go and say, "Hey, Dana, did you know how you showed up?" I'm like, "No, I did not even realize that." Now you only get so many of those. So i- you have to put the onus on you and educate yourself as well. 

Eiso: I lived all over the world, I come from international background, I'm self-taught, no-college degree developer. At the same time, I'm a, I'm a tall white guy. So I... there are parts where I can, can, you know, identify and parts where I constantly have to learn. One of the things that I'm, I'm really looking to figure out is you mentioned this notion of celebrating people, and I couldn't agree more, right? Like at the end of the day, share it across cultures, backgrounds, just basic kindness, psychological safety, and, and being celebrated will, will hold true everywhere.

But as you start building this into a culture, we can also see examples of companies. [00:28:00] And I'm calling out Google here, where all of a sudden, the, the emails that need to go out to say, "Hey, you did a great job," start becoming no longer genuine. So how do you find this balance of like, we're all trying to get in a place where we have a true genuine culture, where DII is genuine, appreciation is genuine, but not in one where it feels like some kind of dystopian movie where we all have to do certain things, and the genuineness that a lot of people have just, you know, doesn't even get recognized anymore.

Dana: I think it starts interpersonally one-to-one. I mean, like, I don't know if it needs to be shouted from the stage, but you don't have to wait for that stage. In fact, I'm sure like smart companies have probably created a frequent script that says, "Go in this Slack room and anybody that was in it, go and send them a shout out," and there's no even human element at all that was like, "Oh, thanks. Congratulations me." It becomes watered down and disingenuous. I feel you have to actually find those moments, share examples, like don't just give the blanket [00:29:00] like, "You did a good job champ." Like-

 ... no, like, I mean, I love hearing that, but like, "What did I do a good job at? Like, tell me." And I think it comes down to management, management finding space and time to build those relationships. You should know your people. You should know how they like to be celebrated. I love a global celebration. Don't get me wrong, like save goes when they're warranted, right? Like, do something big and massive. You're probably gonna thank everybody in the damn company, give them a day off. I don't know, what a better things than that is, is like, "Cool, we're all gonna have a day off at this point " But I think it comes down to, to when we talk about values, right? Leadership values. One of mine is, don't just talk to your people, know your people, know them holistically. It doesn't mean get into their business that they don't wanna share. But meet them where they are.

Understand, once again, it comes back to the interview training. How do they like to learn? How do they like to be celebrated? Make it personal, make it personal, because as soon as you don't make it personal, it becomes disingenuous. And then it's like the email of [00:30:00] like, "Oh, great, it's the mon- it's the month of kudos," and everybody's gonna get kudos. 

And you know what? It's easy to be cynical, and like, it's easy. It's easy to be cynical. I don't know, I, I, I always say I have bad moments. I don't have bad days. But boy, how d- can I get cynical sometimes, because I'm a human that lives in this world. But then I remind myself, I'm like, "Girl, why are you not cynical?" So I say, You know what? Let's break it down a step. How do you celebrate this person where it has meaning? Because at the end of the day, why are you doing it? You're not doing it to just show that you have a culture of celebration. You're doing it because you care about people.

And I like to go one step further. Like I love the people I work with, 'cause when you love somebody, you tell them the good, the bad and ugly, and as leaders, that is our responsibility to do that. And so when it's good, we celebrate that goodness and say, "Look at this. Look at how you've grown. Look at what you were able to accomplish. I'm so proud of you." Maybe they don't need to hear that proud part, but some people do, and then grow from that. And if things are bad, you say, "Hey, why are you not on your game today?" Especially if you have a reflection of somebody's progress, like, [00:31:00] "What's going on with you?" And then if it's really bad, I just called them out, not in a big meeting. I say, " what the hell's going on? Do you realize how you're showing up? Is that how you wanna be known as?"

Like, I don't know about you. A lot of people don't want to show up bad in this world. And a lot of people when they do, they're doing it, 'cause they're under duress, or they're fearful. So I like to move away all of that noise and say, "What's going on here? Let's, let's just talk. It's okay. It's, it's okay to just like, tell me what you're comfortable telling me or telling me what you're not comfortable with." It could be just as like, "I'm having a really terrible day." "Great, you're having a bad day, get offline, go take a walk. Go do it. Don't make decisions when you're in a bad mood."

So I think coming back to your point, it has to be personal, or it becomes disingenuous. If it becomes something that is now, like, automated, because you just wanna make sure, "Hey, we celebrate." You're doing it for the wrong reasons. You got to understand like, w- what do you really want? Do you want people to know [00:32:00] that the time and effort and energy that they've signed up for is worth it, 'cause we can't get time back. It's gone. So we wanna make sure that time that they've already spent with you was worth it.

Jason: Love a couple of things you said there. Uh, in particular, this is one topic that I saw, and I've talked about the podcast a couple of times. One is just overall in tech, the lack of let's just call it broad spectrum leadership that the industry, let's just say, doesn't enjoy. It just as a habit, really. And one of the other sides of that, though, is we talked about a lot about expectation management.

 Yeah.

 And so you hit on something here that I think is important, because as you're building cultures, we, we talked about this in the past, obviously you and I, internal, to GitHub and stuff. Culture is not foosball tables, and ping pong tables and drinks and all that sort of stuff. Culture is about what you do and how you do it. And one of the things that I think that we don't talk about enough is underperformance, but underperformance is a thing in every industry. Every company, [00:33:00] every industry, everything. And you know, hitting on the fact that people can underperform, and you can still be very empathetic to them in the situation. But also they... it wouldn't be the right fit for the company right now or in the future, or maybe they don't like the style of the company that is being approached. How do you approach that in general too, and then how do you think about that, 'cause we, we start on the interview topic- too. How you think about that going into the interview process so you don't bring somebody in and then put them into a situation where ultimately they're going to fail?

Dana: Yeah, I, I think you have to be really transparent about what success and failure looks like. Be real. Like make sure your managers really understand, and then make sure your ICs know, your individual contributors. Like this is our benchmark and don't do not go and just make it, you know, some dank door metrics. Like that should be a, a guiding point for your team, velocity and tempo, 'cause door is great to establish tempo, right? Shipping is the heartbeat of the team. You know, you know things are going good. But when you're talking to about an [00:34:00] individual, I think it's important to have that conversation really be clear of what success looks like.

And I know there's a lot of talk about, like how engineers will take career rubric, and they'll gamify it. It's just a bunch check boxes and like, "Great, I'm the world's badass, give me a promotion," right? Once again, we're only black and white. Neither is a succe- success, but benchmarks are there. And so you have a, a spectrum of behavioral impact and results impacted. Together, that should be the holistic view. And what you can establish utilizing different data points is what that benchmark looks like. So I'd say take the combination of the work that's been done, the impact of the organization, the interpersonal relationships, the commitments, and then weigh that against what you expect at that level, and if somebody isn't meeting it, that's where I'm, like, have a direct conversation. 'Cause here's my philosophy. We're adults, like, "I ain't your mom, I ain't your babysitter." Like, "I'm here to e-" It's like, "I'm an adult, I wanna... you wanna be treated with respect? I wanna treat you with respect. [00:35:00] I'm gonna outline what success looks like, and I'm gonna expect you to own that."

"Only you can own your trajectory. I can help guide you and give you a little... You know, like call me Bugsnag. I'm gonna come and snag your bug when I see you doing something wrong. But only you can go fix that bug, okay? Only you can go fix that bug." And I think leadership has to understand when you leave that bug lingering, the effects that it has to the team, because that's even worse, right? Then you're going against your culture. Then you're saying like, "Wait a, a minute, we can't let somebody that isn't performing as expected in any way, be on this team. It will start to impact others around them." And they will say, "Wait a minute, why do I have to pull up the Slack? Why do I have to deal with this? Why does my experience have to be a part of this." I think you have to find it often and early. And if you wait and let it die on the vine, that's a manager's problem. And obviously, the expectations go up as your career goes up on how you should be handling situations because you- you've lived through it through [00:36:00] experience.

So I'd like to just treat people like adults, I'm very transparent. I've been told I'm very direct. So I have to keep mindful of that directness, when I communicate, because I also have to realize I have privilege now with my title, even though like I , I giggle every day, I'm like, "Dana Lawson, SVP, really? ..." Like, "People are scared of you." Like, "Wait a minute, I remember being that new engineer, I never wanted to talk to the SVP ever, I don't even want them to know my name." I'd be like, "Shit, they know my name." Like, you have to put yourself in that person's shoes as well.

So I think it comes back down to an investment in manager training and clarity on what success looks like with examples. And so people know very clearly early when they aren't hitting the mark. Nobody wants to be surprised, because you do need annual reviews that like, "Hey, last six months you haven't been where I needed to be." If that manager knows that person... And once again, Jason, I think you hit on this, yes, have empathy for the human condition, but also be realistic and say, [00:37:00] "Can you do this job?" Maybe their human condition doesn't allow for that, and you've done everything possible to help clear the, the runway.

Once again, only you can own your trajectory. Only you can fix your bugs. We're here to guide them in, and then once again, we have to determine when it's no longer doable, and we have to have those hard conversations. And a lot of new managers haven't had the opportunity to have those hard conversations, role play them, make sure they understand. I like to write use cases against the rubric. Some people are like, "Oh, don't write these cases, then people will think that this is the only version of success." I'm like, "Engineers are not that stupid." Like, I don't know how we got this rap, that we're all just like binary thinkers. We actually aren't. We actually aren't.

And I think more, and more people aren't binary thinkers. And so let's approach people as adults, humans. Let's give them what we've considered to be our guide to success and ensure that it's held, and then check and balance that. Just like you have living processes for initiatives to support inclusion, diversity, the same [00:38:00] should be for your engineering rubric. It should be expanding and growing as you get better. It should be a living document. Now not changing the goalposts, but really refinement.

Jason: I love this, I, I wanna mention something here that's always bugged me about just in general technology and the industry and things of that nature. I think that we, we have to help people along in their career, we always have to coach and guide, but at some point, you have to expect that, every single person becomes responsible for themselves in that same way.

 So initially, you can push, then they have to start to pull and then it has to become a predominant pull mechanism. The feedback you get as you go up the ladder in terms of careers, or you get far or less and, and it becomes increasingly less positive. And up to the point where the only thing that you hear is negative feedback and it's harsh. And people don't fully understand that about the engineering, the IC side of the world, but imagine a staff level engineer who needs to be praised and patted on the back every day. Well, in effect, they're not a staff level engineer to that point where they have to be controlled outside them. 

[00:39:00] Now, we might talk about external versus intrinsic or extrinsic motivations and things of that nature. But the point being, somebody has become responsible for themselves. That said, what I also think is we as an industry don't do enough too early to show not handhold, show others what it means to foster that and teach people how to fish for themselves. 

So again, I don't like to give people the answer all the time. What I like to give people is, a bunch of questions that I would go ask and things that I would do is next and see if they can go and, and solve that problem. And if they can, then they can come back, we could talk about the data that they gather and all that sort of stuff. And then increasingly, you're just giving them less and less of those questions to go ask because they themselves are doing some of that pre-work.

My last question for you on this one is, again, we're trying to suss these things out, we're trying to use low signal events, sometimes to think these things through. And then as we build out companies and careers and individuals, I'm super curious, if you found anything that you'd love to figure out what I call, highly [00:40:00] initiated individual status, like someone where they are in that curve, are they... do they need a lot of hand holding? Do they need, need the coaching early on, or they entered this phase where it's like, "Hey, you know what? You're an independent entity, for the most part, you're going to run independent." I don't mean solving problems anymore. Coding problems. I mean, like, "Can you live on your own inside this organization for multiple days at a time, or do you need to be... you know, outside onboarding, do you need to be handheld by somebody else"?

Dana: As you go up in your career, right? You work more in ambiguity. It's a spectrum, right? So if we think of your career progression as a lever, and ambiguities at the top, the details are at the bottom. Okay? 

When you're new in this, like, you need the details, like, we talked about that new fresh person, it's like, "I'm gonna break these details down, 'cause you have got the experience." As you go up in your career and you get to our level, man, your whole world is ambiguity, like it is expected to be ambiguity, because they're like, "Listen, I got a problem. I have no fucking idea how we're gonna answer it and solve it." Go forth, be [00:41:00] awesome. That's where you start going and saying, "How do they, how do they work? How did..." In that spectrum of an initiative that you've called out. It's like, "Can they work in the highest level of ambiguity and still come out with results?" Now, you know that somebody is ready for the next challenge.

Now, this doesn't mean that they sit there and, and wait in the mire, and then research and you're like, "I'm gonna spend the next four weeks to figure it out." No, you're gonna take an ambiguous problem, you're gonna figure out what you need to understand, and you're gonna start dissecting it, and then you're gonna make movement, and you're gonna make decisions. And I think it's owning this decision making. And a lot of it comes with time and experience and being put in those situations and having the opportunity to go, to go, like you said, go fishing and catch a bucket full of them. And us as leaders, our responsibility if somebody goes up is to give them more ambiguous problems.

I'm not gonna handhold you. You have the experience on your belt, and I like to use that as my signal is how much of an ambiguous problem can somebody solve 'cause it's a good indicator. [00:42:00] Now, it's not a one-size-fits-all, but I think that's really where you start to see these higher levels of like, "Hey, you know, you're doing a good job, and nobody says anything, because everything is just broken down working in lining." Great, you're just taking an ambiguous problem, and you've brought it down into details for your team. You've taken an ambiguous problem and filtered out the details to the right people to figure out the next phase of that, delegation, delegation, delegation. It's a very hard one to learn as you go up the stack, and so that's where I like to visualize it. 

How do you look at this? Once again, I just said engineers are finer thinkers, but look at me using the binary method, how ambiguous is a problem versus- how many details do I have, and I would say somebody that's senior, senior, if details are flushed out, it's all about execution.

Jason: The other side to think about this one, when I talk to founders, and they asked me if they're ready to scale and grow and things of that nature. One of the very first questions I ask is how many people can you almost blindly rely on to get something done, and they could lead it. And I don't mean that there's... you know, you got [00:43:00] 50 people in the organization, and all 50 need to be that. But if you got five, I think you could take on five major initiatives. If you've got 10, it's likely that you can take on 10, because those 5 or 10, could work with the others to break down and figure out how to make that work. But if you got zero, you're not ready. You don't have people that you could basically build around and base it on. 

We like to use sports metaphors and... or I do anyway, Eiso, not as much, but I, I like to use sports metaphors, but it's... you, you got to think of them as, as anchors for the rest of the team.

And, and it kind of influences the rest of the organization too. What kind of personality they have, or what their skillset is, all that sort of stuff. So you know how I feel about this, and I've talked about this internally to GitHub for many, many moons, but if there's four constrain into the worlds time, money, people and ideas. For the most part, it all boils down to people who can execute on the ideas in a timely manner, and in the most cost efficient way. And so if you're gonna index on one single thing for the point of highest leverage, go find the people.

Dana: You got it. I mean, exactly that. I love that. I'm gonna, I'm gonna take that one, Jason, right? That's a good, a good [00:44:00] number, right? Who can you delegate these problems to, and can they find success? Are you ready to scale? Because you have those people that understand the problem, the space, and the mission so deeply, that they can just solve for. And I think that's what people want, right? In product development, you think about the pyramid of clarity. In a good operating company, it's mission, vision, right? I love, I love a, I love a pyramid of clarity, objectives, and then everything should come from the bottom-up, because now you know that you have this highly, highly intentional mission with some probably top-level objectives. But now you have these four people below you that can go execute, and really understand what success and what results look like. So I totally agree. This has been so much fun. Obviously, we could talk about any of this stuff forever. I know y'all ain't got forever. None of us do.

Eiso: Thank you, Dana. That's a fantastic place to leave this on. I am gonna throw one quick short question out to you, Jason. Since you worked with Dana for years, what is the thing that, that you've learned from Dana, that still sticks with you till today?

Jason: We talked about the energy in the [00:45:00] beginning, Dana is someone who could walk into a room and just Energize. And it's not my default mode, I kind of go in and maybe defuse or deflect, you know, icebreaker or something like that. But, but people walk in, and it's like, "Oh, Dana's here." And they'd like have to freebase caffeine to keep up. And, um, I learned that, but, you know, stage presence is great. She's got that, you know, walk up on stage and kill it type of vibe about her and stuff. So, um, and people gravitate to that, and people gravitate to her because of it.

Eiso: I definitely felt that today. Thank you so much, Dana. 

Dana: Well, thank you. I, you know, I, I, I like to say I'm on... w- we talked about spectrums, either you love me, or I'm annoying. So I'm glad that I'm on the farther end of that one for you, 'cause that could be a lot, and I get that. But I appreciate those kind words. And thank you again for having me. It's been great. I enjoyed this conversation so immensely, and I look forward to... I don't know, maybe one day hearing it back. We'll see. 

Eiso: We'll definitely have to have you back on because it sounds like we can talk for hours. That's a great place to leave this. Thank you so much, Dana. This was [00:46:00] awesome.