Mike McQuaid (GitHub)
Today we have a great guest to talk about his transition to, and current role as, a staff engineer: Mike McQuaid from GitHub! Mike is also a project leader at Homebrew, and brings a wealth of expertise and experience to the table, as well as the obvious added perspective that any engineer from the GitHub team would have. In our conversation, we get into a bit of Mike’s journey up until now, the period of stepping up into the position of staff engineer, and how his time spent with open-source projects has influenced his other work. Mike gives us a good rundown of the different levels of leadership that exist at GitHub as well as painting a picture of the way he prefers to oversee engineers and projects. We talk about the healthiest ways to prioritize and tackle work and get into the sometimes murky waters of impact and value measurement. We ask Mike about what it is like working at GitHub where the people building things are also the ones using them, before discussing some thoughts on mentoring and sponsoring, OKRs, and the resources that have been most useful to Mike along the way. Tune in with us today to hear it all!
Links
Listen#
Transcript#
Note: This transcript was generated using automated transcription and may contain errors.
David: Welcome to the Staff Eng podcast where we interview software engineers have progressed beyond the career level into staff levels and beyond. We’re interested in the areas of work that set staff plus level engineers apart from other individual contributors. Things like setting technical direction, mentorship and sponsorship, providing engineering perspective to the org, etc. My name is David Noel Romos and I’m joined joined by my co host Alex Kessinger. We’re both staff engineers who have been working in software for over a decade. Alex, please tell us a bit about today’s guest.
Alex: Our guest today is Mike McQuaid. He is a staff engineer at GitHub. Additionally, he’s a project leader for the Homebrew project which is a package manager for Max. This interview is a lot of fun.
Mike: I got a kick out of what.
Alex: The GitHub monolith is called. And on top of that, I enjoyed hearing about Mike’s work. I think others will enjoy it as well. Let’s get into it.
David: Mike, it is a pleasure to meet you. Thank you so much for taking the time today. If we could start by having you tell us in your own words who you are and what you do.
Mike: Sure thing. So I work as my day job as a staff engineer in the communities team in GitHub and yeah, I’ve been at GitHub for about seven years and I’ve been a staff engineer I guess about six months now and then my related hat outside of work is I’m the project leader for Homebrew, a Mac package manager as well.
Alex: Awesomeithub Is there a typical set of expectations for a staff engineer or does everyone sort of do it a little bit differently?
Mike: I think probably a bit of both. There’s a set of expectations in terms of what is required for you to hit a benchmark to hit that promotion. So like I guess a base level of expectation across various different kind of metrics. So in my case it was something that we’ve been sort of talking about these metrics for a few years and stuff like that. And there were some that I’ve probably been meeting for five years and then there’s some that were the ones that I was struggling with, which I kind of had to get up to par in order to get promoted. So I think for me it’s a combination as well of whether you have those attributes and whether your manager feels that you have those attributes and actually being able to demonstrate them and say in the last whatever, 612 months. Here’s a demonstration of say something like mentoring or project management type work or whatever. Being able to actually point to work and say, okay, I did this. And it demonstrated that I was effective and other people respected my work on that, rather than just three years ago I did this, therefore I can do it. So that’s fine.
Alex: Cool. Do you feel like there’s a good definition of the difference between someone who’s just about to be staff plus and someone who is staff plus or the typical deltas between whatever is less experienced than a staff and a staff at GitHub?
Mike: Yeah. So for us the leveling goes senior, staff, principal, distinguished, and I guess I’ll focus on senior to staff because that’s what I know I can talk a little bit about senior to principal. But then our distinguished engineers have been, I imagine like a lot of places, sort of unicorns in some respect. Where I think our internal benchmarks talk about you need to make industry wide impact. So as much of a flowchart you can follow to get that. But I think for us the jump from a senior to a staff looks I guess a fair amount like Will has talked about in the book, where you’re taking a step out from beyond what you might already be doing as a senior. You know, we would expect a senior to be doing a certain amount of work like mentorship review, splitting up projects, being able to lead projects, stuff like that. Whereas for a staff we really want to feel that like you not only do all those things and can do those things, but you are pretty excellent at the majority, if not all of them. And also I guess when your work starts to step outside primarily contributing through code. So we have a bunch of senior engineers who spend a lot of time doing things like glue work. I imagine a fair number of the people listening to this will have either read that blog post or heard that talk. So I won’t redefine that. But. So we see a lot of people doing that type of work. But it’s pretty rare that we have senior engineers where that’s the majority of their role is doing stuff like that. Most of them particularly, I guess in the part of the company where I’m at, where we’re primarily doing user centric feature development, those user centric features that you build are probably going to be the majority of your output, even if they’re not necessarily always the majority of your time, that’s what you’re going to be judged upon. And we see the people who move into staff is when you are going a bit above and beyond on that stuff. So you’re not just. There’s perfectly great seniors that I work with that will work with a PM or a designer or, sorry, pm, being product manager, designer on the team, their engineering manager, whatever, they’ll take work, they’ll deliver it on time to a high quality and that’s that. Whereas the staff folks, it always tends to be the people who are going a little bit above and beyond. So I guess to think of someone else on my team who just got promoted literally in the last week, so they’re someone who, for example, they were tasked with doing a migration for. This is GitHub sponsors was the stuff that we worked on together. So GitHub sponsors used to share a lot of the backend with GitHub Marketplace, which enabled us to get something out the door pretty quickly, but we wanted to sort of split them out. So she was sort of assigned with doing that and instead of just doing the work, cranking out some code, whatever, basically went and split out the work, made a plan for the next six to 12 months of this process, was going to work, and then went off on maternity leave for some of that time and came back and effectively her plan had been executed more or less to the letter while she was away, and everything was just smoothly running while she was out. And to me, that’s the type of thing that’s not an example that everyone does, but those are the types of things that I look around the company, I see people who are crossing that threshold starting to do when they’re doing those type of tasks that are really impactful on a bunch of other engineers. Work beyond just writing code.
Alex: Cool. And when you were promoted, was there a particular initiative or a project that you worked on that sort of took you past the finish line?
Mike: Yeah, I think so. So for me, it was probably two projects that sort of were pretty closely linked. So we have in GitHub, the main application we refer to as kind of GitHub, GitHub, which is a big rails monolith. So GitHub, GitHub, because it’s under the GitHub organization on GitHub and it’s the repository called GitHub, it’s, I think, the oldest repository there. And it’s, you know, what the. You can. It’s cool going back through the. The full history and seeing the founders kind of when they originally started the company and the project and stuff like that. Yeah, but obviously over however many years it’s been Now, I guess 11 or 12 or whatever years that GitHub’s been around, that’s kind of grown and are certainly one of the highest traffic Sort of Rails monoliths there are, if not maybe the highest traffic, I don’t know. But yeah. And when you’re clicking around the site, if we release a new feature, if it’s something like GitHub Actions, say there’s going to be a lot of that stuff that is outside the monolith and you can spin up new microservices pretty easily. But say you want something like on a pull request, you want to have your reviews handled differently, or whatever it may be, that feature is probably 99, 100% of that code is going to be written inside the monolith. So we have hundreds of engineers who are making changes and doing their work probably primarily in that monolith. So two problems that have been building up over time that are sort of related. One was we had an on call rotation for the monolith, you know, started with a probably reasonable number of people when I think I was initially on the infrastructure team when they started that. And it was just the idea of getting more application engineers to sort of take responsibility for the application code side of things, rather than ops people being woken up when it’s clearly an application problem. It started off with maybe 20, 30 people, and that rotation had grown to the point where it was probably more like 150 people by the end. So you have people who are on call effectively twice a year for the entire site, and everything that’s not a microservice that can go wrong is essentially for them to monitor and watch. I think that obviously anyone who’s been on call or dealt with that situation could probably start to immediately cycle through the many things that can and will go wrong in that situation. And I would actually say it held up pretty well for a pretty decent amount of time. But I think the work that was going into it was quite unevenly distributed because you would have some people who really knew what they were doing, who would help out all the time even when they’re not on call, and then some people who would be on call and just, you know, spent the shift hoping that they weren’t going to get paged. And if they did, you know, they knew how to handle things reasonably well. But there certainly wasn’t that level of, in my opinion, the ideal, which is that when I get unpaged, it’s for something that I’m closely related to, perhaps even ideally something that I’m actually working on. So that presented us with a problem that, okay, well, what we want to do is effectively split this up so that every team that’s Working on the monolith has their own on call rotation. But then that presented a comparable side by side problem, which was, okay, who owns what code in the monolith? So we have, I’m sure a lot of folks have used kind of the code owners feature on GitHub where you can make certain files or whatever owned by certain teams. And then we had our own thing which sort of predated that, called areas of Responsibility, which was sort of a more declarative thing that you could annotate your Rails models and things like that, sorry, Rails controllers. And the problem was is that these had both been around for a while. They disagreed with each other in certain ways. They weren’t very heavily linted. And whenever you had a company reorg and a team used to own this and now owns this, those cases weren’t always updated. So we ended up with a problem there of how to assign that ownership and get that information correct and stop a certain degree of backsliding. So we introduced a thing which is unlikely to be publicly shipped because it’s pretty special snowflake territory for how vast our monolith is and stuff like that, a thing called Service Owners, which is effectively a bit like code owners, but splits the code base along the lines of services rather than things being owned by teams. So effectively it moves what was a one to one mapping to a one to one to one mapping. So you have, instead of a file being owned by a team, a file is now owned by a service and a service is maintained by a team. And that has allowed us to kind of sort out the ownership and make the linting a lot stricter. So you can’t have teams that accidentally own, Sorry, multiple teams that accidentally own the same file, whatever. But then that also allowed us to comment out all our on call stuff as well. So things like exceptions, background jobs, failing, a lot of our logging, all this stuff’s now annotated with the service and then the service from that you can look up the relative team and then effectively page the right people. So I sort of was involved with the initial conception of that and then I probably did a lot of maybe the majority of the implementation side and ship that to completion at the same time as splitting out the encore rotations and developing a bunch of training and stuff like that alongside that to kind of try and ease people into the new process and good ways of doing Encore and things. So yeah, for me, I think that was the sort of project that very much felt like a sort of staff project that I think got me the promotion.
David: Interesting. I want to circle back to sort of the service owners thing and to sort of project execution in general. But something that you mentioned earlier, you mentioned that, you know, you oversee the Homebrew project. We’ve noticed a pattern where a lot of staff engineers we talk to are also pretty heavily involved with Open source or have previous experience as a, as a founder or as an early employee at a startup or. Anyway, I’m curious to what extent you think your experience in Open source has influenced your sort of day to day work. And especially if you think there are aspects of the staff engineer role that sort of stem from your experience in Open source.
Mike: Yeah, no, I think so. And I mean the early stage startup stuff as well. I wouldn’t have thought about that necessarily, but that feels related too. So I think the thing that I see on both of them, I guess the biggest thing from Open source is, at least in GitHub, staff engineers and principal engineers do not have direct reports. We live in the org chart. And some staff engineers report to directors instead of engineering managers and principal engineers report to VPs instead of directors. But because you don’t have that reporting relationship, you don’t so much have the ability to order people around. Essentially. Probably the most formal power you have is the ability to say no to things and sort of shoot down proposals or require changes to be met. But if I want someone to do something for me, I can’t go and tell them in terms of how the organization is technically run. That’s down to their manager or product manager or whatever to decide. And in a lot of ways that’s very similar to Open source, where on Homebrew I can’t ever tell anyone what to do, or I can try, but they won’t necessarily do it. So I feel in both cases you can have someone who has effectively no hard power, but quite a lot of soft power. So with Homebrew, I’ve been working on the project for I think 11 years now. I’m almost losing count at this point. And most of the maintainers who are around today, I’ve been involved with kind of proposing that they join the project and helping them on board and stuff like that. So I think there’s a certain amount of kind of trust there that they know that I’m not going to just bark orders at them. But at the same time, if I do sort of say, hey, please can we do this? Or I really strongly object to this a lot of the time that’s enough for people. It’s not always. And there’s definitely times even in the last year where I’ve been quite frustrated that I don’t have more hard power and I can’t just say no to things and I lose arguments. But I mean that’s probably a sign that it’s healthy and that the process is working well, that I’m not just getting to getting to boss people around. And I guess similarly the early stage startup, I think the other thing that comes from both open source and that angle. I was the first employee at a company called Mendeley a few years ago and I feel like there’s a to talk about, I guess Will’s archetypes. I kind of see myself along the lines of a solver with the work that I do in GitHub. And I think there’s definitely an open source and early stage startup approach of being like, if you have a problem and it technically belongs to another team, do you just say to that team, hey, I want need you to do this? Or do you go and basically see the problem through to completion yourself? Which may or may not involve the other team doing it or not. But it’s kind of taking ownership of some of these problems. And it’s definitely something you see, the more junior an engineer is, the more they may feel slightly, I don’t know, helpless or frozen or whatever if something is very much outside of the responsibility of them or their team.
David: Especially in a bigger org, right? It’s really tempting to look at a problem as a junior engineer in a bigger org and say, oh yeah, that’s a problem, but it’s not my problem.
Mike: It reminds me in many ways that it’s very similar with open source. And I guess, Obviously, unsurprisingly in GitHub almost all of the stuff we do, including a lot of even configuration if I want to be added or removed credentials for a service that’s a pull request on a repository that gets a review in a merge and stuff like that. It’s quite easy for me to look at that and see the part of my brain goes oh, this is open source, I know this and say okay, well if I’m making a deploy and there’s a message in there that’s output that I’m like that’s wrong or that’s really confusing or why doesn’t that link to the document that someone asked me about, I can just go and create a pull request and try and make it better. And it may be that that’s not always the best thing to do, or it may be that that will Tread on toes or that the other team will kind of have a different direction they want to go from my pull request. But again, that’s similar with open source. Not every PR I submit is one that I would expect necessarily to be merged. But the idea of doing that rather than, I guess, the open source consumer, or maybe as you say, big corporation approach of well, I’ll just go and ask the other team to do, doesn’t always pay off how it should because it may well be important to you, but it’s quite possibly not important to them. And if you’re willing to do the groundwork or the coding work or the testing work, or any part of the work really to facilitate that, then you may well find that that team, that maintainer, that project, that company, is dramatically more receptive to doing what you would like them to do. It’s making it easy for them to do the right thing.
David: That makes sense. And it’s actually a good segue to the next thing I wanted to ask you, which is basically, how do you decide what to work on?
Mike: Yeah, so this is something that gets kind of a lot of conversation and thought and I’m still figuring this out. So thankfully I’m lucky enough to have kind of some good mentors at the company who’ve been doing this stuff better and longer than I have. But what I try to do, in my case, it maybe sounds a little bit, I don’t know, hubristic, but I think because I’ve been around the GitHub for a while and again because I worked on stuff like Homebrew for a while, I have sometimes more historical context, more relationships, and more, I guess, awareness of how other things are done. So what I’m trying to do is solve problems that have maximal impact, that can only be done by me. And that sometimes means writing the code, sometimes it means writing up a proposal or an issue or mentoring people or whatever it may be. But certainly, I guess a guidance for the code that I do write I try to have because I guess there’s that classic staff engineer thing of are you writing code anymore? Are you writing as much as you used to? And in my case, yeah, I’m definitely writing less than I used to, but I’m still writing probably a non trivial amount, but I’m trying to keep it focused on every pull, request, commit whatever I make. If I was to create an issue for this instead and completely wrote up what needed to be done here, would this get done in a sort of reasonable time frame by someone else? And if the answer is yes, then I shouldn’t be writing that code. And if the answer is no, then I guess the next question is, is this actually important and worth doing? Or is it me fiddling around with something that I find indulgent and fun rather than is really impactful? But you know, I’m human. I’ll allow myself to do that every so often. But that’s the stuff I’m trying to do at least, is trying to focus on things where I feel like the way the organization is set up right now, it’s not going to get done otherwise. And then I guess the remaining parts of my work, I try and have a. I’ve tried to sort of set. I was, when I initially was staff, kind of was on a feature team and was doing sort of some of this type of work, like on top of that work. But I found that didn’t really scale terribly well. And I think I just felt like I was a blocker on that team because I would get assigned work to do and then other stuff would keep pulling me away from that. And I just felt like I was very unproductive in holding other people up. So instead we’ve sort of moved more to a model where I’m encouraging. Basically any engineer on the team can come to me at any point and say, hey, Mike, I want you to review this. I want you to help me with this, whatever. And that’s, I guess, the sort of push. And then the pull side is I have weekly meetings with my director, at least one other ic, with my manager, people like that. And from them I’m trying to almost like extract from them anything useful I can do to help. So I’m looking for things where they have a gripe or whatever or think or say, hey, what would you think about this idea? And trying when it’s something I know that they care about, trying to almost go and often jump in, solve the problem before they’ve even had a chance to think about it idea I liked that a previous manager, before I was staff, actually, when he was talking about what he wanted me to grow into is he was talking about giving me a box of files rather than a file, just almost like, right, here’s all the stuff I need to deal with right now. You figure out what’s important, go off and do it and come back to me when it’s done. And I will hopefully not have to give you dramatically as much guidance as I would have to give to a senior or lower engineer. And I find that’s the type of work I find that’s really rewarding is when my director has something which has been bugging her or whatever and I can just go and say, right, I’ve done it without there needing to be a conversational back and forth or okay, I’ll add this to my roadmap and get to it in a month or whatever it may be.
Alex: That’s interesting. So I think I hear what you’re saying is sort of like the work that you choose to do is something that you’re uniquely situated to do, but also highly impactful. And it does sound like you’re getting sort of like organizational signals sometimes that like this work is highly impactful. Are there any other tools that you use to make sure that the work that you’re doing is impactful to the organization as a whole?
Mike: Yeah, no, that’s a good question. I mean, for me. So the stuff I’ve been doing most recently is kind of. It’s somewhat obviously impactful in that it’s very measurable work. So I’m improving some parts of our, I guess, local developer experience that like all of the people working on the monolith have to run some of this stuff ten times a day and I’m shaving like minutes off the time. And that’s the stuff where impactfulness, you can pretty much do back of the napkin calculations of how much time and probably even how much money you’re saving the company. When do you improve stuff like that? Beyond that? I find it slightly harder. Certainly the stuff I was mentioning with almost helping my director and stuff like that, I find those are the things that I struggle with a little bit more to articulate the value directly beyond just this person is my boss, they want this done. So I’m going to do this to help them. But I guess even the performance work, I guess the way I came about discovering that work is looking at a few years ago, I would have maybe been a bit more cynical about stuff like our OKRs, whereas I looked at our CEOs OKRs, our department’s OKRs, and got thinking maybe a little bit more abstractly, like, what does it mean to do this? So one of ours was talking about we’re doing a lot of performance work on GitHub at the moment to try and make the site as a whole a lot faster basically and cut some of those edges. And that kind of got me thinking about, well, we’re doing this effort on the site. But if you read the OKR describing this, it’s not just external facing stuff. We’re trying to be high performance in general. So what does that look like when you look through the lens of empowering engineers on our team to have higher performance tooling and things like that? So I can’t necessarily speak to what that’s going to turn into in the future because I’m not really sure. And this has been the first probably big thing I’ve picked up since my kind of role has changed and I’ve left a feature team. But yeah, I guess I would like to have something which is I can demonstrate a measurable impact effectively.
Alex: That’s really cool. You mentioned that you’ve done sort of infrastructure work and then earlier you were talking about how you improve the on call experience for the monolith. And I feel like you’ve talked about like performance and sometimes those things because I think many engineers see the innate value in that kind of work, but it’s not always necessarily explicitly visible to the whole product experience. You know, do you or does GitHub have like a framework for understanding the impact of that sort of work that’s less than visible in maybe the product experience?
Mike: So for us, the performance work right now is being like that has actually been signaled pretty much from the top, that this is really important and this is a high priority for us as a kind of engineering Org and even as a company right now. So I think that’s helped. And I think from that perspective, I’ve never had direct reports, let alone kind of been vp, C suite, whatever. But I think having in this case a CEO and a VP of engineering who are both still fairly deeply technical and have a deeply technical background, I think that has helped with this type of work in that they’re not just expecting features to get cranked out the door and not really consider things like on call tech debt, performance, stuff like that. I think their leadership has kind of helped from that perspective. But I think as a company, I think it’s something where again hopefully it’s something that staff engineers and principals and above are sort of contributing to that conversation as well. Because you can see sometimes flows where a product manager has spoken to users and this is what users want and they work with kind of a designer to sort of spec up what’s going to get built and then the engineer kind of works with the implementation and builds it. And that’s a flow that works really well when you have a really good insight of what you’re building and what’s important. And as you say, when you have those organizational priorities. Right. And I think the tricky thing sometimes is if you have an engineer who assumes that the product manager is aware of technical debt and that they need to pay it down and that the fact that they’re not talking about it means that they just must think it’s not a priority right now. I think that’s something that is a sort of interesting diversion from that which I see, I guess some engineering managers, but certainly in GitHub, I think that’s a big part for the staff engineers to play, where they’re kind of coming in and saying sometimes, okay, this might look like a simple problem, but we really have to pay down some tech debt while we go along. And they are the ones who are sort of speaking to the product managers, speaking to engineering managers or whatever, and sort of articulating those concerns from more junior engineers who may sometimes know that there’s tech debt and it’s a problem that needs to be solved, but they may sometimes struggle to explain that in a sort of business centric framing rather than just this code is crappy, it needs to be improved. The staff engineers can actually articulate like, well, you know that feature that we just built that took longer than you thought it should have taken for us to do that? Yeah, we think it’s taken longer than it should have done too. And the reason why is because of X and we need to fix X before we pick up something else like this. And when you see people, senior engineers, staff engineers, whoever really speaking to product managers or whoever on those terms, then obviously it’s a smooth process. The product managers want this stuff and they care about this stuff being prioritized and dealt with too. It’s just sometimes there’s sometimes assumptions made that it’s that one person’s focus is the same as another person’s focus. And that’s, I think the staff folks I know in the company at least are the ones who are much better at sort of cross pollinating those ideas and making sure everyone’s on the same page.
David: Yeah, that makes sense. And I think it addresses a lot of sort of like how staff engineers can interface sort of upward in their org. One of the things that I’ve seen staff engineers do as well is act as sort of the mediator sometimes between teams that sit, you know, quote unquote below them in the org. So sometimes there’s like different teams that are, you know, maybe they’re planning projects that overlap and the staff engineer is helping them sort of find alignment in those projects, or maybe they have a difference on how something should be implemented and the staff engineer sort of helps Them find common ground. Have you seen that pattern as well? And if so, do you have any thoughts on sort of the, you know, how staffingers can be effective in that role?
Mike: This is the first one I have to be completely honest and say I haven’t seen that pattern at all actually, because we have. So the, the part of the org I’m in, we have I guess three teams technically that are sort of underneath us, but they have been. I mean, a lot of this is down to our director. Our director has done such a good job of building those teams to feel like they’re one big team and that they’re one. You know, it’s called the Communities organization. So there’s an obvious pun about them being a community of teams there. But yeah, I think they’ve done that in such a way that I don’t think I’ve ever seen those teams be kind of oppositional to each other at all. I feel like I would be the first one to jump in and try and smooth things over and have people get on okay if that wasn’t the case. But it’s not something I’ve actually seen myself.
David: That’s fantastic. In that case you mentioned a minute ago, okrs. So it sounds like that’s a process that GitHub uses to sort of set objectives throughout the org. How do you work with your team to set objectives for sort of your group?
Mike: Yeah, so from us there’s, I guess different okrs come from slightly different directions. So we have, you know, the company wide ones and team wide ones and even kind of in some cases ones that tie directly to kind of products that were, I guess, products within GitHub itself. Obviously GitHub itself is one product, but say something like GitHub sponsors, which has been something I’ve spent a lot of my time working on. So there may well be okrs that specifically relate to that. So generally those are kind of someone is the directly responsible individual who is kind of going to come up with the drafts for them and kind of push the process through to the conclusion. And generally someone’s kind of drafting these up and then we tend to have a fairly open discussion, sometimes in meetings, sometimes in Google Docs, sometimes on pull requests, on markdown files on what people think about those. What people think about both the OKRs themselves and how they map to. I imagine like most orgs, we tend to have ones where the CEO has their OKRs and then as you go down the hierarchy, effectively they look like more granular versions of what the company wide or CEO wide okrs are. So we’ll have discussion about how much we think they fit and how much these things are the things that we think are best able to impact those goals. And then obviously there’s the debate about numbers as well. I forget what our internal definition is, but it’s along the lines of you shouldn’t be unambiguously smashing all the numbers in all your KRs. If that’s the case, then it’s a sign that maybe they’re not quite as ambitious as they could be or should be. But yeah, it’s a fairly, I would say a pretty collaborative process sort of all around. And we try and have it be in such a way that the most junior engineers in the team are able to have just as much voice and input on those as folks who have been around for a long time and maybe a bit more senior.
Alex: That’s interesting to hear something that occurred to me as we were talking about sort of like cross functional partnerships. You were, you’re mentioning like a product manager. I wonder if you could speak to this if like, is it a unique experience working at GitHub also being an open source project maintainer? So you’re literally using the product that you’re building. And I’m curious, does that impact the sort of conversations that you have with your product team?
Mike: Yeah, in fact this was something that came up. We’ve got a book club for the staff eng book happening at the moment. And this is something that came up yesterday actually is that pretty much every engineer at GitHub is able to provide some sort of pretty well informed input into the product because I guess from outside the company you would look at open source as well as being obviously, I guess in my case I was probably using GitHub on a daily basis for three years or so before I ever kind of applied to join the company, which took me three times instantly. And at the company your average engineer is doing the same thing. Everything on GitHub is on GitHub. Probably in the last couple of years we’ve started using some tools like Google Docs a little bit more. But certainly when I started everything was an issue was a PR. The main default place for information to live on GitHub is on GitHub, certainly for engineers and people inside the engineering. Org. And again similarly the default way of doing things on basically every repo is making a pull request and reviewing it that way, even if I’m updating documentation and it’s an actual typo, it would be very rare for me to just Push a commit because then you don’t have that almost notification and conversation and stuff like that. So I think, yeah, as a result, obviously we have a lot of people in the company who are very, very opinionated, justifiably so, on how the product should work and what things it does that we like and what things it does that we don’t like. And when it’s kind of interesting because there’s some features, I won’t point out the specific ones, but there’s some features that we’ve had to build a few years ago or whatever for various kind of contractual compliance reasons. And then we have to eventually comply with some of these same standards, particularly post acquisition by Microsoft. And people find some of them really annoying. Some of the kind of behaviors which were previously enabled or maybe more socially enforced and are now technically enforced, and people find it quite annoying. And that’s both a pro and a con. Because I guess our management team, their attitude is. Which I actually thoroughly agree with in that like, well, that’s good because probably everyone who has to deal with these compliance requirements on GitHub finds it annoying. So let’s find a way of making the entire product better for people in these cases. Rather than saying, okay, well, we’ll just turn this off for us or we’ll hack around it or whatever, because we don’t like this feature, let’s say, okay, let’s make this feature kind of better. How can we avoid this pain for other people? And yeah, I do think that that. To go back to your original question, Alex, I do think that that informs the conversation with product a lot because when you’re talking about particularly stuff around pull requests, GitHub actions, GitHub sponsors, whatever, then we have people who have a lot of experience and a lot of opinions and it’s nice to see the vast majority of engineers at the company, I would say, would be pretty comfortable expressing those opinions on how they think the parts of the product that they’re using should be working. But then on the flip side, there’s the slight. It’s not unrelated to kind of the open source analogy we were saying before, where if you’re on the pull request team at GitHub or we don’t have a dedicated pull request team, but the team that maintains pull requests at GitHub, then it’s a little bit more painful for you working on something which people use every day and people are making probably thousands of pull requests inside the company, maybe even tens of thousands on a daily basis. And if you slightly move their cheese, then you hear about it a lot quicker than someone who’s, you know, working on some enterprise SAML feature or whatever that you may well end up touching eventually, but it’s not so integral to their workflow. But then again, the flip side of that is I think that does make us conservative on the things that are used very, very heavily, which is probably a good thing because as much as it’s important for us, we have millions of users who are using GitHub every day who don’t want their cheese moved either. So if we’re going to do that, then we have to do it in a good way and for a very good reason that they’re going to be eventually happy for.
Alex: Earlier you were talking about how sponsorship and mentoring, it sounded like it was a part of your role and I was curious what your approach to sponsoring and mentoring was.
Mike: Yeah, great question. So I think my approach is mainly around, I guess, two ways I look at it. So I try and have, if there’s someone I’m kind of working with at the moment, kind of relatively focused weekly meeting where it’s just one on one with just me and them to try and I guess almost work with them in a sort of manager like relationship to talk about whatever their goals are and see what we can do to work towards that on a given week. I don’t actually end up doing a lot of pairing just because time zones mainly because my team is mainly in mid and west coast of the US and I’m in the uk, so I don’t have a ton of time zone overlap with people. But what I try and do is I try and have that chat for sort of focus time and then encourage them to sort of think about what they’re going to bring to me and bring things to me throughout the week, but then also try and stalk them a little bit as well. So I try and keep an eye on what they’re up to, try and jump in and help them out if I can, try and just generally support them wherever I can. And then the big part of the role, I think as well, has been getting people towards promotion. So most of the people I’ve been mentoring have been people who are on the cusp of moving from one level to another, maybe becoming a senior engineer or becoming a staff engineer, for example. And I’m kind of, either they’ve been pointed to me or I’ve been pointed to them so that we can kind of work together on that kind of process. So hopefully they can get promoted. And yeah, I’m sure as those of you who worked for big companies will know, a certain amount of that is here’s how to become a better engineer. And a certain amount of that is like, okay, here’s how you need to play the game in some ways if you want to kind of get through that promotion process and get promoted. The other side of the mentorship equation for me as well is when those people are hopefully going up for promotion, then we have obviously a relatively big company formal process for making that happen and hopefully at that stage as well. I’ve worked with them enough and I’ve given them enough feedback and suggested what they have to do that they’ve actually done that and I’ve seen them do that. And then I can go and actively advocate for them as part of the promotion process as well. And I think particularly the higher level people are coming. Then we value obviously staff engineers feedback on someone who’s going to get promoted to a staff engineer more than we might value a junior engineer’s feedback or sorry, a more junior engineer. We don’t technically have junior engineers. So I think that’s the way I’ve gone about mentorship myself. But it’s something that I’m relatively new to, I guess the formal process of doing it. I’ve informally done outside of work mentorship for a long time through Google Summer of Code and Homebrew Maintainers and all these types of folks. But yeah, the more formal process is slightly newer to me, so I’m sure I still have a lot to learn there as well.
David: You mentioned sort of like the folks that you mentioned. It sounds like they’re not necessarily folks that are on your team. So I’m curious if there’s a process that you use for sort of choosing the folks that you work with.
Mike: Yeah, so right now there’s like everyone, until very recently has been people within my org. So I’m generally happy to sort of do like one offs with anyone else. But I generally try and restrict my recurring meetings with people outside my org just because it’s folks that come to.
David: You or their managers come to you or you reach out to them or sort of.
Mike: How does that work? Yeah, so the mentors within my team, team, it’s been a sort of discussion, sort of mutual between their managers and me and then I go and offer them. No one’s ever forced to kind of take mentorship, but I can offer them and say, hey, I can help you out in this way. And something I found helpful in that way as well. Because sometimes people can be A little bit not resistant but not from because they don’t want to be helped. They’re resistant because they’re like oh but you’re important and your time is so valuable. I don’t want to waste your time helping me. And then what I found this helpful to point out is say like well I guess particularly when I was going for the staff promotion I was like well I need to demonstrate my ability to successfully mentor people to become senior engineers. So you’re actually doing me a favor if you let me do this and if you let me work with you and if you get promoted that going to reflect well on me and help me get promoted as well. So it’s a win win here. And I find whenever I’ve sold it like that people are dramatically more willing to sort of engage with the process once they see that it’s benefiting me as well.
David: Right, right, that makes sense.
Mike: But yeah, but I have kind of taken on people outside of my org as well and I guess in those cases I’m sort of looking for, I guess almost like what I was saying with the code stuff before of like why me? What is it specific about me that seems to provide value to that person? And in the one person who I’m mentoring in that way right now, I guess the answer is I have a pre existing relationship with them. I referred them to join GitHub and they will probably speak a bit more candidly to me and also perhaps accept more candor in return than someone who, because they’ve not been at the company a super long time and they maybe haven’t quite built up that trust and relationship with, with other people. But I guess for me all mentoring is or has been at least a relatively short term thing. Everyone I’m sort of mentoring, I’m sort of trying to reevaluate every six months. Are they still getting a lot of value out of this? And if they’re not, then can sort of offer them either to just do it less regularly, maybe go from weekly to fortnightly or monthly or whatever or you can say okay well let’s do this one offs when you need it or if they feel like they really still need it, then we can kind of continue to do that. But I’m trying to make sure get that balance of providing the most value to whoever I can provide it to.
David: Of course. So we’re almost at time. I have two more questions I want to cover. So maybe lightning round, what are some resources, books, blogs, people, et cetera that you’ve learned from and that have sort of helped you in your. In your journey as a staff engineer.
Mike: Yeah. So I guess the main one would be relatively obvious, like the staff engineer, like staffengine.com site. I would say for me, that’s been 90% of my thinking around this stuff has been that. And then beyond that, it’s been just probably individual conversations with people in and outside the company about how they do things and how they work and stuff like that. But I guess as we touched on before as well, for me, another big part of it has been the open source experience and also perhaps the sort of the mentorship side of open source as well. Stuff like programs like Major Leave Hacking and Google Summer of Code and outreaching and things like that, where you can sort of have a more certainly on the mentorship side, a more formal sort of mentorship relationship with someone for a short time period. I think that’s been really useful in sort of teaching me some of these skills too.
Alex: Cool. So our last question. Hopefully this is a fun question and we’ve asked everyone, how much time do you spend coding still?
Mike: I don’t know. I would say maybe up to, on a good week, probably up to about 50, 60% of my time, and on a bad week, maybe like 20% of my time. I think for me, the nice fallback is that I can always find code to justify writing on Homebrew. So even if I know I can’t justify any GitHub code right now, I know that Homebrew’s got a backlog that’s longer than anything I’ve ever seen in my life. So I can always pick something up, work on something, and ship that in quite a satisfying way, even if I can’t necessarily do that with my work stuff.
Alex: Cool.
David: Well, that’s a pretty good outlet to have.
Mike: Yep, it’s good. I like it. Cool.
David: Mike, thanks so much for taking the time. It’s really been a pleasure.
Mike: Yeah, pleasure, guys. This was really fun to talk.
David: That’s it. Thanks so much for listening to Staff Eng. If you enjoyed today’s show, please consider adding a review on itunes, Spotify, or your podcaster of choice. It helps others find the show and is a really useful signal to us that folks are finding value in this so that we keep doing it.
Alex: You can find the notes from today’s episode at our website podcast. The website also has our contact info. Please don’t be shy.