1:1 with Brooks Swinnerton, Senior Engineering Manager at GitHub

For our ongoing series, 1:1 with Engineering Leaders, Code Climate and Codecademy for Business spoke to managers and VPs about their career journey, leadership strategies, and advice for the next generation of engineers. Below is an excerpt from our conversation with Brooks Swinnerton, Senior Engineering Manager at Github, who shared the value of hackathons, the importance of getting to know your team members, and the most interesting management advice he’s received. Edited for length and clarity.

For Brooks’s advice for early-career engineers, visit the Codecademy blog.

Tell us about your current role. What are your current responsibilities, and how did you get there?

I’m an Engineering Manager at GitHub, where I work on a team called Ecosystem Events. And what we do is we manage the infrastructure that powers webhooks. Webhooks are kind of the inverse of an API, where an event happens on github.com — like someone opens up an issue or a pull request — and we send an HTTP request out to people that are interested in knowing. And that powers things like various parts of Code Climate, for example.

I’ve been at GitHub for about five years now. I first started out as an individual contributor on our API team. Previously, I worked at a company called General Assembly building out kind of a backend coding platform for our mobile app. And prior to that, I worked at NYU as a Systems Administrator. I’ve been in the tech scene for a little while, though software engineering specifically wasn’t something that I really got started with until I started at General Assembly.

Fast forward about three and a half years through my career at GitHub, and one of my teammates went off and spun off her own team, a one-person team to focus on this area that we now focus on. I found that particular area really interesting and I jumped ship to join her. It became pretty clear shortly after that we needed an Engineering Manager. We needed someone to articulate the problems that we were trying to solve, to the product organization and to leadership. I was given the opportunity to try out engineering management, and here I am.

Let’s start with what made you decide to get into engineering, because that wasn’t where your career started.

The beginning came from hackathons. A while ago, I actually got on a hackathon-on-wheels known as the StartupBus, where you get on this bus with a bunch of people that you don’t know. And the idea is you build a startup on your way to the South by Southwest festival in Texas.

That my first realization that, “Oh my gosh, coding is really cool.” I had done coding before, but not building web applications or anything like that. We got on a bus and coded our own startup on the way to South by Southwest. And right after that, I took a class at General Assembly known as Intro to Rails, where I learned Ruby on Rails.

I realized that I am very interested in being able to create something from nothing.

Was that bus something you had to apply for?

It was something you had to apply to. I heard about it at the New York Tech Meetup, which was this very big technical Meetup at NYU in Manhattan. I never thought I’d get in because I didn’t have any experience in coding. And met a ton of really valuable people and it was, more than anything, an amazing networking experience.

Hackathons in general are a really fascinating way to meet people.

Let’s jump forward to your next major transition, from IC to manager. Was that a leap you expected to make? Did you know you wanted to be a manager?

Yeah. It was something that I wanted to do early on. There was a sense of autonomy that I was looking for. And thinking back to the role when I started at GitHub as an Engineering Manager, it was largely a gap that I was trying to fill for our particular team. I thought that the most value that I could provide to the company was in this new role of Engineering Manager, rather than writing the code.

People often move into management because they think that it’s the next most logical step in their career progression. But what most folks who make that transition realize is that you’re really starting over. You go from being a software engineer who may or may not be pretty comfortable with like your area of expertise, to a completely different world.

I had the opportunity to move into this because the previous Engineering Manager left to move to another team and there was a gap that needed to be filled. But by communicating with that old manager, I was able to find out how to best move forward on the path to engineering management.

And did that person have any particularly good advice?

Yeah. I had to interview for the role, and I talked a lot to folks who were around me in this particular organization. Some of the most interesting advice that I got was more of a heads up that engineering management has really high highs and really low lows.

It’s really amazing that you can motivate other people and empower them to ship the most interesting things that they’ve shipped in their careers. But there are also some really tough conversations that you need to have over time as well.

How do you think the role of a manager differs from the role of a leader? Is there a difference?

I think there are fewer dissimilarities than people think. You can certainly be a leader as an IC, or as an Engineering Manager. In terms of communication, for example, delivering feedback is a really concrete way of trying to better someone on your team, and that doesn’t necessarily have to come from an Engineering Manager.

It seems like you were kind of touching on that a little bit before when you were saying, “If you want to be a manager, try to influence others and start stepping up.”

Definitely. I’ve seen a lot of really incredible people in my career at GitHub who are able to influence not just their own technical project, but the way that their team works, for example. And that’s something that really can help improve the productivity of the entire team.

You have some writing out there — some blog posts, some talks — it’s all very technical. And I know a lot of the time it’s tough for people who are thinking about moving into management to contemplate letting go of the technical side of things. How do you balance that?

That’s a fantastic question. It’s a struggle. I do try and stay technical, whether that’s on the weekends or just in my own personal time. But I recognize that not everyone has the opportunity to do that. And that’s something that ideally you could set aside time for in your day-to-day role.

For example, at GitHub, we have this concept of a Day of Learning. It’s your opportunity to brush up your skills, and you can use that however you see fit. As an Engineering Manager, you may be interested attending a conference or something like that. As an IC, you may be interested in learning a new programming language.

For me personally, what I’ve been trying to do is brush up on both.

Is GitHub usually co-located, remote, or partially distributed?

All of the above. I was looking at the numbers not too long ago. I think pre-COVID we were a large majority remote as a company.

My entire team at GitHub is remote. We have one person who goes into the office, but that effectively makes him remote whenever we’re all talking to one another. The spread on my team goes from San Francisco on the West Coast in one time zone boundary to London, England on the other. It makes for some interesting challenges and trying to schedule meetings and things like that.

Other than the obvious logistical challenges, what challenges does remote leadership present for a manager?

My default is to try and have a face-to-face communication. And we set aside time to do 1 on 1s. I do 1 on 1 with everyone on my team, and that’s pretty common practice at GitHub.

The meeting scheduling is challenging, but I think what GitHub does really well for remote work is optimizing for asynchronous communication. Whether that’s in Slack, whether that’s a GitHub issue. We use GitHub to build GitHub to an extreme — everything is documented in a GitHub repository.

We have team repositories, which represent the composition of the team that was on it, with each of their time zones, documentation on the way that we like to work, the way that we like to review pull requests. We have issues for every project that we’re working on. And what’s fascinating about working like that for an extended period of time is that you can go back throughout the entire history of GitHub and see why every decision was made and what everyone was doing at that moment in time.

That is a really fantastic side effect of asynchronous communication. It does make things challenging if you want to search through, but if you look hard enough, usually you can find the answer to any questions that you have, which is awesome.

How do you get to know your team and help them grow professionally — individually and together?

It’s a challenge as a remote employee, I think. The thing that I miss the most about being in-person at General Assembly is just that human-to-human interaction. It’s not to say that you can’t read the body language over video, but it’s just a little bit different.

1 on 1s are the primary way to talk about career progression and feedback and just kind of whatever’s on that person’s mind that week.

In addition to that, pre-COVID, what we would do is get everyone together for what we call mini summits. They were a way for us to come together, usually around a pretty tactical goal. During those there are lots of team-building opportunities and opportunities to get to know one another outside of a work setting, which is really beneficial for having a well-formed team dynamic. It’s definitely much trickier now.

What advice do you have for new managers or people looking to become managers?

I think everyone’s path is a little bit different to becoming a manager and also getting in the flow of being a manager. As someone goes from an IC to a manager, especially if you’re working with the same people, that can pose some really unique interpersonal challenges. That’s something to approach with a bit of caution, and just acknowledge the fact that’s happening.

In addition to that, I found that having a leadership coach has been incredibly useful just to have a sounding board. It’s nice to have someone to talk to who has no context of the company that you work at or the specific people that you’re talking about. I found that to be really beneficial. If you have a learning stipend or anything like that at your company, that’s a really fantastic way to use it.

I took what I believed to be a really pragmatic approach of reading as many management books as I could. And while those are valuable for learning those techniques, I’ve found that every distinct human relationship that you have on the team is a little bit different. Understanding that style and getting to know each person is step one in being an effective engineering leader.

Any last comments or thoughts?

We talked a bit about software engineering as this really interesting problem-solving experience. Sometimes that may not come to you in the period from of 9:00 AM to 5:00 PM. And especially in the time that we’re going through right now, you may able to work different hours. That creativity may come to you outside the bounds of a normal working day.

Try to optimize for that. and try and optimize your team for that, I think more specifically. If you can do asynchronous communication, now’s the time to try and take advantage of that so that you can optimize for whatever works best for you. It’s a little tricky at times, and you have to be able to pass off work. Make sure you’re very explicit about how you pass off that work. That’s kind of the key to being able to work whenever you’d like, which unlocks a lot of really awesome possibilities outside of the day to day.

How do you make sure you’re really optimizing for the way your mind works, and not just procrastinating?

It’s a really good point. I think to an extent there’s some trust that you need to have. And that’s also one of the things about being a leader — making sure that you can follow up and have real conversations of like, “Hey, how’s that project coming along right now?” Building that team communication to keep people motivated and interested and continuously communicating, I think is the key to success there.

For more of Brooks’s advice for the next generation, visit the Codecademy blog.