The Path to Becoming a Senior Engineering Manager • Denise Yu & Jiaqi Liu

This interview was recorded for GOTO Unscripted.
gotopia.tech

Read the full transcription of this interview here

Jiaqi Liu - Senior Engineering Manager at GitHub
Denise Yu - Senior Software Engineer at GitHub

DESCRIPTION
In this Unscripted episode, Jiaqi Liu and Denise Yu give you insight into their path to becoming senior engineering managers at Github while covering what the position is like. You’ll learn about "glue work" and how speaking at conferences can influence your career.

RECOMMENDED BOOKS
Will Larson • Staff Engineer: Leadership beyond the management track
Matthew Skelton & Manuel Pais • Team Topologies
Ken Kousen • Help Your Boss Help You
Julie Zhuo • The Making of a Manager
Michael D. Watkins • The First 90 Days

Twitter
Instagram
LinkedIn
Facebook

Looking for a unique learning experience?
Attend the next GOTO conference near you! Get your ticket: gotopia.tech

SUBSCRIBE TO OUR YOUTUBE CHANNEL - new videos posted daily!

Chapters

• 0:00 Intro
• 7:00 Persuasive writing
• 15:18 Glue work
• 20:47 Speaking at conferences
• 25:17 Open source work
• 26:53 Decisions
• 32:17 Outro

Transcript

Intro

Jiaqi Liu: Hello, my name is Jiaqi Liu. I am a senior engineering manager at GitHub on the database infrastructure team. I work closely with our platform, our core infrastructure. And my team owns our suite of MySQL instances. I am based out of Baltimore, Maryland, although I'm currently in New Jersey right now for U.S. Thanksgiving. Denise, why don't you introduce yourself?

Denise Yu: My name is Denise Yu. I am also a senior engineering manager at GitHub. I work on a very different part of the product, on GitHub Sponsors, which is GitHub's answer to Patreon, but for open source. Most people probably know that a lot of open source communities do all their development and their collaboration on GitHub. Sponsors is a way to support the open source projects that you use, if you happen to depend on the hard work of maintainers for your company or for your personal projects and want to show them some financial support.

Before joining GitHub, I worked at Pivotal. And before that, I worked at a financial publishing company. I don't even know what industry they're in anymore. So, I've done a lot of different things before landing at GitHub. I'm currently based in Toronto, Canada, although I am originally from New Jersey. Jiaqi and I are actually from pretty much the same part of the country and went to the same university, and now work at the same company.

Jiaqi Liu: It's funny how our journey took us on this path. I'm so interested in how you ended up at GitHub, in particular on the Communities team, and as an engineering manager.

Denise Yu: It's so funny. I only started my tech career seven years ago. In 2014, I was in London actually finishing up my master's degree in a field entirely not related to tech at all. I was studying social policy in Europe, and then I literally had a few months on my Visa and decided to sign up for a coding boot camp. Because what else are you going to do with a spare four months at the end of a Visa? And it sounds corny, but actually, that ended up changing my life completely. I went into the coding boot camp thinking I was just going to pick up another set of skills to be able to write Excel macros or script some of the repetitive tasks that I would be doing in a policy job or maybe in a law job one day, if I wanted to pursue the path of being a lawyer. I had no idea in 2014 that I would switch full-time to being a software engineer.

So, now that it's 2021 and looking back, I'm like, "Wow!" We work at one of the most well-known companies for developer tooling in the world, and we work with such amazing teams. I just had no way to predict that this is where I was going to be seven years ago.

But originally, I studied economics as an undergraduate. I was very interested in the policy track. After I finished my master's degree in the UK, I had a hard time finding a job in policy. Because it turns out there are only 20 openings that come up per year and they prefer to give those to people who can work natively in the EU, and I was not one of those people. So, that's what kind of got me looking around.

I think deep down, I probably always had a suspicion that I would end up doing something creative and technical, kind of weirdly in that intersection. I don't know about you, Jiaqi, but when I was growing up, I was, from a pretty young age, interested in website design. For all the student clubs that I was in, I did Model UN, Model Congress, I always ended up being the webmaster for those clubs because I knew just enough CSS and HTML. I knew this much more than everybody else.

It was because I did a lot of Neopets, and Myspace, and LiveJournal, and designing custom Xanga themes. I don't know if anyone knows what Xanga is, but it was like the teenagers' blogging platform from way before Tumblr, way before LiveJournal. It was probably one of the original ones. I don't know. You just go on there, and just kind of post pictures of your favorite celebrities and come up with CSS themes to make the font as tiny as humanly possible.

Jiaqi Liu: Yeah.

Denise Yu: What was your journey into your current role like?

Jiaqi Liu: Well, I know what Xanga is. And now, there's Neopet NFT. So, you get back on that Neopet train.

Denise Yu: My Neopets are so hungry. It's been 10 years since I've logged in, at least.

Jiaqi Liu: I'm sure they live forever. For me, I started out my career as a data scientist, which is very different from my role now as an engineering manager on the infrastructure side. I totally agree with you, though. I think it's so cool to be both creative and technical. I realized that pretty early on as a data scientist because you have to be creative with how you interpret the data and how you work with data.

My background is a little bit more traditional within tech, I guess, or maybe not traditional anymore. Who knows? I did study computer science in college. I specifically focused on computer science theory, so towards the last part of my college career, there was a lot less coding, a lot more writing proofs on paper. And today, my favorite tool remains paper and pen. People always ask me during onboarding like, "What tools do you use?" I'm like, "No, I have this pen I really like that is recommended by Barack Obama. It's what he used to write his books. And this notepad I really like."

Persuasive writing

Jiaqi Liu: I think where I keep kicking myself is while I did go to engineering school, there was a strong emphasis on liberal arts. I did take a lot of liberal arts classes. I actually really struggled in my liberal arts classes. I think I got an A on a paper, like, once my entire college career. And now, as an engineering manager, so much of my work is persuasive, concise writing. I'm finding myself thinking back to those college days where it's like, "How do I have more conviction in my argument in writing? How do I get this to be concise and clear?" And I spent so much more of my time doing that, but also in a technical way because I'm making arguments in favor of either technical choices we have to make or projects we have to take on.

Denise Yu: It's honestly such an underrated skill. People who ask me, when they're early-mid career, "What should I be doing right now to accelerate to get to senior faster? How do I get to be an engineering manager faster?" I'm like, "Write." That's my number one thing. If you do writing for its own sake, keep your own blog about the things that you've learned. Write down thoughts you have around leadership, engineering, teamwork, whatever it is. But also, get better at communicating, written communication.

We both work at GitHub and GitHub has been remote for a long time. That's been the culture. But I have a lot of friends at companies that were not remote first, and there was no emphasis on asynchronous communication. There was no emphasis on written communication until COVID hit last year. And all of a sudden, there was a huge change that people suddenly had to make, all the things that people depended on in terms of working in person. I think we're very lucky that being in a remote-first company means that strong writing skills were always valued. There were always cultural norms about what to write, when to write, how much to write, the tone and tenor you use when you write. And I 100% echo that. I feel so blessed that we had the opportunity to really sharpen that skill in undergrad.

I don't know how hard your high school writing classes were, but mine were not so serious. I basically didn't really have to learn until I got to college. I almost failed my first college paper. It was a B minus, which is not actually failing but you know what it is for a high achiever. A B minus is shitty. Sorry, bad experience. But after that point, I was like, "Oh, okay. So, persuasive writing means you need to form all of your thoughts around a thesis. You need to seriously think about how you communicate your thoughts and really understand your audience."

There are so many parallels to product development. Honestly, when you take a step back, understand your audience, understand their motivations, figure out what your readers are looking for, what they're reading for, it's so underrated. How do we introduce the persuasive writing component into technical training curriculums? I don't know.

Jiaqi Liu: Yeah, for sure. For me in high school, writing was always about meeting a certain word count. Each paragraph has to be a certain amount of sentences. And it's so not like that in real life. It's so much more on, are you conveying your ideas across to your target audience? Did you think about who your target audience is? And are you making the points that resonate with them?

Denise Yu: Exactly. I think coding itself is also a lot like creative writing. I've seen and heard a couple of conference talks now that compare the process of editing and the process of structuring an essay or any kind of journalistic piece to writing code. When I'm doing a refactoring or writing something new, I feel the same brain muscles churn as when I’m writing a paper. Because you have to think about where are my core ideas? How do I surface those core ideas? How do I make the most relevant pieces the easiest to find?

And that's similar to naming functions, right? If you're extracting out shared logic and you want to keep the core logic in the main function, you don't want to extract away for the sake of hiding stuff. You want to keep the core meaning closest to where the code is going to enter, that module or that class or whatever. I think there’s probably more to pull on there that I haven't fully thought out.

Jiaqi Liu: Yeah. I think we think about this a lot at GitHub, but what honestly is new to me since joining GitHub is the readability of code as well. Can someone look at this and get an understanding of what is happening and be able to be self-sufficient in that code base? Of course, there's always documentation and comments as well. But is this code structured in a way that other people can build on top of it? It's not something that I thought too much about earlier on in my career: Just, did this code work? Did it run fast enough? Versus now.

I don't write code as much as I used to, but when I do, I definitely go through an editing process where after I get it to be somewhat functional, it's like, did I name this variable right? Do I want all this logic grouped together? Are they actually separate? Should I be wrapping certain things within functions when they're loosely out there somewhere? I'm trying to develop a style guide for my writing. But it's also like having a style guide for code as well.

Denise Yu: Yeah, for sure. I remember one of my boot camp coaches said way, way back "Make it work, and then make it pretty, and then make it fast." Pretty is kind of an unfair word for it because it's not like putting cosmetic finishes on. It's like, make your code work, and then make it readable. Make it human-understandable. And then make it fast.

Of course, depending on the domain, sometimes you're more interested in making it fast and then making it readable. I think the order of those two is debatable. But the first one, make it work, being the core thing. That still sticks with me a lot. And I think that's exactly the same sort of writing process. Right? The first task is just you getting your thoughts out of your brain and onto paper. And then you go back and figure out, did I do this in the right order? Did I do this using the right words? Did I break up the paragraphs into the correct places, and stuff like that? That's really cool. I never really thought about this in that much detail before.

One other thing that we have in common is Jiaqi and I actually met because of a conference called Write/Speak/Code. They do a couple of yearly conferences, but it's a community for people who belong to marginalized genders in tech. Jiaqi, you were involved in one of the chapters, right?

Jiaqi Liu: Yeah. I actually met a couple of current Hubbers through Write/Speak/Code way back, I think, in 2016. I went to a conference and just met a lot of people over dinner. It was very cool to be a part of this community because this community was so focused on action-oriented career goals and career progression. And to its name, there are three main areas of focus: writing, speaking at conferences or giving technical talks, and coding. And the coding part had a focus on open source as well, which I loved.

I was really excited to be a part of this community, and it definitely has a lasting impact on my career and all my personal career values as well. Denise, how did Write/Speak/Code impact your career?

Glue Work

Denise Yu: I definitely tell people that this is my favorite conference to go to. I don't live in a city where there's a Write/Speak/Code chapter, yet, anyway. I guess I have some control over that. I almost discovered Write/Speak/Code by accident. I can't even remember how I found the conference. But I decided to just apply to speak at it. And this is back in probably 2017 or '18. At the time, I was like, "Oh, this feels like another really cool women-in-code type meetup." But I didn't realize how action-focused it was until I got there and was in back-to-back workshops that focused on professional development. The target audience for Write/Speak/Code is people who are already in the tech industry, but want to get to very senior positions, want to get to the director track. They want to level up in their careers. It's a support community for people who are already invested in the industry.

I think that's one of the big differentiators of the community. There's so much room, and so much space and demand for communities that want to lower the barriers for people wanting to get into the industry. Write/Speak/Code explicitly doesn't pitch itself at that group because it's just a different audience. I don't know how to describe the first time I went to Write/Speak/Code other than I found so much camaraderie. Everybody there knew what I was going through.

I remember seeing Tanya Reilly, I don't know if this was the first time she gave a talk, but she delivered this talk that I now get sent pretty often. People are like, "Oh, check out Tanya's talk." I'm like, "Yeah. I know Tanya. She's fantastic. I was there for one of the first ever deliveries of this talk." The talk is called Being Glue and I remember that talk honestly changed my life in so many ways. I don't know if you still think about this talk as well, but I send it to everybody. Essentially, the thesis of the talk is that so many people from marginalized backgrounds in marginalized identities will end up doing the category of work on their teams called glue work.

Glue work is all the tasks that fall in between things that are considered engineering tasks or technical tasks, but things that are still critical for the team to function as a cohesive unit. An example is, when you're on a team and you recognize that nobody has written onboarding documentation. The new joiners are having a hard time ranking up because nothing about this is written down. So, you might take it upon yourself to develop an onboarding checklist or write some documentation or come up with a system where new joiners pair with somebody old and have a buddy system for the first few months or weeks that they're there.

But a thing that happens very often with glue work is that you don't get promoted for it. Glue work is easy to mentally anchor on because so few people are doing it. You often get really positive feedback about it, which sounds really nice, but it's easy to write a piece of feedback. Jiaqi, you developed this onboarding program for new joiners, and it was so great and now, people are really happy on the team. But that's not the thing that people get promoted for. People get promoted for engaging with difficult technical challenges, from doing technical leadership, and for doing things that are hard to write about, and hard to get feedback about.

Glue work is one of those things that I am so conscious of for my own career and as a manager now, I pay attention to who's doing the glue work. And if I see someone doing too much, I tell them, "Hey. I want you to prioritize. I want you to know that the things that we promote people for, at this organization..." I'm not saying GitHub in particular, but most tech companies promote people for delivering on technical work.

You can do a certain amount of glue work. I've actually found over the years that doing a certain percentage of glue work actually makes me happier to come into work. There was a time that I kind of swore off of glue work. I was like, "I'm not going to do this anymore until I get promoted to senior, until I get this or that." But I found that swearing off it 100% actually made coming to work every day difficult because people were unhappy. I saw the team wasn't cohesive, and nobody else thought it was a problem worth solving. And I was like, "But I care about my team being happy. People being unhappy around me brings me down." It makes me want to come to work less and be less motivated to actually do a good job, to get the technical achievements that I might need to get the promotion.

I figured out my own balance, but I definitely encourage people to think about the balance of technical work versus non-technical work that you want to invest your time in and do it. Whatever percentage you choose, do it deliberately. Don't let yourself keep getting suckered into glue work because there's no one else doing it. Because the worst thing that'll happen is things will just go back to the way they were before. You won't get penalized for doing the same as everybody else.

That was a very long explanation of the Being Glue talk. But I think about that a lot. And that was 100% a Write/Speak/Code insight. I don't think I would have come across the concept, or come across a whole cohort of other people going through exactly the same problems in their careers without having heard that talk, without having been in the room when the follow-up discussion happened for it. So, that's one very, very big way that, I think, Write/Speak/Code changed my life. There are more examples of talks like that.

But conference speaking as well. Jiaqi, you've spoken at Write/Speak/Code before and other places. How do you think that conference speaking has affected your trajectory or the shape of your career as an engineer?

Speaking at conferences

Jiaqi Liu: That's so interesting. I love how Tanya put a name to glue work because before that, you had this inkling that, "Oh, this isn't helping my career," but you didn't really know why or what to call it even. Maybe this is funny, but I actually think speaking at a conference can sometimes be like glue work. You get a lot of recognition for it, and people really respect it. But it's not what's going to help you get the next job or get promoted. But it does help you build up that skill set of public speaking which is really important even within your day job, too. You're ultimately going to have to present your ideas in front of other people. And feeling comfortable in that setting is really important.

And then secondly, it kind of gives you your own brand recognition. The more you speak at conferences, I think the more people will seek you out either for the ideas that you're presenting or just speak at future conferences where you'll get to meet other people. It is a really great way to network, especially for me, being very introverted, I'm not going to walk up to someone at a conference and introduce myself. But when I'm a speaker at that conference, other people are coming to me. So, I do think speaking, while it's a little bit nebulous, you don't know if it'll get you the next opportunity, it does present you as a subject matter expert within the community. And then that sort of opens up many different opportunities that you otherwise might not have known about.

Denise Yu: Yes, absolutely. One thing I think about a lot is decoupling your personal brand from your brand within a company. I empathize so hard with what you said around doing a conference talk, even keynoting a conference might not be the thing that gets you promoted within your current company, but it's going to set you up for bigger opportunities in the future even if you can't see exactly what form that takes just yet.

I shouldn't say this because I'm not a lawyer. But I have heard a lot of evidence that having conference speaking under your belt and published writing in books, magazines and white papers, helps you a lot for getting those fancy Visas. If you ever want to work in the UK or the U.S. or the EU or someplace where you might need evidence of being an established professional in your field, that actually does help a lot for that.

Conference speaking has definitely been such a big part of my career. I can't really imagine what my tech career would have looked like without it. I also hate going up to people at conferences. Being a speaker, honestly, is the best life hack ever for being an awkward person who hates unstructured interaction. People literally just come to you and are really nice to you.

What have been your best conference speaking experiences so far?

Jiaqi Liu: Write/Speak/Code has been amazing. One of the things I'm still thinking about is the first time I spoke at OSCON. I actually gave a talk that I had already given before. I felt more comfortable with it, but it was twice as long as the version I gave before. So, I still spent a lot of time working on that.

I think, OSCON, which is the Open Source Conference hosted by O'Reilly was really inspiring to me because, at the time, I was thinking about how I can get more involved in open source, what that open source community looks like, trying to engage with maintainers of specific open source projects that I was really interested in. And conferences do open up those kinds of opportunities.

Write/Speak/Code, that was the first time I ever made a PR to an open source project because I was literally sitting next to a maintainer, and we were working together to get the CI to pass, get the PR to merge. I do think that having that connection was really helpful in meeting all these open source maintainers to help me get a better understanding of the open source community itself.

Open source work

Denise Yu: Do you do much open source work these days?

Jiaqi Liu: No. I sadly don't. I just don't have the bandwidth. And I think this is a common theme across open source now. It's actually very hard to find maintainers and contributors, especially given the burnout from COVID.

In my previous role, I was working on an open source project. So, this is where it's a little bit different for me. The challenge, I think, with open source is it's actually really hard to prioritize because everything on your roadmap is community-driven. It's all coming from someone who needs this for their work, for their research, for their own open source project. And there's a lot of motivation to push yourself to satisfy the needs of the community. But you also have to restrict your own capacity and bandwidth, and really focus on, "This isn't realistic for the project to have such a large roadmap. Where can we narrow down to what we can deliver that still adds value to the community, but is tangible for us?"

So, to that sense, I find it easier in corporate to prioritize because everything is more metrics or revenue-driven. I think at GitHub it's a little bit different because a lot of our roadmap is also community-driven. That's something I find very interesting. How do you balance the needs of others versus your team's needs and your own capacity?

Decisions

Denise Yu: I still don't have any good answers to this question. When I was at Pivotal, I actually did a very, very short rotation as a product manager which is not a thing that I was supposed to do. We just happened to run out of PMs at one point. And I was like, "Can I do it?" for a couple months, and they let me. I learned so much when I was in that role. My main takeaway is that as a PM you get decision fatigue so easily. And I think a lot of the role is just building up stamina to keep making decisions with sometimes very, very little certainty. You have to get comfortable with just picking a decision, understanding what your escape valves are, and just rolling with it until you see one of the circuit-breaking criteria you have to come up with ahead of time. Like, "Okay. We see this sign of failure or that sign of failure. Then we revert. We go back. We try something else."

You know, it's very interesting. I don't know how much of that you get to do as an engineering manager now, but I do a little bit of it. Obviously, I work in partnership with my product manager and my design and research team. But I think making decisions is probably one of the hardest. Having to make decisions when you are at best making an educated guess is, I think, one of the hardest parts of being in leadership in engineering.

Jiaqi Liu: That said, I want to close this out with something that's been on my mind. How do you make decisions about your own career? How do you weigh those, and how do you actually drive your career?

Denise Yu: This is so hard. I feel like you have thoughts about it. Do you want to talk through that first?

Jiaqi Liu: For me, it's actually very similar. I want to stay open-minded and willing to try anything, but also have those escape valves or know my barriers. I find being an engineering manager really fulfilling and really exciting and I see a lot more areas of opportunity for me to grow. But if for whatever reason I wanted to go back to being an individual contributor, I know that's an option. Having those safety mechanisms of, if this happens and here are certain options I can explore, makes me feel really good about my decisions and going all-in on people management, learning those set of skills, and knowing that if for whatever reason, this is not the path I want to go on anymore, I can go back to being an individual contributor.

As an individual contributor, picking an expertise or topic skill in-depth on, has always been hard for me, though because I want to go in-depth on everything. But you really do need to spend some time on a topic to really feel or get to the point even of knowing, like, here's all the things I don't know that I'm going to have to keep pushing on.

Denise Yu: I empathize very deeply with a lot of that. I try to view every new project or every role change or every new company as a learning opportunity. And I try to figure out what I like about each thing or what I don't like. I'm still trying to figure out what I want to be when I grow up. I don't know about you. I still haven't figured it out exactly and I never have a good answer. People are like, "What do you want to do five years from now?" It's like, "I don't know. Maybe I'll own a cat café five years from now." I have no idea. You know, five years ago from today, I didn't think that I would still be in tech. And five years before then I thought I was going to be a lawyer at this point.

I think a good way to approach your tech career is to seek out new opportunities. Take risks early on. Don't stay in one place for too long. When you feel like you have no more hypotheses to disprove or when you feel like you have no more stones to turn over, that's a good sign that you should be looking for a new opportunity. Not necessarily switch companies, but see if there are other things that you can do within your organization, different roles you can try. Ask if you can be a product manager for a couple of months. Maybe somebody will let you take that risk. But just try to figure out the different pieces of what resonates with you.

For me, with people management, I was surprised to learn that I actually really love contact switching. I actually really loved working in an interrupt-driven way. I was never good at doing deep-focus work. In fact, coding was the only thing that could get me into that and playing video games. Coding a hard problem was the only thing that made three hours would just fly by. There are very, very few other activities that can get me into that state. If I'm not coding, then I would prefer to be responding to things and multitasking four or five different things at a given point in time. That's just how my brain wants to work.

So, now, I have that data point from having been in engineering management for a couple of months. I'm now taking that and looking ahead to maybe running a business. It's something that I might like to do one day because that's also very interrupt-driven. Maybe doing more leadership-focused stuff, even getting further away from the technical side, towards the director track, towards leadership. You know, higher leadership is something that I might be interested in one day. But I still have a lot more data points to gather.

Like you said, you don't have to have all the questions to ask. You don't need to have all the unknowns turned over just yet. But it's important that you learn a few more of the questions that you want to ask yourself with every new environment that you're in. Every kind of new challenge or every new project, every new role that you take on. Don't take on roles that are not going to force you to learn anything new.