Sometimes among all the sprints, the pressure to ship faster, tools to measure lines of code written, it seems like we as an industry forget a simple fact: developers are knowledge workers, not robots
To remind us what it means to be a human, we invited some of the most empathetic engineering leaders we know to Interact and asked them to sit on a panel together. The conversation that followed is one of the most insightful and relevant conversations we've heard all year. Whether you are an IC, manager or manager of managers, we promise this conversation will help you become a more empathetic leader and colleague.
Today's episode of Dev Interrupted features Kelly Vaughn, Director of Engineering at Spot AI; Jean Hsu, VP of Engineering at Range; and Lena Reinhard, an engineering leadership coach.
Episode Highlights:
- (3:34) Hot take: no coding exercises in technical interviews
- (13:35) Why the panelists are so passionate about this topic
- (28:52) How to conduct a proper 1:1
- (36:44) 'BS metrics'
- (46:38) Burnout isn't the '24 hour flu'
- (53:41) Discussing burnout with your manager
Episode Transcript (disclaimer: may contain unintentionally confusing, inaccurate and/or amusing transcription errors)
Conor Bronsdon: Hey, everyone, welcome to Interact and our next panel, "Treating Devs Like Human Beings." I'm your panel moderator, Conor Bronsdon, co-host of the Dev Interrupted podcast, and I'm joined by three incredible humans today. It's a topic that we hear about again and again from the best leaders in the business, the need to treat developers as the creative, insightful problem-solvers and builders that they are. Sometimes, among all the sprints, the pressure to ship faster, tools to measure lines of code written, it seems like we, as an industry, kind of forget the simple fact that developers are knowledge workers, not robots, and we have to remind each other of that. We all have thoughts and feelings, needs and wants, and it's our collective job as an industry to remember that. It's the right thing to do, it's crucial to retaining top talent, and to create an incredible developer experience that makes your company stand out and perform better. So to help us remember, it's my pleasure to introduce our panel participants. With us today are Jean Hsu, VP of Engineering at Range. Jean, welcome in.
Jean Hsu: Thank you, thanks for having me.
Conor Bronsdon: Where are you joining us from today?
Jean Hsu: I'm in Berkeley, California. Just a little bit outside of San Francisco.
Conor Bronsdon: Awesome, great to have you here, and then we also have Kelly Vaughn. She's an Engineering Manager at Spot AI, and you've probably seen her on Twitter.
Kelly Vaughn: Yes, it's great to be here.
Conor Bronsdon: And, Kelly and Jean, I have to say, I love the bookshelves in your backgrounds, by the way.
Kelly Vaughn:Thank you.
Conor Bronsdon: Kind of regretting not putting mine in the shot. It's wonderful.
Kelly Vaughn: My office has turned into an article showroom.
Conor Bronsdon: Wow, I like that. And then, last but definitely not least, we have Lena Reinhard. She is an Engineering Leadership Coach, consultant, and trainer, and she's also been an engineering leader at multiple successful organizations, and she's joining us from Italy today. Hi, Lena.
Lena Reinhard: Hi, I don't have a bookshelf, but I have a fusebox in case anyone is interested. It's so great to be here.
Conor Bronsdon: It's wonderful having you here. Thank you so much, all of you, for joining us. Our goal today is to have a little fun, might even say a human conversation. I know, terrible jokes. So, I wanna kick off this panel by doing something a little different. When we were talking before this conversation, a kind of a, maybe a hot take came up, when we were talking to Kelly. Kelly, you said that you question whether or not engineers should be required to code in an interview. What's your take?
Kelly Vaughn: Yeah, I love starting on a hot take, by the way. This is a great way to kick this off. Yeah, this is one of those hills I'll die on. I am very, I'm a strong proponent of not having a coding exercise in a technical interview, reason being, most of the time, we're hiring engineers who are not absolutely brand new, and they've been coding at other companies before, they have plenty of production building experience, and so I am not here to see exactly how you code, especially live. First off, we're not, you know, standing behind each other, watching each other code, so that's not a thing, and, second, when it comes to like take-home assignments, for example, they lean towards privileging those who have the time to put into doing the take-home assignment, and so, if you are looking for another job and you are still working full-time or working long hours, it's very tough to find the time to actually work on that, and so you might not be able to do your best work, so it's already putting you at a disadvantage. So, I like leaning more on system design interviews because I wanna know how you think, I wanna know how you problem-solve, I wanna know how you approach a problem, I wanna know just your entire thought flow, especially as you're working with one of our engineers and going back and forth, you know. No stupid questions in this technical interview. No, like, I want to hear whatever is on your mind, and I've found this works really well. I mean, I like to say, I like to think that I've hired some really great engineers in the past, so it's been working great so far. I will say the one caveat, though, is with junior engineers, I know you need to establish some level of baseline knowledge of where they're coming in, and so I'm okay with some like basic, how would you approach solving this specific coding problem, but I'm trying to make technical interviews less stressful for the candidates because they're already so incredibly stressful as it is.
Conor Bronsdon: What about you, Jean, what do you think?
Jean Hsu: I definitely tend toward the, like, let's simulate what it would actually be like to work with this person, and so things like, you know, having them describe something they did, which, you know, sometimes if it's a more senior engineer, we'll bring in some, you know, mid-level folks or junior folks and be like, okay, like this is kind of a situation where this person's describing something like, can you communicate with this person, right? Or have them work with a designer or PM and, you know, have a sort of like simulated kickoff meeting and see, like, hey, can this person help, you know, given these priorities, or will they ask for the priorities, and then how can they help scope or, you know, think about the timeline for this project that we just kind of threw in their laps, right? Like, this is for a more senior engineer, and that's really, I think, you know, going back to the topic of this talk, like what is it like to work with this person rather than like, what is the current technical ability that they have 'cause I'd much rather have someone who maybe doesn't know the language that we're coding in, but has a strong trajectory, has a strong career history of picking things up quickly, right? Like knows a few languages, they'll pick it up quickly. They've had that like, I guess, success in the past, and so, I think assessing what their current, like technical skills is is not like super, is not super helpful.
Lena Reinhard: Yeah, yeah, I would so agree on that. Like I was, for a different project looking this up just last week, engineers, on average, spend about 11 hours per week in meetings, and even if, you know, in your organization, that's different, and I know meetings are a whole different hot topic, but I find that a really interesting way to illustrate, like the job is so much than put, so much more than putting out lines of code, and the job is so much more complex than that, but I still see so many organizations where the interview process for engineers is essentially a row of technical assessments that just focus on how do you produce code, but how, in the sense of essentially how much code do you produce, and where the complexities of it that are about collaboration, communication, building good relationships, being able to take ambiguous problems and turn them into solvable chunks of work, and all of those kinds of things that actually make up the majority of the work, or interacting with your team in one of these 10 hours of meetings, that's the role, that's the actual job, but I think so many companies, already in the hiring, basically pretend like it isn't.
Jean Hsu: Also, the more senior folks get, I mean, especially if you're hiring someone who's sort of like a tech lead or engineering manager type, right? Like they likely haven't been coding, so you hear, you know, I have friends who are like, "Oh, I'm thinking about interviewing, but I need to spend like four months studying up on like LeetCode." I'm like, there's something so broken about the system if you're applying for the same role you have now, but you feel like you need like, full-time, to study for four months, like that's just ridiculous.
Conor Bronsdon: Yeah, to all of your points, what I'm hearing is this recognition that software engineering today is a team sport, and we're often taught, I think, as folks are moving into the ranks of becoming a developer, that it's more of an individual thing. You go in and you like knock out all this code and you solve this problem, and that's part of it, but you also are functioning within a larger organization within a team, you're working with product to make sure you're aligning on the right features, you're working with the rest of your team to make sure you're working on the right pieces, you're probably doing PRs, and I kind of hear that recognition from all of you, which is important that we consider the job as more than just pushing code out.
Lena Reinhard: I think there is an added complexity in that team element, like so many companies essentially when they hire engineers, assess them at an individual level, and there's no doubt that that needs to be done, but the much bigger question that ultimately arises once they join is are they going to be able to perform effectively as part of a team? Because we all know that like adding one engineer to a team won't mean that the output of the team is going to grow by one engineer exactly. You're also increasing the complexity of that team, but what happens is that engineers are basically assessed as sort of standalone entities, and I think a lot of that still comes from this really pervasive hero culture that we still have in our industry, of sort of the lonely coder, maybe they're wearing a hoodie and they're probably also a man in that cliche, and they have the, you know, the stereotypical hacker, whatever, screen on that we all know from the movies, and they're doing it all by themselves, all by their lonesome, but that's not the reality, but at the same time is this question like, how will they contribute to the team? What value are they going to add? What impact can they bring, and how are they basically making the whole of this team better in terms of how they're working and what they're able to, has in terms of impacts, like that's the big question that I think is often really underestimated because we are so focused on these individuals.
Conor Bronsdon: This also brings up something that, Kelly, you alluded to, which is that certain people, if they're being given a take-home, you know, coding challenge to solve as part of their interview process, maybe they have family commitments, they have children they need to take care of, maybe they simply don't have the time or the circumstances, so, my guess is we're also seeing this reduce the diversity of the candidates we're getting, and it's kind of forcing us into a certain mode of candidate by actually having this part of the hiring process.
Kelly Vaughn: Absolutely, and it's something that, you know, if you're being very cognizant of making sure that you have a very strong pool of candidates, a very diverse pool of candidates, you need to look at, from the very top, what does your interview process look like, but also, what does your job listing look like as well? Is your job description speaking to everyone or is it speaking to that very specific, you know, hustle culture cliche, like very passionate about this and fast-paced environment. You know exactly what I'm talking about there. So, you know, all of these things impact the type of candidates who are applying to a role, and every single action you take during the interview process, it can easily turn somebody away from being able to complete it because they, as you said, they simply don't have the time because maybe they have kids at home that they need to be taking care of, they have that second job already. You know, it could be for any number of reasons, and so this is why I'm very specific about the interview processes that I introduce into, whenever I'm hiring for a new role, to make sure we can get a good read on the candidate, but we're being fair to them and being fair to their time as well. Also, you know, the more interviews you have internally, it impacts the productivity of your current team as well because they're having to spend more and more time interviewing, and if you don't have your interview process really down on lock, you're gonna have to do more and more and more interviews, which is going to take more and more and more time, and then you're just going to see this constant cycle of time just being spent on recruiting instead of being actually able to produce what needs to be done for the company.
Conor Bronsdon: I think it's important to bring up that, you know, we're using this word diversity in hiring and diversity in opportunity of candidates. It's not just because, oh, you know, we need to meet some quota or something like that, which I think is a perception for some folks. It's because there are studies that show diversity of backgrounds increases the diversity of thought, and therefore, the innovation of a team. There's a huge opportunity for companies that can take this forward, and, honestly, it's one of the things I'm very proud of with this panel is we have three people who come from very different backgrounds, who are all in very different locations right now, and I wanna kind of dig into the perspectives that each of you bring. You know, we have some unique backgrounds on the panel. Kelly, many of the audience may not know that you actually have a background as a trained therapist, which you bring into your role. You know, Lena, you're kind of bringing our EMEA perspective and so much more from your background, but, Jean, let's start with you. When we asked you what you wanted to speak about at Interact, you immediately aligned with this topic. What do you find so rewarding about this subject matter?
Jean Hsu: Well, first of all, I was drawn to it despite it's clickbaity title because I feel like-
Conor Bronsdon: I feel called out, I'm so sorry, but I feel called out here.
Jean Hsu: I know every time I, like, I checked in this morning on Range, which is where I work, and I did a eye-rolly emoji after saying I was gonna be recording this panel because it's just like, I mean, to me, it's so obvious, right? Like, you should obviously treat your developers like human beings, but I think it is one of the biggest gaps in the industry, still, and so it's obviously not obvious to some people, and or just like people are not given the training or skills to do it effectively. So, yeah, I spent three years before I was at Range, building out a leadership development company for engineering leaders, and the main focus was really around like communication, how to help engineering leaders build alignment with like other stakeholders, other functions, and it was all very, like, we didn't touch a single technical skill, right? Because I think that's the biggest gap in, when people move from like IC roles into tech lead, engineering managers, and like more senior roles, that they're not trained to like communicate to figure out, "Hey, what's important to this other human?" They're kind of just like, "Hey, you're good at IC engineering, why don't you now manage all these people and like manage up and communicate, you know, across the organization?" And I remember we had this one workshop, where, at the end, we have people share like, you know, their biggest takeaway and this one person was like, "Yeah, I feel like I just learned an API for humans." And we're like, "Okay," like, I guess if that was your takeaway, right? Like we're just so focused on the engineering aspect that like, we kind of, I don't know, somehow as a function, we've kind of forgotten about the like, no, these are all humans. I think it's very different from other functions, where like, as a product manager or a designer or marketing or sales, you kind of need that to be successful in your role for like, you know, even from the, you know, junior PM needs to know how to, you know, treat the people around them as humans to be successful, to build alignment, to get things done, but I think that's a little bit less true of like earlier career engineering.
Conor Bronsdon: I don't wanna cut our panelists off too much here, but I feel like you just gave us a better title for this talk, "An API for Humans," and I've got to go back to edit it, and now, so thank you for that. I do think this also aligns with the background of both Kelly and Lena, and Kelly, you in particular, you have a background as a trained therapist, like I said, you have a degree in clinical social work, a masters, I believe.
Kelly Vaughn: Yes.
Conor Bronsdon: Given your background, how do you align with what Jean's saying and how do you think differently from other engineering leads?
Kelly Vaughn: No, I mean, what Jean is saying is absolutely true, and given my background, my educational background as a trained therapist, I take a bit of a unique approach to how I approach coaching and hiring and building, you know, building relationships with a team because I've been studying how to, you know, how to monitor behaviors, how to monitor patterns in speech, how they're talking to other individuals and being able to not only intervene when something happens from like a, you know, conflict resolution standpoint maybe, but be proactive and start to notice when things are going a bit downhill in a certain direction, and intervene then before things get worse, and this is a, it's something I really pride myself on because I'm, you know, I'm very focused on, you know, career-pathing, for example. I want to help you figure out what is it that you actually would want to be doing in the future, especially for engineers who are interested in getting into that engineering management-type role. They wanna learn how to make that switch from being an IC to being a manager. You know, you really do need to learn the people side of it because, you know, we've seen so many companies throw really, really strong engineers into a manager role, and they completely fail, and it's not at any fault of their own. First of all, you gotta make sure they're actually interested in being a manager because your focus changes from the projects to the people as you make that change, but, also, if you're not giving them the tools to succeed, if you're not giving them the coaching at that managerial level, you're setting them up for failure, and so, when I go, you know, when I'm bringing in my social work background into this, and I have a second master's in public health, which is really focused around preventative tactics versus the interventions that you see in social work and therapy, and so I'm able to combine the two of them to a degree. I mean, there's only so much I can bring in about like healthy eating and healthy behaviors on that side, but, you know, that's a side topic there, but, you know, I'm able to bring this in to get this holistic view of my team and find where the gaps are, find where they want to succeed and really pull things out of them to help them think through what is it that they want because, you know, you'll have a lot of people who will say, "Hey, this is what I really wanna do," and it's really not what they want to do, it's just what they think they're supposed to be doing next, and helping them really find what they're passionate about and recognizing that their passion's gonna change over time with everyone's lifestyles. We go through so many chapters in our own lives, in our own careers, and our goals are going to change over time, so it's also important if somebody says, "Hey, I'm not interested in being an engineering manager right now." You can't rule them out forever, you can't write them off. Just say, "Okay, this is not the right chapter for them right now." Let's revisit in, you know, six to twelve months and see what they're thinking, see how they're feeling, see how their lives have changed, how their interests have changed over time, and adapt your coaching, your mentorship, your management style, to what they need now versus what they needed then.
Conor Bronsdon: That seems to align really well with the work that Lena's doing as an engineering coach across the world. You've seen all kinds of managers and management structures. In your experience, would you say it's fair to say that the best engineering teams treat their developers in the way that Kelly and Jean are describing?
Lena Reinhard: For sure. I mean, honestly, the whole take I didn't share at the start of this panel is that many of the best managers I've ever known aren't engineers and were never engineers and will never be engineers, and that's not, I mean, I do have a personal bias there because that's also my own background. I can't code myself out of a bad situation, but that's okay 'cause I never had to. I hopefully never will, but on a particularly different note, like with the engineering managers that I've worked with, many of them never needed to develop those human skills, the API to humans, because that was the biggest asset that they had going in because they ended up in tech through accidents, through career changes, different journeys than the stereotypical person left college with a computer science degree, went to an engineering role at some bigger company and went on from there, like they don't necessarily have these backgrounds. They're deeply interested in tech, they're deeply technical in the sense that they understand engineering, understand engineer's problems, can have conversations about architecture, potentially even, but they're not coding themselves, and I personally still believe that those are incredibly valuable skills, but they're still skills that are extremely undervalued in our industry, and I think that's a huge issue because so many people that I speak with, and, honestly, even my own experience, many companies discount candidates or roles from the get-go if they've never been an engineer themselves, and I think that they're doing themselves a disservice, but I think it's something that's still deeply problematic, and so a lot of people approach me with those kinds of backgrounds and say, "Hey, should I take a break in my career?" "Hey, I've already been a successful manager for six years, but I'm having troubles finding another role. Companies won't hire me because I can't get through their coding test." And there are so many of these folks out there who are really skilled, who've had fantastic impact, but who can't get the jobs because companies still think, essentially, that pattern-matching is the way to solve for high-performing engineering teams. If we have skilled engineers, the only person who they will respect and the only person who will be able to lead this team obviously has to be someone who's as much like the team as possible, and that's where we end with successful engineers being shoved into management positions against their will, that's where we also end with a lot of companies still having only one career path, and that's just engineering, and at some point, you have to become a manager if you want to earn more and get a bigger role, and that's where we also end with a lot of really good and talented managers not being hired, and that's something that I'm really passionate about, and that I do think successful engineering teams do differently because they acknowledge that these soft skills are real skills and they're also really hard skills to learn, hard skills to teach, and they're extremely valuable additions to any engineering team.
Kelly Vaughn: I love that. I currently have 12 engineers reporting to me, and you could imagine, that's a large number to be managing all at once, and if you look at my calendar, I like to send screenshots of my calendar to people just to be like, "How are you breathing right now?" Because I am basically wall-to-wall all day in meetings, like that is my life, but that is the role that brings me joy. That is like, as you said, you know, you have to shift what is success for you in this role? It's no longer writing that production code. I've not written a line of production code at Spot since I joined a little over five month, or a little under five months ago. I was talking to one of my engineers this morning and found a typo in something. He's like, "Oh, you can make your first PR." I'm like, "Nope, not doing it. Just gotta keep this line going for now. You can do it." But, you know, all this to say, you know, I get this joy from seeing my engineers grow by giving them the opportunities, by advocating for them. Does it mean I'm spending all my time in meetings all day? Absolutely. Am I tired by the end of the day? Yeah, but, you know, that's fine with me. That's just, it works as an engineering manager, and it's something that I'm always emphasizing for the engineers who are looking to make that shift into engineering management. Now, I would never ever, ever, ever say, "Hey, you wanna be an engineering manager? Here's 12 people." So there is, you know, that caveat there, but your shift does change, and one of the things I often see get wrong, when you're making that shift from IC to manager or up to a higher level of engineering management, is you're still trying to solution, and that solutioning is now the role of your team, and so you can help guide them to a solution, but you should not be coming up with a solution yourself, and this is why I think it's really powerful to have a background that's not technical because you can't solution. You can help guide them to the solution just naturally, but you're not gonna be in there being like, "Well, this is how you should build it and these are the, this is the tech stack you should use." Let them make that decision. You know, let them potentially make a mistake and say, "Oh, maybe this wasn't the right option and here's why," but you can learn from that as well.
Conor Bronsdon: I really appreciate your point, Kelly, about the fact that, for you, this role's really rewarding. Yes, you're in a lot of meetings, but you are helping to support people and solve their problems, and, for you, that brings a lot of joy, similar to how maybe you would solve problems with code, but, for a lot of folks, that's not necessarily the right career path, and I think that's a really important thing to call it and say, "Look, part of treating developers as fully living, breathing humans is accepting that some of them may want to go into management and focus on people problems and others want to be super technical and focus on the problems they can solve with their code." I remember talking to you, Jean, before this panel about a really great example of this. You told this great story to me about offering part-time work to an engineer who wanted to step away from the company, and that takes an extraordinary amount of trust to build to and kind of develop that relationship. Can you maybe tell us that example and then talk about how you had that conversation?
Jean Hsu: Sure, they didn't wanna step away from the company, but I, you know, through our conversations, I felt like, I mean we kind of talked about this openly that like there were some, you know, creative needs and like autonomy that they weren't getting from their work at the organizations. They were wanting more time for personal projects and I kind of brought it up as an option, and they were not aware that that was an option, so like it created a very like win-win situation, where we could find a way to like retain this person who had a ton of, you know, knowledge at the company and they were able to get what they wanted too, which was like having more time for their, you know, their personal projects, but also having the financial stability of part-time work, and, yeah, I think it was the result of many, many conversations of like, you know, constantly checking in of like, "Hey, are you, you know, what are you wanting more of?" And checking in on personal projects too, right? A lot of our one-on-ones would be like, "Oh, here's, you know, here's what I'm doing in the creative world and like, here's what this person's doing," and just connecting on a personal level, but knowing a little bit about their, you know, what is their life like, what does their life look like outside of, you know, just showing up as an engineer at this company, right? And so, yeah, there's no like silver, magic bullet, silver bullet?
Silver bullet. I think it just, it takes time, it takes like showing this person that you are genuinely interested in them, that you want the best for them, and sometimes, yeah, just like kind of the like, you know, making it possible for people to bring up constraints that are showing up, right? Like, "Oh, I might," you know, for someone else, it might be like, "Oh, you know, I have this financial need that's coming up in six months and so I wanna talk to you about that," right? Like that's a high level of trust, whereas someone in a low-trust environment might just be like, "Shoot, I gotta start, I gotta start looking for a new job," right? And so, just building, I mean that comes up at team level and in the manager level as well to build that trust.
Conor Bronsdon: I think this is a really interesting point because we have these processes we've developed to help build trust, right? And one of them that you mentioned is one-on-ones and the importance of one-on-ones. I'd love to dig a bit deeper there 'cause I think it's one of the key tools that we see leaders using to build trust with their teams, but it's really easy to do this wrong. Kelly, I know you've said that one-on-ones are not a place to be giving someone feedback or ask for project updates. It's time that should be for the employee. Can you talk about your approach to one-on-ones and how you do that?
Kelly Vaughn: Yeah, for sure, so first and foremost, I do not cancel one-on-ones. This is time that is specifically for the employee to talk about whatever is on their mind, whether it is an issue, whether it is a dream, whether they have like this really cool project that they've been working on on the side, that they wanna see, you know, can this fit into what we're working on on the roadmap somewhere? When I'm putting together my one-on-ones, you know, I tell them, right at the very beginning, "What you share with me is strictly confidential. I will only share what needs to be shared with getting permission from you ahead of time, and I want this time to be for you. I'm not gonna give you feedback unless you're specifically asking me for feedback, but I would rather have that time set aside for another time," because, usually, if you're asking for feedback during a one-on-one, it's already too late. You should be, you're normally giving feedback in a much more timely manner, after the feedback is needed. You know, I have some engineers who will be like, "Well, how am I generally doing? You know, if I'm interested in becoming an engineering manager, how am I doing on this path?" Like, and if that's the case, then I need to be more clear about what kind of metrics we should be looking at in terms of how we can track that career path and to make sure that they can hit where they need to, where they are, and they have insight into that without having to ask me for it immediately. So, I'm not usually asking for, you know, updates on how they're doing on, you know, have you finished this task or, you know, how much longer is this going to take you? I wanna have this time dedicated for you, and so, you know, I usually check in with them like, "How are things going?" You know, "How are you feeling overall?" "We've been going through a number of changes on our side, so how are you feeling about that? Is there any way I can support you on that front? Do you have any concerns that I should be aware of?" And then kind of, just open up the floor, like anything goes, and for some of them, they'll talk about, they'll talk about work, they'll talk about specific projects that they're interested in working on, and again, I'm not gonna steer the conversation away from something if that's what they want to talk about, but others, we will just talk about personal things the entire time. You know, and part of building trust for me is bringing my whole self to work, and if I want my team to bring their whole selves to work, I need to do the same, and so if we wanna get on a personal topic, I'm totally cool with that. Again, it probably does help that I have this background in therapy to help structure this type of conversation, but I like having, I like that each of my one-on-ones are so incredibly different, based on who it is I'm talking to and what their personality is.
Lena Reinhard: I do think the whole sort of bringing your whole self to work, because Conor mentioned that I'm the token European in this conversation, there is, there's an interesting point in that, culturally, there's a lot of differences in expectations in terms of what that means for people and how much they actually want to bring of their full selves into work. I mean there's also a whole other question of the privileges you may need to have in order to be able to actually afford to bring your whole self and the full person that you are into the workplace, but even from how much to talk about personal things, how much people wanna share about their families or how they're doing health-wise or hobbies they care about. Germany, for example, has a very, very strong history of very strict boundaries between work and personal life. That's definitely changed a little bit, especially with startup culture in the country, where hanging out with coworkers has become a bit more normalized, but for like 20 years ago, that would've been unthinkable, and, to this day, my dad is using the, we have the version where we essentially use a very polite way to address someone or sort of less formal one. My dad still uses the very polite version with the people he's worked with for 50 years, and so there is a very strict boundary and that's very different in different cultures, and so figuring out what people are comfortable with, even talking about the things that they want to share versus how much they actually want to keep it strictly professional is also a really important part of that.
Kelly Vaughn: Absolutely, and it's not a panel or talk or anything if I'm not recommending a book, so highly recommend "The Culture Map" if you are, whether you're managing people or not, it gives you so much insight into how different cultures approach work and life, and especially if you're working with a globally distributed team, you know, you have to cater your management style to who it is you're working with. You can't, it's not, it's never going to be a one size fits all. Even if they're all based in the Bay Area, they're still very different people.
Jean Hsu: I think there's like, culturally, for sure, there's a lot of differences, and I'm finding that like, I mean, companies as well, like different companies have different cultures of like how much it feels like you wanna bring your self to work, and I think generationally too, right? 'Cause I had this conversation recently with an older woman, and she was asking what Range does. I was like, "Oh, we do, you know, async check-ins and we have, you know, people check in with like what they're working on, but then also their mood for the day." And she like literally laughed in my face and she couldn't stop laughing. She's like, "Wait, you actually call it mood?" And I was like, "Yeah, that's what I told you." She's like, "Why would you share your mood at work? I don't want anyone to know how I'm doing." And it was just like the, yeah, the divide was so interesting to me that it was just hilarious to her that you would even imagine sharing how you're feeling.
Lena Reinhard: One more thing since we're around the cultural topic, so in the sort of area of dehumanizing developers or people at work, one thing I always find really important, just what there is language, and we haven't touched much on that yet, because the way that companies talk is often really representative of how they actually think about people and developers in particular, 'cause I don't think any company would come out and say, "Hey, that we dehumanize developers here and we don't care about you as human beings." Like, everyone hopefully is at least on board with the concept, but then it starts with small things like human resources or talking about resource allocation when you actually mean the way that my team spends their time, and small things like that that are very sort of pervasive in corporate culture and especially if you have a long history there, but also I think are symptomatic of these dehumanizations, and especially as managers move sort of higher up in an organization, it can get very easy to sort of be disconnected from the humans and the real aspects that humans deal with, and so, especially if you are in a higher level position, you also need to watch the way that you talk and because it will be reflective of how you think, and so it's not just about using the right language, but it's about using your language to assess what are you actually sharing, like how are you actually feeling about these people who are working for you?
Conor Bronsdon: This is all, I think really evocative of how much of a divide there is. You know, Jean, your example of, you know, someone laughed at the idea that you might share your mood with your coworkers, and it's pretty clear that not only does it span different cultures, different generations, but, Kelly, to your point, even micro-communities within, you know, a small region. What can we do to try to improve the awareness of this problem and to kind of, I guess, I would say, evangelize it to those folks who maybe haven't yet recognized the value?
Lena Reinhard: Mostly because that's kind of a hot topic, and has been one for the last couple years, the whole topic of like how do you measure engineering productivity, how do you convey velocity and all that, and why should you really stop measuring lines of code as a measure of productivity, and I think metrics are a great starting point because a lot of companies care about them, more companies want them, and they're also oftentimes used as a tool to dehumanize people, but I also think they have a lot of power in actually connecting with engineers as humans again, and so, if you're a line manager or you're the tech lead or even, you know, middle management or an executive, doesn't matter, the thing you can do is basically look at the metrics that your company is using and look at which ones of them dehumanize people. Lines of code is a really good example because it's just a BS metric. It doesn't actually convey anything useful. It's just a, yeah, it doesn't help anything, but what does help is, essentially, helping teams take ownership of the work that they're doing, and metrics are a fantastic way of doing that. Give your teams metrics that they can own. For example, when it comes to the services they're owning, the goals that they have, the business impact that they're looking to achieve, have your teams actually own those metrics in the sense that they have visibility into them, they have dashboards that they can look at, they have monitoring capabilities that they can actually implement, that they can utilize over time, that they can make better. You can also do things like simple delivery metrics, lead time, cycle time, things like that. So the first part is basically giving ownership to the teams, not having ownership with the executive somewhere or with a business intelligence team somewhere, with the team directly, making sure they know what the metrics are, they can measure them, and give them the power to influence those metrics. Give them some capacity in their development, capacity to, for example, invest in improving their observability for the next quarter or whatever the most pressing thing is there, or have them review their cycle time on a regular basis and then discuss how they can make it better. The big thing there is, there's basically two benefits. The one is I do believe that teams are, ultimately, the most powerful entity that we have in engineering organizations to solve problems. It's not individuals, but it's teams, and those teams need to be functioning and those teams need to have ownership and be empowered to solve problems that they see because they're the subject matter experts and they're closest to these problems, and they feel the pain every day if the pager is going off when it shouldn't, and you probably, as an executive, don't. So give these teams power and then have them figure it out, and at the same time, having these metrics will give managers, executives, the finance department, whoever needs it, visibility that they need. Probably don't use agile delivery metrics for visibility for the finance department, but metrics, especially when they pertain to business impacts and KPIs, can be really helpful for them, and so it solves two problems, and at the same time, for me, that's the biggest reason why I recommend that. It really drives this whole idea of teams being a powerful entity and having teams have control and ownership over their work because that's ultimately what you hire developers for, to have great teams that have great impact, and so that's where I would suggest starting.
Kelly Vaughn: I love the elimination of, you know, things like lines of code and velocity as a team. You know, how many story points are you actually closing per sprint? It's not an accurate representation, and one of the things that you'll notice is when you're measuring, your KPIs are more around the metrics of, let's say, what are the overall goals that our team is focusing on? So like engagement, for example, how is engagement trending over time? You can also look at, one of the ones I really like looking at is, you know, if your team is dealing with support tickets as well, follow up on those support tickets for feedback after the fact as well. You know, we often look at how long it takes to close a ticket. Like that is not a good measure. What is the impact of closing this ticket, not only on this customer but on other customers as well? How is this change impacting more things instead? It gives you more of a forward-thinking look of your work and not just kind of narrowly looking at one particular issue, especially when it comes to a lot of support tickets dealing with bugs you may have introduced, and then you feel responsible for that. You can see, we all make mistakes, and we're not gonna penalize you for the mistake, but, hey, look at the work that you've done overall and how this is impacting everything in such a great way. I think it also allows you to provide insight into the human side of things. You know, I'm also asking my team, I'm making sure one of the things that we're correcting right now is how much time each of our engineers are working per week. This is something that's important to me because I don't wanna, you know, I'm still correcting, especially on the same team where I see a difference between some engineers working 60 to 80 hours a week and others trying to find ways to keep busy for 40 hours, and, again, if your work is getting done, why are we looking at hours in the first place? But if your work is getting done only because you're putting in too many hours to get it done, then we have a different problem on our hands that we need to address, but all these metrics really help you understand the human and how they work, but also give them something to look forward to and build towards that's not just a direct measure of how they're performing at this very moment.
Jean Hsu: I think this conversation also reminds me of the hot take I was getting ready to share at the beginning, we skipped that, which is, I don't think that hot of a take, but I think a lot of people think that caring about the people is like on top of, right? Like, you get the core like engineering stuff done and then, oh, if your company has some free time, then you can like have a few social events and do some like team bonding, right? It's kind of like a free lunch-type perk, and I think my take is like absolutely not, right? It's an investment in your team if you care about, you know, if you know how to support your teammates and help them grow, you're gonna get the best out of them, right? Like, people want to be doing their best work, right? Like, people wanna be on a team that's really working well together, that owns their metrics, that feels empowered, right? Like, that all feeds into, like supporting your engineers as humans all feeds into that and will get you better results, so, I think it's not like, oh, we can't waste time on that because we need to focus on the engineering, right? Like that's, it's not an either/or. It's like, it's all in the same, yeah, it's all the same thing.
Kelly Vaughn: It's like you're building a terrible Maslow's hierarchy of needs.
Jean Hsu: Yeah, like, oh, once we kind of get the team running well, then we can worry about luxuries, like caring about them.
Lena Reinhard: That would've been such a great closing statement.
Conor Bronsdon: Yeah, we can cut it here, we're done. I do think that point, Jean, about like not ignoring, this is like an actual feature of what we should be doing and treating us with like this extra, which I think everyone's talking about is like, we need to avoid that. It's really important and it's one of the things that, in my mind, drives burnout for teams is when, you know, keeping yourself healthy, keeping the team healthy is viewed as this like extra or, you know, approaching creative tasks that you're excited about is like, you know, another extra. It can be a huge issue, and one thing I've heard you say, Jean, is that burnout is no longer taboo to talk about. How do you make sure teams feel safe to talk about it?
Jean Hsu: Yeah, I mean, I guess I feel like it seems like everyone's been burnt out to some degree in the last few years, so that's why I said-
Conor Bronsdon: We did go through a pandemic.
Jean Hsu: Right. Before, it felt like, "Oh, if you say you're burnt out, what does that mean," right? There's all these stories that come up of like, "Oh, does that mean you're not gonna, you know, you're not excited to be here?" Like, does it say something bad about the company, right? Like, if you're like, "Oh, my friend works at this place and is super burnt out," like does that reflect poorly on the company? And I think because it became such a widespread issue for people, it sort of opened up, like it made it easier to talk about it without the sort of like, "Oh, what does that say about your company?" Or what does it say about you, like are you a weak person, right? Like, no, no, everyone's suffering from burnout, and I think I personally like talked about, I think, as a leader, one of the best things you can do is like be, you know, be open and vulnerable about what you're struggling with. I remember coming back from winter break, like I think the first year of the pandemic, and everyone was looking forward to being like, "Oh, we gotta, you know, we've got a company shut down, we're gonna come back and be so like recharged and refreshed," and I came back and I was like, "I'm still tired," right? Like, one week of no work is not gonna fix, you know, nine months of like lockdown pandemic, right? And in our morning check-in that Monday, I shared that. I was like, "You know, I was hoping that I would feel more refreshed, but I'm actually like, you know, still, still pretty tired," and like, and in a one-on-one later, one of my reports was like, "Wow, I'm like really glad you shared that because I feel the same way," and like, it kind of opened up that conversation to talk about it rather than be like, "Oh, our company gave us a week off, so we should all be really grateful and like, you know, be back at it."
Conor Bronsdon: And I know it's something that I've heard you talk about too, Kelly, that this isn't like a 24-hour flu burnout that you can just kind of get over and get back at it. It takes consistent effort. What's your kind of thought process around how organizations should approach burnout, understanding it's, A, not something that immediately will go away, and B, as the way work has evolved because of the impacts of the COVID pandemic, because of the impacts of digital transformation, is really adjusted and altered.
Kelly Vaughn: I think the first thing to note here is burnout is literally recognized as a mental health syndrome. It is classified as a mental illness now, as a syndrome versus a disease, there is a difference there, but knowing that, it's also important to understand that there is another cultural component to this as well. When we're talking about mental health, there are certain cultures who are still gonna continue to shy away from mental health, any kind of discussion, including burnout, but you can see the patterns in how people are talking about burnout and how they're feeling overall, even if they don't come out and say, "I'm feeling burned out." So, when I'm thinking about organizations and how they can approach the understanding of burnout, you know, as I said, burnout's not a 24-hour flu. It takes time to not only get over the symptoms that you're feeling as a result of being burned out, but it takes time to get to the point where you're actually burned out as well. You know, it's not like a, you know, a three to five day, and then you're like, "Oh, okay, yeah, I'm burned out. Let me just rest for a couple days and I'll be good to go." The behaviors you have to change start at the very beginning. You know, you look for these signs of burnout early on. You look for changes in personality. You look for withdrawing from work, and, you know, there could always be a number of things going on in somebody's life that has nothing to do with burnout as well that's impacting their work, but you just start to look for these signs over time. You look at how they're communicating with others, you look for that negative self-talk that often comes up when you're starting to go on this downward slope and address those as early as you can, and when somebody's burned out, you need to give them the time and the space to operate as they need, as they feel that they need, in order to overcome how they're currently feeling, as whatever level it is that they're burned out. Burnout is, it's different in everyone. You know, there's no textbook definition of I am burned out because I feel this, this, this and this. It's just, it's not, I am the type of person, when I'm burned out, I don't like to cook and like get creative in the kitchen anymore. That's one of the signs that I'm like, when I'm starting to be like into a better mental space, I'm like downstairs just like grabbing random things from my fridge and my pantry and making a meal. I'm like, "Oh, oh, that's a good sign." So I've, you know, I've learned over time with myself, you know, what kind of things to look for in my own pattern behaviors, but look for those in others as well, in your team as well, and provide the education and the coaching around what burnout will look like, and how it's gonna differentiate from one person to the next, but it's those regular check-ins, it's why I'm doing these one-on-ones, and I do not cancel the one-on-ones because I can really get a read on how people are feeling and how they're acting and how they're talking about their work and how, you know, are they in, you know, are they excited about it, and it's totally fine to not be excited about what you're working on as well. Sometimes we just have to do boring work that has, just has to get done, but learning these patterns and picking it up early on can help an organization try to push off burnout as much as they can when, you know, you can only control so many factors. We can't control that there's been a pandemic. So, knowing that, bringing those factors in, how can we change the way that we work and how can we change the way that we approach work as a whole to reflect what we need right now?
Lena Reinhard: I do want to add the sort of systems view of burnout as well because I do think it's really important to have these conversations and be open to having them at the individual level, but I think what we've also seen with a lot of organizations, especially during the pandemic, the great example is that there were the emails that said, "Oh, we care about you." There were the messages in Slack that said, "Oh, you're so important to us," but there wasn't a lot of action that followed that. There were not a lot of companies that actually adjusted their goals. There were not a lot of teams that were told, "Hey, we're going to decrease your capacity to just 80% by default, and we're going to assume that your productivity is just not going to be the same." Rather, to the contrary, in many cases, because companies also feared the economic impacts of the pandemic, they actually made goals tighter, encouraged the teams and said, "Well, yeah, we are invested in you, but here are still the goals." And so I do think, in the discourse about burnout, that part is also important. Basically, leaders having conversations upwards about, "Here are the adjustments that we need, here's the capacity that our team actually has. Here is what we think we will need in order to get through this in a way that's okay and that doesn't burn people out in the first place." And I do think I would love to see companies taking more responsibility for that side as well, in the sense of not just saying, "We care," in the same sense many companies care about diversity, so putting the words out there, but also in actually making choices, in making choices about focus, priorities, and the capacity that they're planning for and the sacrifices that they're willing to make because if, ultimately, the goals stay the same during global pandemics or during other big impacts that people have, then we will still continue to have mostly ideally burnout prevention conversations or people burning out, and I would love to see workplaces actually caring about people as human beings in the sense that they're also willing to make the structural and systemic adjustments that are needed for them.
Jean Hsu: I think also you can talk about the, like the different parts of burnout, right? Like the kind of work that energizes you, that drains you, what are the system factors, like we're in a pandemic, right? Like what are the things that, you don't have to say, "Hey, are you burnt out or not," right? You can have like, you know, oh, what, "Pre-pandemic, like what are the things you would do to recharge?" And then help people realize, maybe those things aren't accessible to them anymore. If it was like, you know, travel and social time with friends. If they're like very, you know, conservative and locked down, and like, "Okay, well, what, you know, what do you wanna try? Like, is there something that you wanna try to," like, just help them see that like, the environmental strain has gone way up, and if they're not finding ways to recharge, then like, yeah, it makes sense that you're gonna burn out, right? Like, it's just like, that's just how it works, and, yeah, I forgot where I was going with this, but I think being able to talk about it, not just like, are you, you know, binary burnt out or not is helpful.
Conor Bronsdon: So we're talking a lot about ways that leaders can try to help enable their teams. Leaders obviously burn out too, which I think is an important thing to note and essentially discuss. Jean, you alluded to it, but let's say an engineer feels burned out or worries maybe they're starting to suffer from burnout or headed that direction. How should they have that conversation with their manager?
Kelly Vaughn: If you have a, like a level of trust established with your manager, and you feel comfortable bringing this to them, I absolutely recommend having this conversation with them. I think one thing that could really help is, and you might need to work with them to figure out what exactly this looks like, but if you know specifically what is it that I need right now to course-correct, share those things and work with your manager to come up with a plan that's going to help you and support you and advocate for you to help you get back to a place where you feel like you can work at your normal kind of workflow and address the areas that are contributing to the way that you're feeling burnout. If it is a cultural work situation, it's going to take more than one person, usually, to actually see this change, and, honestly, I can't say that every single company is gonna be like, "Yeah, this is an issue, so we're going to fix it." Like, there are gonna be plenty of companies, as Lena said, like, that are like, "Yeah, you know, I really care about you, but these are the goals we agreed to, so, you know, just, if you can like work, you know, a little overtime just to get this done, then maybe you can take a break. You know, we'll give you something smaller to work on next time." Like, that's not a solution, and you can only-
Jean Hsu: Right, keep your unlimited PTO.
Kelly Vaughn: Exactly.
Jean Hsu: Still get everything you said you'd get done done.
Kelly Vaughn: Yeah, yeah, and this change really does have to start at the top, you know, to allow for these structural, cultural things to change within a company to like, if you have unlimited PTO, are you actually able to use that unlimited PTO? Are you checking to make sure people are using it? Are you adjusting, as Lena said, are you adjusting your goals for the current time to make sure that your team is able to make these changes? But as an individual engineer, these conversations had to be had, they have to be had. You know, it is tough place to be like, "Hey, I cannot give you my best work right now." But an engineering leader who has been coached or trained over time to understand and recognize this, this is not a fault on you, this is a fault on the overall system, and we need to make a change here overall to make sure that this is a good place for each-
Lena Reinhard: One thing I would also say is make use of the benefits and things that the healthcare system makes available to you wherever you're at. That obviously differs very greatly from country to country and region to region, but there are, for example, even in the US, there are ways to get systems, in Europe, or even in the US as well, like you may be able to be put on medical leave for a certain time. Like if you have access to any form of that, like make use of it. If you have access to mental healthcare providers, if you can get therapy, even if just briefly, use those kinds of things too because, ultimately, this is for you, and I do think speaking with your manager is a great part if you have the right relationship and the trust, but also see how you can basically get help outside of the company because this is something that can be really detrimental to your mental health.
Jean Hsu: The willingness and the ability to have the candid conversations is also important for the company, right? 'Cause like, as Lena said, like it's still a company, right? Like, I mean, especially, like I'm at an early-stage startup, right? And so, unfortunately, the burn rate of an early-stage startup and like the timeline of the pandemic are the same timeline, so you can't just say, "Take unlimited PTO, you know, take care of yourself, do whatever you need to do," because people know that there's a limit, and it's, if you don't tell them what the expectations are and what the limit is, they're not gonna take the PTO because it's unclear, like, I mean, maybe a day or two, but like, you can't just say, "Oh, do whatever you need to do," because it's obviously not true. What I need to do is take three months off, right? Like, your job's not gonna be there, and so I think being able to have the candid conversations allows you to talk about options, whether that's, you know, medical leave or, you know, having the option to go down to like four days a week or, you know, half-time or something like that, and then that also allows the company to do planning, right? Okay, does that give us budget to hire a contractor or hire another engineer? Things like that, and like without the ability to have those candid conversations, the company can't do that, you just get burnt out. People showing up every day, not doing-
Lena Reinhard: There's one more thing I wanna add on the systemic side on that as well, which is, that kind of loops back to this whole like devs as human beings topic, which is, a lot of people get burned out on work that's unpaid and unrecognized. Specifically, on engineering teams, it's often the members of underrepresented groups who are trying to hold the team together, who advocate for diversity, equity, inclusion, belonging. It's people who are doing the flu work, I think, fantastic word for it, like holding things together, filling gaps where other people don't do it or don't see them, and that's oftentimes the kind of work that doesn't show up in performance reviews, that doesn't get recognized in compensation increases, and that's often happening in addition to a job they already have, and it's work that people do because they care, because they're invested, and because they want to do the best for the team and the company. So one thing that leaders can do in all that is recognize that kind of work, figure out who's doing it, and also help them do less of it, because a lot of that work should actually be on people in leadership roles. Make sure people get that work recognized in reviews. In compensation increases, make sure that work gets rewarded. Build career paths that include that work, like you can have people demonstrate collaboration and communications skills from junior level onward that doesn't require a senior level as entry qualification, and so making sure that kind of work that often happens kind of in the shadows, but it's so instrumental to how teams work, that that's not the kind of work that people burn out over is a really, really important part of that.
Conor Bronsdon: I think that's a really great point to end on. I know we could keep talking about, you know, this whole topic, but particularly burnout, for quite a bit longer. It's been a great conversation. Lena, Kelly, Jean, thank you all for joining me and for sharing your API for humans with the audience today. I know I learned a lot, and I think everyone in the chat probably is as well, and a thank you, of course, to our audience for the comments, the insights, and discussion. I know it's gonna continue long after this conversation. Thanks for joining us in Interact. I'd also be remiss if I didn't thank our sponsors and the company that's responsible for Interact, LinearB. LinearB helps teams like yours continuously improve by providing correlated data, context, and automated workflows that help streamline code delivery and improve the developer experience, stuff we're all talking about. It's free for dev teams, so check it out, linearb.io, and have a great Interact, everyone. Talk to you soon.
Want to cut code-review time by up to 40%? Add estimated review time to pull requests automatically!
gitStream is the free dev tool from LinearB that eliminates the No. 1 bottleneck in your team’s workflow: pull requests and code reviews. After reviewing the work of 2,000 dev teams, LinearB’s engineers and data scientists found that pickup times and code review were lasting 4 to 5 days longer than they should be.
The good news is that they found these delays could be eliminated largely by adding estimated review time to pull requests!
Learn more about how gitStream is making coding better HERE.
