Amy Unger (GitHub)
Amy Unger, our guest on today’s show, is passionate about providing a high-quality service to the customers who use the products she is working on. Amy has a diverse skill set and an equally diverse set of tasks that she undertakes weekly for GitHub, and at the core of everything she does is her drive to provide value. Amy came into the for-profit space from the academic programming space, and she explains the different experiences she has had in these realms. We discuss what a tech lead role consists of, in comparison to the deep diver role that Amy currently holds, the responsibilities that come with it, and why she loves what she does. Amy also shares her thoughts about trade-offs, and the considerations that all engineers should be making before they embark upon certain projects.
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 who have progressed beyond the career level into staff levels and beyond. We’re interested in the areas of work that sets 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 Romis and I’m joined by my co host, Alex Kessinger. We’re both staff plus engineers who have been working in software for over a decade. Alex, please tell us a bit about today’s guest.
Alex: Yeah, Amy Unger is an engineer at GitHub, previously of Heroku as well. Amy works on a dizzying array of things in a given week. It was fun getting to hear her approach and I think you all enjoy it as well. Let’s get into it.
David: Amy, thank you so much for taking the time. It’s really great to have you here with us today. If we could start by having you just tell us who you are and what you do.
Amy: My name is Amy Unger. I’m a software engineer. I started out in libraries and archives with connection there because of my history background and slowly moved more and more into developer tools. So I spent six years at Heroku and now I’m at GitHub.
Alex: Nice. I’m curious, is there a typical set of expectations for a staff engineer at GitHub?
Amy: Yeah, fun, perennial question. No, there’s not a standard set. I think every org has a different approach to how staff engineers kind of come up into the role. And I think a very common pattern is to bring folks into the role as something similar to what Will talks about as the tech lead archetype at GitHub. That’s, that’s very common. We also have a bit of folks who are deep divers. GitHub is at this point a very large monolith. Well, the core of it is a very large monolith. We need deep expertise in git systems in other parts of our technology and that’s a really easy to justify kind of model for your time. You get wins. They might be a little bit shorter. Shorter is the wrong word. With a tech lead, you’re really very clearly of use to your manager, someone who’s deep diving and solving bigger problems. You’re not necessarily working on a three month timeline, you might be working on a 12 month timeline, but you are clearly able to bring wins to the table with, okay, I brought performance up by 15%. I solved this memory issue. So those two models are really common for us. The tech lead for bringing folks into the world. It’s kind of a natural extension of probably what you were doing at Senior and kind of just getting you a taste of what you could do. And then solver for solver, deep diver for a different variation of staff that’s pretty easy to justify to the business in terms of value.
Alex: Cool. Do you feel like either of those epitomizes your approach to staff or do you have your own unique twist on being a staff engineer?
Amy: I think everyone rotates through different roles. Maybe if you don’t want to. I think a lot of folks rotate through different roles. That’s not what I’m doing right now. I work for a department that has about 30 ICs. One way of looking at us is we are some of the oldest parts of GitHub married with some of the newest parts. We have repositories which is like that is the first feature of GitHub. We have pull requests issues came in between. But when you’re talking about code collaboration and building, software issues help you track it. But the actual code work repositories first, pull requests next. Then to add in a little bit of the new we have codespaces which is helping you write code. A complete development environment in the cloud so you can write code, pull, request it and get it merged in all from your. Your iPad if you wanted. So it’s a really cool set of features. It’s very broad. My work is kind of mostly focused across the department, making sure that we understand where our risks lie. We have a lot of legacy code that we are very happy with because it’s delivering great features but it needs some care intending and if there’s no one there to clearly articulate that we need to get it done. Which obviously we have lots of ICs who are and have been doing that work. I help kind of coalesce all that into common approach. I take on anything that’s not being addressed that we think really should be and then every once in a while help out with assorted fires. So you know, critical ga date about to be missed because surprise, your team didn’t deliver something we’re telling you about today. The deadline is March 31st. Go that sort of fun stuff.
Alex: Cool. This is a little bit tangential. I was curious. You said you mentioned you came from libraries. Are you familiar at all with the code for Lib Group?
Amy: Yeah, I can’t remember which one I attended, but I was one of their scholars or sponsored whatever when I was.
Alex: In library school before working at Stitch Fix, the last company I worked for was a library vendor. So we sold software to libraries. Oh, which BPress? Digital Commons.
Amy: Sorry, I haven’t heard that before.
Alex: It’s an institutional repository. It doesn’t matter. The reason why I brought it up is that that was sort of a detour for me in my software engineering career and I was in my experience going to code for Lib and doing other sort of library software engineering activities. There was a very different approach to the job than I found pretty much anywhere else. And I was curious if that was something that you saw and if you have brought that approach to GitHub.
Amy: I wouldn’t say that I have brought that approach, no. Well, there are three things I’m really grateful for for starting out there. Probably first and foremost is that academic libraries, academic programming in general didn’t have the same exodus or forcing out of women from the field. So I had a lot of men surrounding me, but there were still some really senior, really kick ass women. That was really great and empowering for me. I think the second thing that has really stuck with me is just a service ethic. It is really easy to come to consensus. Well, maybe not easy to come to consensus, but you can always start from a point of sharing a dedication to patrons to serving the needs of your community and building knowledge and resources to those people. Personally, I wish eventually to get back to that. I think there is a strong component of that in developer tooling that I probably do relate to, but they’re very for profit companies and so I wouldn’t say that that ethic really applies. And let’s see. Oh yeah, the third was kind of. I didn’t see a lot of spectacular thinking around programming coming out there. So I’m curious what approaches to programming that you found and enjoyed working at the press.
Alex: Totally. So one of the things I think, I guess was the approach of the community to their job more than the approach to programming. Like you said, libraries sort of take this oversized role in our society, both like your local public library and your university library. It’s almost like become like this social infrastructure that we don’t really talk about that much. And it’s interesting, GitHub is also sort of social infrastructure for code and open source. And I was wondering if you found a sort of, you know, a shared theme there and it sounds like you do.
Amy: Yeah, I think for me personally, yes, I think that as a staff engineer, particularly in the roles beyond tech lead, I think a little bit of business knowledge, product knowledge is always going to be a positive. And so I would hesitate to say that I approach my job first and foremost from a service ethic, I do probably put my team in department first as much as well. Yeah, but being constantly aware that you are a for profit company as much as we are the backbone of a lot of open source development at Heroku, we were the backbone of a lot of programming, teaching. So the ability to spin up free dinos for students to see their work was really important. But I think if you ignore the product direction, if you ignore what’s making money, if you can’t find some way to align the work you’re doing or help frame the work that other engineers are doing in the context of what is delivering value, and for better or worse, at a for profit company, that value is going to be tied to money in some way, shape or form. I think you’re going to be less effective.
David: That’s actually a pretty good segue to the next thing I wanted to ask, which is how do you decide what to work on?
Amy: That’s a tough question because I don’t think I have any formulated thoughts on it. For me, I think what I strive for is when I’m working across teams, I’m striving for working on the things that everyone thinks, oh gosh, we should have someone thinking about that, we should have someone working on that. But no one can because their role is shaped towards a different type of delivery than mine is. So I definitely limit the list based off of things that my role can do better than the other than if I were in a different role. But then, yeah, what is a higher priority and what isn’t within that? Because there are so many things that we’re just not getting to. I think some of that is a little bit of gut instinct. I definitely prioritize in my role, which is a little bit more tied to my director than to a product line. I am probably skewing a little bit towards the organizational and management challenges. This kind of role that works across teams. I’ve seen kind of two framings of the responsibility are either tied to a manager, which is true in my case, or you’re responsible for a product line, the technical delivery of a product line. And so if you know there are reliability issues, if there are, you know, if we didn’t address that tech debt and now we can’t deliver a feature in the timeline you expect because the code is full of way too many edge cases to make sense of, that’s your responsibility. If you are tied to a product line, I think there it’s. If you’re tied to a product line prioritization is based off of delivery of a great technical product to your customer. With a role that’s tied more to a manager. I think it’s a little bit harder to say a particular thing that I am aiming for, and that may just be my inexperience in the role. I was doing something similar to this, but kind of tied to both a product line and a manager at Heroku in this role is very crosses a bunch of different product lines. So I’m not sure I can tell you a formula for what exactly I work on, other than things that will make sure that my department continues to operate smoothly and that my director never has any surprises.
David: Would you say that your work is more oriented toward planning, training, recruiting and mentoring, or more toward guiding groups through sort of specific projects?
Amy: Yeah, you know, I think that’s an interesting framing that I’m not sure either really applies. I guess I’d be curious to hear more about the distinction you’re trying to make there between those two models.
David: Maybe another way of framing it is like concretely what do you do in a week?
Amy: Sure. So my week generally starts with probably about maximum of two priorities or two deliverables. A selection of those might be getting together. Our department’s report for a monthly meeting that at Microsoft and GitHub is called Fundamentals. So that is basically how our engineering fundamentals doing from pages to tech debt to web performance, API performance security issues. I might be taking a look. Our department of 30 plus ICs has a shared on call rotation which means that things slip through the cracks in terms of process and knowledge sharing. So I might be working on something like that. A deliverable of writing up something to coalesce to last month’s incidents. A write up on here’s how you can tell that something’s gone wrong with Kafka, that sort of thing. I might be working on random tooling for the team that just doesn’t no one else can get to where I might be thrown a random fire like the one I referenced of hey we need something yesterday. Why didn’t you know about this? Let’s find a solution to unblock this feature launch. So probably deliverable of one of those things maybe a second and then pretty much a full day of meetings that are oriented towards I would say guidance and framing for managers. So my manager, the manager, each of the managers within our department and then the senior ICs. So rotating meetings trying to hear what their problems are help them frame technical issues, problem solve with who might be best suited to what with our senior ICs. That’s some of like what challenges are you having if you’re new to staff? Like, how are you adjusting if you’re senior in staff? What the heck is this weird thing we’re doing together? I don’t know. But let’s problem solve and then maybe a sampling of talking with our product folks just to get a little bit of an update. Then a half day of within that week, a half day of one on ones. I rotate through all of our ICs on a quarterly basis just to hear what they are working on and provide any context I can. When I was in a tech lead role, one of my measures for my own success was whether each of our ICs felt like they could draw a connection between the code they were writing and the technical strategy of the company. With 30 plus ICs, it’s a little bit harder to deliver on that universally. So quarterly as I can kind of framing like. Okay, well one of the reasons we might be framing our performance issues in this particular way because there are infinite performance metrics that we could deliver towards is because of X quality of our market.
Alex: Wow, that’s like an amazingly diverse set of things that you could tackle in any given week. That’s awesome.
Amy: Yeah, it’s a fun challenge. I definitely enjoy it and love it. And I also think it speaks to the vast diversity of staff engineering roles that you can have once you get beyond the tech lead kind of position. There is a lot of freedom to look at what your skills are and what you can offer the company. And you know, you’re, you’re bringing to the table just as much as your manager brings to their boss an action plan. And part of the job is figuring out how you can best use your own skills for the business. And that leads to over so many different, wonderfully different, fascinatingly different answers for each and every one of our senior staff folks.
Alex: Cool. You mentioned for a prior role, a set of measures of success. I’m curious, do you know what your current set of measures of success are?
Amy: No, I don’t. I am confident I’m hitting what my boss needs me to hit. But I do think that once you are in a role beyond technilead, you know, you’re bringing something to your own role, you’re bringing your own goals, you’re bringing your own direction. So I do have, you know, I have a 12 month set of 12 month goals I want to deliver for my department and each of those have metrics of success, but I haven’t yet. I mean, I’m six months into this job, so maybe it’s that. I also think some of it is being tied to a director. So I can kind of independently frame what success looks like if my responsibility is to a product line. But if my responsibility is to a director in a department and kind of an org, then it’s a little bit less under my control. But no, I don’t think so. And I think that’s something that is something I need to grow into.
Alex: Cool. Earlier you mentioned that you leaned more towards the organizational management and away from sort of tech or feature lines. Did I have that framing correctly?
Amy: Yes. In terms of responsibilities, there’s a model of staff engineer where you are the person for, let’s say, GitHub Actions. And if that’s not having success in the market for any technical reason, that’s on you. Yeah, that’s not my role. Currently it is. If my director isn’t happy, if our department isn’t succeeding, technically, that is on me.
Alex: Cool. I was curious, is that like a conversation you’ve had with your director specifically, or is that just something you’ve. How do you know that that’s what you do?
Amy: Yeah, it’s a job interview. My director was looking for someone to fill a role like that. I was looking to continue doing a role like that. And yeah, we were lucky, I think, to be able to. It’s rare that you hire externally for that kind of a role. I think it’s also somewhat rare to be on the market explicitly looking for that kind of role. Probably less rare than it is to have an opening, but it’s absolutely. It should be explicit, especially if you’re hired into it. If you’re promoted up, then yeah, maybe it’s a little amorphous. Especially so in my last job, my manager was tied to a product line. So my job was kind of in between. Personally, I think in that position where it’s kind of both. I mean, you can navigate both. I’m personally not going to navigate both. I like clarity. So for me, the choice is and always will be the product line and serving customers. First priority being not being a shitty human to my coworkers and the people that I am responsible to as an employee, but secondarily then to delivering an amazing product. And you navigate that with your manager by keeping them up to date on where you stand and if there is a disagreement working through that.
David: You mentioned a couple times this example of. Typically, this is an example. I have no idea if this happened this week or not. But the example of like going to a team and saying, hey, like you know, you, you’ve basically dropped this deadline and the rest of the org needs it. Let’s make it happen. How can we make it happen? That type of scenario is one where like you’re trying to, trying to bring people along and you, you’re maybe representing some positional authority but you’re largely using your influence, right, to sort of, at least that’s been my experience. Do you have any, any sort of tactics that you use in those scenarios both for sort of navigating the maybe tough conversation of like addressing the problem and also like working together toward a solution and potentially sort of bringing together multiple teams that maybe, you know, oftentimes in these scenarios the reason something got dropped is because there, there was sort of not the right line of communication between those teams to begin with. So sometimes there’s a little bit of like patching up that needs to be done as well.
Amy: Yeah, for sure. I’ll give a privileged answer first because I think if you are in a position where you can do this, it’s incredibly important make sure that your trade offs are the same ones that in a broad sense your organization is making. So it becomes incredibly difficult to navigate those conversations if you as an engineer fundamentally disagree with the pace of business, with the pace of taking on tech debt, or with the quality for however you defined quality, the quality of engineering being done. Obviously switching jobs is hard and I have been so lucky to have front loaded those kinds of conversations in my past jobs and be able to join a place where I am confident that kind of my comfort zone is somewhat similar to the ICs and managers that I’ll be directly working with. So I think it’s just a lot easier when you’re willing to make the same trade offs that folks around you are willing to make. For that reason, I think there would be a few very special small startups that I would love to be a part of. It’s going to be few and far between. My comfort zone is large, larger companies and if you know that about yourself, you’re going to set yourself up well. So then how do you handle those conversations? The first thing I think is important is to trust the people that you work with. If you trust your teammates first and foremost. So if they’re giving an estimate that is longer, push enough to understand why, but like it’s your job to go defend that. The next thing is to think about the risk that the organization is taking on by rushing work. And that’s usually how I frame whether it’s explicit or not. That’s how I frame any proposal or estimate that comes out of those requests. We can rush something. You’re going to be paying for that in terms of presume like a guesstimate of 20 tickets a week of whole series of security bugs and a compliance feature and just trying to frame those risks in terms of impact to the market. Most of the time you’re getting a rushed feature request because there is a need to deliver something to a customer. If it’s a security issue, then this calculus is very different. But there’s not much value in delivering a truly, truly broken experience to the market unless you’re under incredible financial duress and framing the trade offs, framing the risk that your team is taking on in terms of product risk that the business is taking on in order to deliver something that looks like what they promised. That framing can help make better choices about whether there might be other options, whether we can instead frame let’s say things I’ve seen. These are not GitHub examples. To be clear, things I’ve seen include okay, we acknowledge that there will be an extra support burden. We’ll bring over someone from support to write the docs for you and they’ll be like very specific. That only works if you can be explicit about the product failings. If you can’t be explicit about the product failings, then maybe it’s okay, well, we promised a public beta, but let’s say it’s a public ish beta where your public onboarding is like handheld. You get assigned a product manager. There is no chance that that customer will ever actually even reach support because they’re going straight to the PM who’s going to jump on a call with them and walk them through whatever BS we ended up shipping. And then there’s always moving a deadline. Right, to actually have allow the business the time to deliver an experience that’s going to work in the market as opposed to one that works for face saving. Ultimately, customers are not dumb and if you’re treating them like they can’t detect a bad product, then you shouldn’t be in the market.
Alex: Interesting. That’s a really great breakdown of how to have those conversations changing topics a little bit. Do you see sponsoring and mentoring as a part of your role?
Amy: Absolutely. I think it’s an interesting thing. It’s gotten a little harder as my role has been less involved with the day to day of shipping individual product features, but absolutely, I definitely see mentoring as a strong component of my job. I have struggled with formal mentoring. Mentoring for me is kind of just a scattering of folks that I have started infrequent one on ones with and we found them useful and we have kind of sped up the pace without any potential, any formal mentoring. I think one of the fun things about leaving a job is you can have some honest conversations. And I had some really lovely conversations as I was leaving my last job where we were like, hey, me, like, you did a really good job with the mentoring side of this. I’m like, oh yeah, I’m glad. Like, I’m glad you saw that and I’m glad that you felt that this was a mentoring relationship and not just like, I don’t know, something that I thought it was, but. But you didn’t. I struggle with formal mentorship programs and I don’t know how to do them and that doesn’t play to my skill set. So I will leave that to other folks. Sponsorship, however, is something that I very passionately and formally do. I think a lot of staff engineers get overwhelmed with the amount of work that they have on their plate. They may be able to prioritize, but prioritization doesn’t matter. If you’re not willing to make hard cuts, actually make cuts that feel painful. And so a lot of staff engineers get into a problem where they’re not thinking ahead enough to what they’re going to have to cut. And so by the time they have to cut something, they’re like, okay, well this is a hard cut. This still needs to get done for the department. How are we going to get it done? Okay, well we’ll pull this like mid level engineer. It’s a good growth opportunity. Well, what have you done there? You’ve added maybe three hours to your week of a one hour onboarding meeting, dropping context, an hour of slack chat sprinkled throughout the week, and one hour of reviewing whatever proposal they’re working on. So you end, you can very quickly end up in a place where you are delegating, not sponsoring. And delegation takes extra effort when you’re already underwater. So for me, I think about sponsorship as really anything that I’m working on. There should be someone who has the ability to take it up. I would say that’s something I’m not doing super well in my current role in part because the incentives are very much to alleviate burdens from the department. And so pulling someone in, in my past roles where I was a tech lead and then working on a product line is very clear. Like, okay, I will Just always have someone shadowing me for any given thing and we’ll just throw a little bit more at them as they come up to speed with my current role. There’s a lot of stuff that just. It’d be a burden to have someone on it and I don’t like that thinking in myself. But I also can’t justify the extra time. I think if I somehow disappeared from the company, a lot of the stuff, well, we’d kind of. It’d be in a good enough spot that we’d just amble along and it wouldn’t make as much progress. So it is definitely part of the role. I think it’s something that folks struggle with and I think when you get into some of the weirder variations of staff engineer, it’s unclear how much of it you should be doing.
David: That all kind of resonates with me. I’ve also struggled with formal mentorship programs at various points. I find the distinction between sponsorship and delegation and sort of the areas in between pretty interesting. I don’t feel like I have a good handle on them. But we’re almost at time and I want to touch on a couple other things before we break. One of them is just are there any people or resources that have influenced the way that you think about software engineering and staff engineering and sort of like everything that we’ve talked about today?
Amy: Yeah. I am horrible about written resources. Instead, I will say I have learned the most from other staff engineers who work at my company. Wherever I’m at finding the people who really think deeply about their role and just asking them about how they’re approaching their role and kind of sharing how I’m approaching my role and seeing where those differences are. I think you learn a ton about your weaknesses and strengths from seeing people who are in somewhat similar situations as you and. But are performing very differently if. If just as well, but just performing differently.
Alex: Cool. So our final question. We hope it’s fun.
Amy: Yeah.
Alex: Is how much time do you find yourself coding nowadays?
Amy: None. Absolutely none. I deployed my only meaningful production deploy. I have had a few PRs to tooling here and there. My only meaningful PR to production in six months was one that removed a bunch of if else statements in our HTML code from a. I believe it was a big push to do mobile better and it just never, never gotten removed. It was actually a pretty risky deploy because we don’t. It’s all verified by smoke testing. There’s. It’s really hard to write tests that are worth running in CI for every single deploy for every variation of every. Every mobile device. But yeah, it was literally just staring at if else statements and removing the, you know, if deprecated mobile client from 30 different. Well no, it’d be three. Three files. Probably about 30 different call sites.
David: Nice. That sounds, that sounds like staff work to me.
Amy: Sure. But it’s one PR out of six months, so. Yeah, I definitely, I think that if you’re uncomfortable with the amount of code you feel like you’re not writing, that’s either a moment to reflect on what makes you happy or and that’s a great conversation to have with your manager, or it’s a moment to reflect with yourself about what is the most valuable work you’re doing. And oftentimes the trade offs you’re making are that there’s just more valuable non coding work to be done and so long as you’re on the same page with your manager and other important stakeholders, then you are making the right call.
Alex: Yeah. Yeah, that makes sense.
David: Amy, thank you so much for taking the time. It was really nice chatting with you today.
Amy: Yeah, for sure. That’s it.
David: 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 staffenge. Com. The website also has our contact info. Please don’t be shy.