Kevin Lesht: Welcome to the Day as a Dev Podcast. I am your host, Kevin Lesht. And my guest on this episode is Derek Prior. Derek is an engineering manager at GitHub, working to improve developer productivity. He and the team have delivered such hits as suggested changes, three private repos, community contributors, and GitHub sponsors.
Kevin Lesht: Prior to that, Derek was a development director at Thoughtbot and co host of The Bike Shed Podcast. That's got to be one of my favorite shows. And so I was super excited to have the opportunity of catching up.
Kevin Lesht: Our conversation spanned all sorts of topics I've been curious about, and I think we covered them well. From experiences transitioning from engineer to manager, through the unexpected challenges that came along the way, to helpful advice for building a healthy and productive team. I picked up a whole new perspective coming out of this one. And so I hope you enjoy my conversation with Derek Prior.
Kevin Lesht: 44 degrees out of Chicago, Illinois for this one. Derek Prior is my guest. Derek want to welcome you to the show and ask if you could set the scene for us. Can you give the listeners out there an idea of where you're at right now and what the weather's like out there?
Derek Prior: Sure, absolutely. I'm in the basement of my house in Massachusetts. It's early December so it is cold and there's snow on the ground. We got snow earlier. So my kids have been out enjoying the snow and I've been out clearing the driveway.
Kevin Lesht: Hey, that is my kind of weather and in Massachusetts. You are from Boston, is that right?
Derek Prior: I mean, people who are actually from Boston would take issue with me saying I'm from Boston. But for the purposes of people who live outside of Massachusetts, sure I'm from Boston. I grew up in central Massachusetts and now I live just north of Boston.
Kevin Lesht: Yeah, I was out there not too long ago and went to this restaurant Neptune's. Have you ever been to Neptune's?
Derek Prior: I have not.
Kevin Lesht: It's a fantastic spot. Great crudo. Easy to get carried away on crudo though, going to need a sponsor for the show here to help cover the bill that we tallied out there. But let me tell you, I highly recommend the place, highly recommend Boston in general. Such a cool spot. You're looking around at all of the buildings out there. A lot of craftsmanship, you can tell and I know that somewhat recently on craftsmanship, you have taken up woodworking and was curious about if you're still keeping that up, as hobby and if you've had any projects of note lately?
Derek Prior: Projects of note? Yes. So the answer is not as much as I would have liked probably. Getting settled into a new job and some new teams at my new job which wE'LL probably get into a little bit took a lot of my energy. But I'm still very much into it. I've done some small projects, I made a pretty cool bench, which I'm very proud of and sits out on my front porch. It's not the most comfortable sitting bench but it's really nice to look at.
Derek Prior: So I did that. I signed up for some courses, some online courses that are like take at your own pace kind of things. Really like that. My wife has been asking me to create some floating shelves for our family room, so I'm going to get into that very shortly. The other thing I really like about woodworking is it's probably no surprise to a lot of woodworkers is the gear. I like all the equipment. So right now I'm very much in shopping for a table saw mode which I've set out as a prerequisite for the floating shelves that my wife wants done.
Derek Prior: So I'm spending a lot of time investigating table saws and things like that and deciding between the cheap get yourself started saw, and the more expensive saw that prevents cutting your finger off.
Kevin Lesht: Yeah. Good thing to research there. Make sure you get the right one.
Derek Prior: Yeah, I'll probably go with the cheap, don't go with the more expensive don't cut your finger off.
Kevin Lesht: Right. Yeah, as far as coursework goes too, have you ever watched shows like This Old House is that a...?
Derek Prior: I have a This Old House story. I love that show. I've loved that show ever since I was a kid. Like, I like that show, there was another show called Home Time that I watched all the time when I was in high school. I just like watching people. I think what it comes down to, is I like watching people who care a lot about their work and like to talk about it. Which maybe is related to why I did a podcast for quite a while.
Derek Prior: But at one point when my wife and I bought our first place we were having a problem with the floor and I sent a picture of it and an email to Ask This Old House, and months went by and never heard anything. It was just like a lark and ended up, many months went by, ended up having it fixed, like paying somebody to come in and fix it. And maybe a couple weeks after we had it fixed, I get a phone call and it's from a producer on Ask This Old House who was like, "We wanted to talk to you about your floor?" And I was like, "No, I fixed it." So I missed my shot to be on Ask This Old House.
Kevin Lesht: Yeah, that is fantastic. The only thing that surprises me about that story is I would have imagined it's the carpenters themselves that are, like in my head, I would have imagined they all seem like such down to earth people that they're the ones reading the email inbox, getting back to everyone who writes in.
Derek Prior: It was somebody who definitely identified themselves as a producer, but it was also somebody who clearly knew what they were talking about. Because he was like, he wanted to know what the fix was. And he was like, "Yeah, that sounds right," like that.
Kevin Lesht: Yeah.
Derek Prior: So it was still somebody definitely trained in what they were doing.
Kevin Lesht: That is great. Yeah, the This Old House there's an episode with Nick Offerman, the comedian famous for Parks and Rec, and all sorts of other good stuff. He's a carpenter too. And he comes on the show and he says something to the extent of, "If you take a bucket of nails, and a few planks of wood, and you slap together a dog house, congratulations, you are a woodworker now." And I love that quote. And I love what's behind that quote, just the idea of anyone can dig right into something and immediately embrace that thing as part of their identity.
Kevin Lesht: Because I think it applies closely to software development as well. You know, being able to scrap something goofy together, with some raw materials and then just as you might pick up some new tools, new table saw, or some new technique with woodworking, same goes for furthering any piece of software too.
Kevin Lesht: And to help out those looking to build maybe their first dog house, and also to help those looking to maybe build out an addition, or even just keep the thing standing up, I thought we could focus our conversation here around things like onboarding and things like ongoing processes as well, with your experience coming from a long tenure as a consultant at Thoughtbot now working at GitHub and everything else you've been involved in.
Kevin Lesht: And so maybe to begin, I wanted to dig right in to an article that you forwarded my way which is Give Away Your Legos and Other Commandments for Scaling Startups by Molly Graham. And you know what's funny, I've read this thing twice now. And the first time, I certainly picked up that, and I think I sent you an email after I first read it and certainly picked up that it's framed around, offering advice towards those building out a team and the pain points that you can run into when doing such a thing.
Kevin Lesht: But I read it through my lens, which is someone who has experienced the team scaling from the inside. And my takeaways were focused around the perspective of me, where my role certainly has evolved, but not in the sense so much of moving from a contributor to that of mainly a people manager who's not involved in the code base as much anymore. And then I have a conversation with one of my mentors, my boss, Dave Giunta, and he saw a whole nother layer there that was positioned around more of what I'd like to talk with you about. And that is the transition from an engineer, an independent contributor in a code base, to that have more of a manager, someone who is focused less and less on driving forward that feature work.
Kevin Lesht: So I'd be curious to learn about your transition there from engineer to manager, and also maybe stemming off that too, some of the difficulties that you may have noticed and faced in that move from being an engineer to graduating towards that of a manager?
Derek Prior: Yeah, absolutely. Where should we start?
Kevin Lesht: Hey, there's a lot to dig into there, whatever hits you first.
Derek Prior: Yeah. So I mean, I sent you that article, and I had a lot of reactions to it. I can't, I'm pulling it up now. I'm trying to see like, maybe I'm misremembering, but I feel like I read this a while ago. I'm trying to find like a publication date. I really don't like when they don't put a date prominently somewhere.
Kevin Lesht: Yeah, I have it up as well. I didn't see a lot of metadata like that in there at all.
Derek Prior: And they may be a misremembering, but I recall reading this quite a while ago, in different circumstances and finding things that spoke to me about it. And then reading it again, under recent circumstances and finding similar things that spoke to me in different ways. And so I think that yes, it is written from this is how scaling a startup works. But to me, it's really about any... what speaks to me about it as any time in your career where you go from having total control over something, or the illusion of control over something, or comfort. Control or comfort, I guess, to handing that off to somebody else, so that you can do a thing that is like maybe you don't even know what the next thing is going to be yet. Or maybe you're scared of what the next thing is going to be, because you're not quite sure how to do it. You know you're good at the one thing you're doing right now, that type of thing.
Derek Prior: So when I like, in line with your question there, it kind of makes me think of when I originally joined GitHub, it was to come from I had been a director at Thoughtbot, which is kind of a, it's a people management role, but still very much also building on client work. And the people management you're doing is more like a mentorship and coaching than it is like managing somebody's direct work because they're out on client projects and things like that.
Derek Prior: So I came to GitHub and had a good grasp on the technical bits of the project we were working on, but it wasn't clear to me immediately like, what are the higher value things I should be doing as a manager? Like what are the things, maybe a higher value is probably the wrong word, but like, what are the things that I as the only engineering manager on this team should be doing that... and leaving the stuff that I'm doing that are really any of the four other developers on the team can do, for them to do?
Derek Prior: And so I struggled with that at first because it wasn't a, I wasn't sure what it was I should be doing and b, doing the development was something I was confident in, right. So it's like, I know how to do this. I know I'm good at it. I see very much that the work I'd like to do is like somebody needs to do this on the team. So I can do that.
Derek Prior: And over time had to pull myself away from that to realize that I'm not... like I should be letting the four other engineers on the team do most of this. And I've been slowly stepping away and trying to focus on other things.
Derek Prior: I just recently went through a similar transition on one the teams I've been working closely with for the last I'd say something like six months or so. I've been working with somebody who... Her name's Katie, Katie Delfin. Hi, Katie! She wanted to become an engineering manager, had been an engineering manager previously, wanted to become an engineering manager at GitHub, but was currently in an IC role. And so she let me know that like as soon as she joined team that that was something she was interested in.
Derek Prior: And so we started going down a path of like, "Okay, well, if you're interested in that, here's the type of work that engineering managers do at GitHub, I can hand this over to you. And I can delegate this to you, and you can start doing some of that work." That worked really well, but there definitely was a moment in there a few months in where it was like, "Katie's doing such a great job at this, what if they don't need me anymore, right? Like, what am I going to do?" And the article has that very specific fear, it confronts that very specific fear in people. If this person does what I'm doing right now so well, that they're ready to take it over, what do I do next?
Derek Prior: And reading this article just reminded me that there's always other things for me to be doing and part of my job is to find people who can do things that I'm good at, as good or better than I can, and that that's okay.
Kevin Lesht: There's just so much to dig into there. Wrote down a couple points that I'd love to circle back on. But maybe the first play off of that last piece you just mentioned, which is there's just so much to learn out there. And I think embracing that whatever lane you are currently in has so much to offer, is a huge thing.
Kevin Lesht: I think back to my first read of this article when I was approaching it from the position of just an independent contributor and not thinking of that perspective of a manager. I was reflecting back to my time as a consultant, more so a design consultant, my background delivering essentially marketing sites backed by content management systems to clients, small businesses and startups.
Kevin Lesht: And I remembered back to, I can't remember how many It was at this point. But there was definitely a stretch where I was first starting out that you build these sites, you invest so much time into the design of them and then by pairing them with a content management system, you sort of need to because you don't want these clients unless you're looking for that residual work to call you up for every copy change or image substitution or anything like that.
Kevin Lesht: But by giving that flexibility, that first stretch it's painful when you see some clip art subbed in for the image that you searched for, for hours to just fit the theme so nicely. But then I guess you go through a few of those reps, and you eventually I think, I don't know if you just internalize that this is a thing, and you just got to let go and end it off and remove yourself from it. Or to circle back on what you said just also realize that there's just so much out there, let that one go and focus on what's in front of you.
Kevin Lesht: But I definitely remember that feeling of attachment to the deliverables that I was handing off. And I do think that was difficult to shake for a while. The other points I wanted to circle back on were you mentioned that for a while, when you were first starting out, you had to figure out what exactly you should be doing. But then it sounds like when you had one of your teammates come to you and mention that she wanted to move from an independent contributor to manager. By that point, you had a good idea of the work and you were able to relay what that scope of responsibility would look like as far as making that move.
Kevin Lesht: So I wonder for those senior engineers out there, could you speak a little bit to those that are interested in pursuing a management track? How can they go about getting a feel for the practicality of such a position?
Derek Prior: Yeah, I think by the time that Katie and I had that conversation, I had a better idea. And being an engineering manager's different at a lot of different companies. Like there's some folks where you'll purely be a people manager, and you'll have product and project managers who handle like the planning of the work and things like that. And there are some roles where it's a sort of a hybrid, like it is at GitHub. At GitHub my role as an engineering manager has like I manage the projects, and I manage the people. And those are kind of two separate, like there's a case to be made that those are two separate roles, right?
Derek Prior: So for people that are interested in what's it like to be an engineering manager? I think that's pretty common for engineering managers to play both of those worlds. So we'll pretend we're in that world for everybody. And what I suggest is two things. So number one, the easiest thing as a senior IC or senior individual contributor to get experience in is leading projects on your own, right?
Derek Prior: So handling things like the project, handling the project management aspect, right? Making sure you take large stories and break them down into smaller stories that you can disseminate among the team, being accountable for reporting high level status to any stakeholders, it might be at your manager or you know, other people in the company that want an update on what's going on in the project.
Derek Prior: Basically allowing... Like, I know somebody is doing a really good job of this, if I can just say like, "Oh, that project. Yeah, I know what's going on at a high level because I've been apprised, and if you want details, then yeah, just go ahead and talk to so and so. I know they're doing a great job on it, they'll give you all the details you need." And so I think that that's probably the easiest part of the work for a senior IC to maybe even already have been doing that without even thinking about taking on the management aspect, right? It's common for IC's to step into that role.
Derek Prior: And then the second part which is harder I think to dip your toes into like this is the people management aspect of it. Because you can tech lead projects, which gives you a taste for the planning, but how do I know what it's like to manage somebody, right? To have somebody bring me their interpersonal problems or frustrations with promotion and things like that, that might come up? And so I've thought a little about this, and I think the easiest way for most people to get this experience is like if your organization has interns or junior engineers, and things like that, volunteering to mentor them, and spending time really like not just being like, "Yeah, yeah I mentored the junior engineers, I helped them handle their tickets. And that's what mentoring means to me."
Derek Prior: But actually digging in and spending the time about like, what does it mean to be a good mentor? And then going further than that, like, how does mentoring somebody differ from coaching them through something? And when is it appropriate to do either one of those things?
Derek Prior: So really showing a care for that aspect, like you show that you care for the technical aspects of your job, right? Because that's going to start to give you that experience of what it's like to do those things. And if you can imagine doing both of those things for a team of somewhere between four and eight people or something like that, then you'll have a good idea of what it looks like.
Kevin Lesht: That is super helpful. Yeah, I'd love to dig more into the mentoring, the coaching angle of things and all that comes with that. But maybe before we move there, one thing I'd be curious about too, I think what comes with making or at least seemingly what comes with making that shift too from going about working within the code base to then this position of working more indirectly in the code base through your juniors, and your mentors has got to be just a lot of surprising and unexpected changes.
Kevin Lesht: I think too, it's funny, there's an episode I just listened to of the Jason Calacanis, his podcast. He's interviewing, I believe, it's Alex Maccaw, who is the CEO of a company called Clearbit and they talk about something similar, which is issues individuals face when they move from their focus position. So say coding engineering, to that of management and it's a thought pattern that can be a trap which is you maybe see some difficulty, some challenge happening out there. And the person who was previously maybe a high performer as independent contributor falls into this trap where they start thinking, "Oh, you know what, I was able to get through this by putting the team on my back. I took the ball, I put it in the basket, and we won the game. So maybe I need to insert myself into this problem a little more closely and try to just solve this, take this on myself."
Kevin Lesht: But he mentions that what gets you to that level of maybe a high performer as an independent contributor, doesn't necessarily translate to then being an effective manager, an effective leader of your junior, your apprentice level, or even more senior members of the team as you become a more developed manager.
Kevin Lesht: And so I'd be curious what, if you faced any challenges like that and what attributes, what tactics maybe helped guide you through those situations?
Derek Prior: Yeah, I mean, I think you hit the nail on the head with that story there of like, the first time there's any adversity that you think that previous individual contributor you would have like, saved the day, right? The temptation is to be like, "Okay, but I'll become player coach here. I'm going to substitute myself in and we're going to get this over the line." But that really robs your team of a growth opportunity to face that adversity and play that role that you had played previously, or maybe have a couple people together play that role that you were playing previously, which is probably more healthy, frankly.
Derek Prior: So you're robbing that team of that opportunity. And you're also robbing yourself of the opportunity to coach them through these things, right? This is the skill that you're going to need to develop. Because you will not, like when you first become an engineering manager and you have a small team with a small number of projects, you have time to do that frankly. You can become the player coach for a little bit where you need to, but then as you take on, as you become more successful as a manager, the company is going to find more ways to put more people and more projects under your purview. And you're just not going to have that opportunity. So that doesn't scale.
Derek Prior: And the people who are looking at your successes and failures above you may not recognize that, oh, the reason you're succeeding is because you're actually not managing this team. You're just like player coach, I guess, I'll keep using that metaphor.
Derek Prior: So that's one thing I definitely experienced. And in my case, as I mentioned before, it was a little bit of a conscious effort to be like, I should probably be finding the things that, you know, are uniquely things that people in my position are supposed to be focusing on. And leave the coding work to other people. But it was also brought on by just like more of the non coding work came up that needed to be done, and as I understood more of how my work fit into GitHub, and things like that. Recognizing that like, there's this to be done, there's this part to be done. So it's a combination of a conscious choice and just being forced out of it.
Derek Prior: When I think about challenges of transitioning to management, there's one thing I wasn't ready for at all. Because I had thought a lot about when I transitioned to management like, do I want to do this, don't want it become further removed from the code, or do I want to... Those were challenges I was anticipating. What I hadn't anticipated is that it can be a very lonely job. So, if you're the type of engineering manager that's still regularly committing to code, then you have that camaraderie with the other developers on your team. But then, as you start removing yourself from doing that, you find yourself that like you're the only person on your team that's doing the work that you're doing, right?
Derek Prior: So if you have just a silly idea, you want somebody's opinion on about some process thing that you're thinking about trying out with the team or something like that. There's nobody with your exact context to turn to and be like, "Hey, what do you think about this thing." Like you can when you're doing development work where you can say like, "Oh, I know you were just in this part of the code base last week, I got this idea for how to approach this thing. What do you think about that?" And sure, there are IC's in your team who would love to weigh into that, but like, they're not thinking about it from the same direction you're thinking about, as somebody that's in your exact role.
Derek Prior: So that was one thing that I didn't even really recognize that that was a hurdle for me until I started working with Katie closely on that team. And she was taking on more and more of a manager role. And through her suggestion, she was like, why don't we set up some... Like we have our weekly one on one time, we had some great conversations there. But why don't we also set up some like weekly manager pairing time. Where we would either just have an extended conversation about what's happening or we would like dig into actual tasks, like we would do some backlog grooming together, right?
Derek Prior: It's not fun. It's not like the most fun pairing I've ever done, but it was just like, there's so many of these issues I've been looking at and then like on the fence about what to do about and just having another voice here be like no, no your intuition is right, do that thing, was super valuable.
Derek Prior: So the lesson I took from that really is that when you're going to become an engineering manager it can be very, you know, your default mode of operation here is probably working with your direct team of like, I don't know three to six developers, maybe have a designer or maybe a product manager or something like that. It's a very like you've got your group of people right? But I think you need to be intentional about also making sure you're networking with other engineering managers, finding time to do, I think the engineering manager pairing idea was brilliant. Finding people to put in your circle of engineering manager trust and just making sure you develop those relationships as well.
Kevin Lesht: Holy cow that is super revealing. I feel like it is until you're exposed to a perspective like that. I mean, it's hard for me to empathize with something like that just because I'm not there yet myself of that, you know, you mentioned earlier in that piece there that, and you're totally right, when you're an engineer if you hit a tricky problem which is mostly going to be related to something technical, there's a camaraderie there, there's a team around you to help triage that to help work through that. But I think too, people, I assume, issues of people management are certainly more complex and way more unique to their surroundings that, yeah, I can now see the angle of loneliness there that could come from that.
Derek Prior: I think there's also a large part of this that is interwoven with also working remotely, right? So it's not that when you're co located with your company, right? You will have with no effort on your own part, you will have a chance to speak to other people in your role, right? And you'll just have those natural conversations.
Derek Prior: But when everybody's at their house or at their co-working space or whatever, it's just a little bit more friction to get that conversation started. Like you got to be like, "Hey, is now a good time for you to jump on a call with me, right? I'd really love to get two seconds worth of your time." And so that's why I think having something like if you're going to do this remotely, I think it's probably more isolating. And so it probably pays to just have like some regularly scheduled time with people that you trust as other engineering managers and that you want to build your circle of trust with.
Kevin Lesht: Absolutely, yeah, that sounds like fantastic advice for those in those positions. It makes me think of too, I want to have some conversations now with product managers, because when I was thinking about, when I was trying to build some laterals to what you were saying there since I'm not in that position myself. The only thing I could quickly pull up was, I have to imagine, I wonder if product managers feel this way where typically a product manager is going to be working within a domain of a business and their problems are going to be somewhat specific to whatever discipline that is they're focused on. Whether it be maybe marketing or some other channel. And yeah, I wonder if they fall into that similar situation where there's a loneliness of how do I break down this ticket, or how do I work with this stakeholder? And I'm sure there's a lot to be maybe learned between engagement from both sides there, yeah.
Derek Prior: Yeah, definitely. And I have found that on the teams that I work with, the product manager has been a good partner to also address some of this loneliness with. Like we don't have a very, with the product managers I've worked with, we don't have a very strict like, "Oh, that's the engineering managers job versus this is the product managers job." Other than like the product manager doesn't manage my people, but when it comes to the work, the product manager might break down tickets, the engineering manager might break down tickets. The engineering manager might make a few product direction decisions. By and large, the product manager makes those decisions, but I would find myself in situations where I'd be faced with a question, I'd just be like, "Oh, that's a product decision."
Derek Prior: And when you say like, that's a product decision you're thinking like, "Oh, the product org makes this decision, product people make this decision." But when you think about saying it, like, "Oh, no, that's Devon's decision." Then you're like, "Well, Devon's, just one person, she might want to talk through this, right?" Like, there's nobody else like, "Yeah, there are other product managers at this company. But nobody else has the context. Like, I'm probably the closest person that she should talk to about this. So maybe we should get on a call together. Because I have some of the context." And I can just be her rubber duck in that case. And if I think this is a decision that is largely in her court, that kind of thing.
Kevin Lesht: Yeah.
Derek Prior: But I have to imagine you know, I haven't specifically brought this point up to the product managers I work with, but I have to imagine it can be a similar experience there. And I know for sure like, again, not specifically having brought this up designers, but I remember, I'm hearkening back to my days at Thoughtbot. And I remember how excited designers were when they worked on projects that had multiple designers, right?
Derek Prior: Because most of our projects had two to three developers on them and like one designer, but every once in a while, we'd have like two to three developers and two designers. And it was like, the designers always love that. It makes 100% sense, right? And like the projects where we did only have one developer, like people would complain to me like, I don't want to be the solo developer on this, right? So we're social people. So even if you're introverted or extroverted, just having that social support is important.
Kevin Lesht: Yeah, it seems like too the calling back in a few things that we've talked about so far. A thread across all them seems to be embracing your situation and just understanding that it's a new experience. It's a new thing to learn from and to take on as a challenge even going back to I think where this conversation here started. When you're in a position of management you see some adversity out there, rather than jumping in and just tackling it yourself, looking at it in the sense that this is just a new different kind of challenge and that you have to now figure out how to solve this from a different seat.
Kevin Lesht: As far as those new challenges and new experiences go, you mentioned during an episode of The Bike Shed Podcast that every time you would start a new consulting project at Thoughtbot, it was like starting a new job. And so drawing from your experiences there, I was wondering if for a little bit we could dig into some of the things that have stuck with you in regards to what makes for successful onboarding, and two sides to that topic that I'd be curious to hear about those being, things that organizations can be doing to better that experience, and also things maybe individuals themselves can take on to help the next new hire get up to speed a little quicker, and make it just the whole end to end process better for whoever joins next.
Derek Prior: Yeah, absolutely. Yeah, I mean I definitely, I remember saying those things about feeling like I'm starting a new job every time I start a new client project. And I think that I remember that episode and I think I was largely thinking about it from our perspective of like I'm always starting a new job, I'm always figure out how to run new projects. I was thinking about it from a very technical aspect, and a little bit from the like, how do you figure out what process a team is using to ship things and things like that, a little bit of that.
Derek Prior: And so my advice on that, which I still definitely believe strongly, but it's a little less applicable to me day to day it's like, hey team's should have setup scripts, right? I should be able to like clone a repos, run a script and it should work from... particularly like a lot of teams just use like one type of hardware, where he's using Mac hardware for local development, then it should just be super simple to get started, right?
Derek Prior: And if you can, ideally should be like even testing that script as part of your CI, because you're only ever going to run it when somebody gets a new laptop, or has the nuclear setup, or a new person starts. So it might not be run regularly, but it's super valuable to have that available to you at all times. So you don't have to reinvent the wheel every time a new person starts. We're like, "Oh, nobody's run that script in three months, it might not work."
Kevin Lesht: Yeah.
Derek Prior: So those I think, were the original angles I was coming at that from, but lately I've been thinking about this more organizationally, like you mentioned. Thinking about it a little more broadly. And so like, the questions I think about are like, how do you make new employees or team members? Like, maybe they've been at your company before, but not on your team? How do you make them feel part of your team? And then how is that impacted by remote teams? Because, we work remotely at GitHub, so.
Derek Prior: And then things like, what kind of information do they need to know that's not like the technical information that I just talked about? Like is there cultural information that they need to know? How much information is too much to give somebody at one time? And how do you remember to circle back and give it to them at the right time? How do you create this onboarding, ramp experience? That's related, right? Where you're just like, "I could throw a whole bunch of information at you at once, or I could create this like, hey, it's week one. Here's some things that have been helpful to people in week one. It's week two, here's some things that have been helpful to people in week two. And things like that. So I've been spending a lot of time on those questions. I don't know if we want to dive, should we dive into some of those?
Kevin Lesht: Hey, I would love to. Yeah, I'm super curious too about how, especially with the remote angle, how that plays into junior developers coming aboard? We talked about earlier developing those mentorship and coaching, the distinction there and also developing those relationships. I'd be curious about how those lineup, what your perspective is against how those fit in to the onboarding process as well? And what are some curves maybe that even a remote relationship throws in there.
Derek Prior: Yeah, definitely. One of the realizations I had working... this is my first job working full time remote. I'd had some client projects where I was remote from the client team. But those were pretty short lived, and it's different when you're a consultant.
Derek Prior: Yeah, I mean, I think there were a couple times where I realized like, "Oh, you know, what's hard about mentoring or coaching junior or less experienced developers at GitHub is that at Thoughtbot, I could look across the room." And Thoughtbot had a very, one of those open office plans. So I can literally just look across the room and be like, "That person looks stuck," right? And I can pick myself up, walk over, sit down and be like, "Hey, what's going on? Oh, you're struggling with that? Oh, let's just sit together and let's just like figure it out together," right?
Derek Prior: And a little bit related to what I was talking about before with the loneliness of being an EM sometimes, right? It's just like it takes a little more effort when you're remote to make sure you're checking in and make sure they know it's okay, or even just saying like, "Hey, oh, yeah, let's just jump on Zoom and let's look through this together. Let's talk through it." That kind of thing. It takes just a little bit more effort. I think that's the most I can say about the remote aspect of that.
Derek Prior: The mentoring and coaching part, once you get over that inertia, and you actually start the conversation. I think, remote teams, it's a little bit harder to build the foundation of trust, I think that's needed, or trust and familiarity, I think. Because you lose those chance for just the everyday runnings at the water cooler at the lunch table and things like that.
Derek Prior: So I'm conscious of that trying to make sure that the first few one on ones we have I focus a lot more on like, tell me about your life? I remember my first manager at GitHub, Nada, the very first question she asked me in our first one on one was,"Tell me your life story?" And I was like, I don't start with that because I was paralyzed by that. I was like, "What do you mean my life story? How much detail do you want? When should I start? Should I start at birth? Do you want to know like? Do you want to know my professional story? Do you want to know?" And she was just like, "Whatever you want to tell me." And I was like, "Oh my gosh." I was just totally overwhelmed.
Derek Prior: But I appreciated the angle that the question was coming out. I definitely appreciate the question too. It's just like, my personality was like starting to panic about that a little bit. But the angle she was coming at was just like, it's we have so much time and I've never really specifically talked to her about this, but in my experience, what I'm thinking that she was coming at this was, we have so much time to cover the nuts and bolts about getting work done here at GitHub, but none of that's going to matter if like we don't know each other as people and trust each other as people and respect each other as people.
Derek Prior: And so getting to know like, "Oh, where do you live? What's it like where you live? What's your office look like? What's your house look like?" I took somebody who reports to me, Mike. I took him on a tour of my house like with my laptop.
Kevin Lesht: Really?
Derek Prior: And just like, this is my living room, here are my kids, like the whole thing. And I think silly things like that are important. Because just like forming those personal bonds, and then the rest of this stuff, once you have that foundation of trust, then you can move on to other things where you can get into a little bit of the nuts and bolts and things like that.
Kevin Lesht: Yeah, I think that making sure those... it sounds like for fully distributed teams, each individual sort of shares that same situation and that they are remote. And so there's a mutual understanding there that everyone is trying to close that connection.
Kevin Lesht: I think even it's even more important for teams that might only have a single individual or a couple individuals that are remote. We have at Home Chef, a couple co workers who are full time remote with the majority of the team being in office. And I know something that during our retros, my close team has gotten feedback on as appreciated, was just bridging the gap by forwarding on some of those funny things or even weird happenings that might play out in the office.
Kevin Lesht: One thing that comes to mind is, I've been known to crank out a side project or two of questionable substance. And just forwarding those along. I might spin up over the weekend on omelette Blog, it wouldn't be a podcast episode if I didn't self promote the Omelette Blog out there. Even sending that along, check out this thing I built over the weekend or forging some personal connection that is outside of the back and forth of everyday work. I think that something that I can only look at as a person who is in office and surrounded by my co-workers, but could absolutely see as really help to connect with the person behind the computer there, yeah.
Derek Prior: Yeah, I mean, I think we have in many ways we have it pretty good at GitHub in that, there's still a lot of people, there's still, I think, what is it? Something like 30, 35% of the company that works from the San Francisco office. So it's still a large chunk of people who work in the San Francisco office. And I've worked on a couple of teams in the year and a half or so I've been at GitHub where multiple people were located in the San Francisco office, but it's not the norm at least on engineering.
Derek Prior: So I think we're pretty used to even when there are two people that are in one place and the other people or not, so much of the cultural stuff happens in Slack or in Zoom and things like that. Like when you were talking I was reminded of a conversation I was having just I think it was yesterday in one of our slack channels. We have our work Slack channel where we talk about work and funny things related to work. And then we just have our off topic channels where we're a little more free.
Derek Prior: And one of the things I was talking about was like, "Hey, my family really wants me to set up a wish list for Christmas. And I literally think that I have everything I could possibly need, and I hate doing this. What are some cool things that you've gotten as gifts or that you have in your life that are less than $30 that I should put on my wish list?" It's silly things like that, stuff that you might talk about at a lunch conversation, but just making space to have that. Or people sharing pictures of their dogs and their cats, and people learning the names of each other's dogs and cats and kids and wives and things like that.
Kevin Lesht: I dig that. Yeah, drop the Omelette Blog in there for me. See how that plays.
Derek Prior: I will.
Kevin Lesht: No, I think it's helpful though, to get a sense for everyone's personality, because I think it then does play back in the work that we do involve ourselves with every day. One of those being pull requests. Maybe one of the final things that we could step through here, as I do want to get you back to, did you say you were shoveling the driveway before the show started?
Derek Prior: Oh, no, that was yesterday. So, the driveway's shoveled. We're good.
Kevin Lesht: Yeah. Well, then the woodworking project then, but so much to dig into here. One thing I didn't want to leave the session without hitting was you have a talk out there that is implementing a strong code review culture. Love this talk. I think that it would be beneficial for anyone joining a team to check it out.
Kevin Lesht: It's focused around just how you can carry yourself to develop productive conversations within a pull request. And yeah, circling back, I think that just getting a sense for everyone's personality can really help you maybe understand what might be going into someone's comments. I think back to one of my co workers who once said that if you ever have to leave maybe a dicey PR comment, just tack some emojis on there to lighten the blow.
Kevin Lesht: But I think maybe it was said in jest, but I think what your talk frames are better, is there's a better way through all of that, which is maybe incorporating something like the Socratic method, which is framing things more around questions like what do you think about this? Or is there... things along those lines. And really liked the advice you offered there, and was wondering, that talk was a while ago, and we would be curious about, now a few years later, wanted to challenge you a little bit as an extension of that talk.
Kevin Lesht: Say you're framing your questions as best as you think you can, in a productive way. And maybe the pull request author isn't necessarily receptive towards those suggestions, or there's or maybe even the commenter isn't... there's a difference of opinion. I'm wondering from your lens of a manager now, what some tactics individuals can maybe invoke to try to resolve and just promote amenability in those situations?
Derek Prior: Yeah, sure. The first thing I recommend to people is to stop trading comments on GitHub if it's possible for you to do that. Once you've gone back and forth, like once you've made an original comment, there's been a follow up, you made another comment, and there's been another follow up, you've probably gone about as far as you're going to get with a comment on GitHub. And so once things reach that point, I generally try to say like, "Hey, maybe just have a conversation about this. Hey, why don't John, Sarah, and I get on a call together and I'll just get you guys, get you all... I'll get you off kick started and then I'll recuse myself, basically." Because I don't want to insert myself as the arbiter either, right?
Derek Prior: And, one of the things I've learned through trial and error here is one pattern that's easy to fall into is like, "Oh, okay, so John and Sarah are having a disagreement on this pull request, and I'm their manager. I'm John's manager, I'm Sarah's manager. Well, let me meet with John. Let me get John's side of the story. Let me go meet with, Sarah. Get Sarah's side of the story." And then somehow through that present to them parts of each other's story and hope that it works out. Like that's not... or what am I supposed to do? Am I supposed to make a decision? I don't, you know, it's not really my job. I don't think that's my job, right?
Derek Prior: So I think instead, it's more productive to just say like, "Let's just get people together." And let's talk about whatever the issue is. Let's come up with a path forward here. Let's make sure that each that John can you represent what Sarah's... I might not be as formal about it here, but you might say like, "John, can you start by telling me what you think Sarah is saying? Sarah, can you tell me what you think John is saying? Why is this important to each one of you? What do you think the consequences of going one way or the other are? If we make the wrong decision here, how will we know? And what will the cost be?"
Derek Prior: Those kinds of things and trying to center those things. And ultimately falling back to one of the values I took from Thoughtbot and code reviews is the ultimate decision on what to do lies with the person submitting the code, right? So ultimately, you're going to the one that deploys this code, you're going to be the one that's going to respond when something goes wrong, hopefully, if assuming it goes wrong quickly after you deploy it. Sometimes you deploy time bombs.
Derek Prior: So, it's on you, and if by and large I think that's enough for most things, is to say like, "Yeah, we've had a conversation about it, I hear you. I'm going to go in this direction." As long as we've had that conversation, particular if it's contentious, some of those points that I was talking about just earlier, as long as we had those conversations, that's probably going to work out, okay. If it doesn't work out okay and it keeps working out not okay. Say like John just keeps messing up, he's not taking Sarah's feedback, and he just keeps messing up, then we're into more of a coaching, mentorship situation where it's like, "Okay, we had this conversation, things keep breaking in the ways that Sarah is predicting they're going to break. What do you think we should do about that?"
Kevin Lesht: Yeah.
Derek Prior: We need to see some improvement there. So, yeah, I mean, I think that just again so much of this boils down to communication and kind of knowing when to say like, "Let's just have an in person conversation if we can or over the internet conversation. Let's just change, we were doing text, let's do voice. Let's just change that a little bit."
Kevin Lesht: Yeah, maybe think back, what I had paired with this question that I had written down that I think plays into whether it's a PR comment or a conversation along those lines is, I can't place where I picked this up from, but it was an article focused around productive, technical conversations.
Kevin Lesht: And it was like, whenever you are leaving feedback, it should have purpose, direction and motivation. Meaning that there should be a good reason for why you're picking out this piece of code to comment on. It should have some direction and that you certainly as you mentioned, don't want to solve the problem for the author themselves, let them embrace that challenge, but you should give some direction towards whatever you're getting at there.
Kevin Lesht: And then also some own motivation. Maybe why it would be beneficial to change whether as you mentioned, if it's like a recurring problem maybe some behavior that could be better there or if it's just a one off thing, here's a performance gain we could benefit from, or something like that.
Kevin Lesht: So yeah, so much to dig into there. Maybe, we set you up for a sequel to your talk there. I'd like to see it. I'd also like to see another episode here. I think we'll have to tee one up again in the future. But as we wrap up this session here, Derek, do you have any parting thoughts reflecting on our conversation here for our listeners out there?
Derek Prior: This was a lot of fun. If you want to do it again in the future, I'd be happy to do it again. And yeah, that's it. I think, if there are people out there that are interested in toeing that line between management and individual contributor, I hope that I was able to offer some sort of clarity there, or some sort of helpful advice, but I love talking about these things. So if people want to reach out and just get a stranger's opinion on the internet I'm happy to help out.
Kevin Lesht: Hey, no, that was fantastic. And with the year coming to a close here, I certainly am going to pull quite a bit of this into my own performance review. So I appreciate it. And I appreciate your time. Thank you for joining the show. And thank you for your time.
Derek Prior: Thanks for having me.
Kevin Lesht: For show notes, and more on this episode, head on up to the site. That's dayasadev.com. While you're there, check out our release notes. This is a short newsletter that we send out about once a week. It includes updates along with all sorts of other goodies packaged up for your inbox. Thanks for listening for the Day as a Dev podcast. I'm Kevin Lesht.
