NOEL: Hello and welcome to Episode 55 of the Tech Done Right Podcast, Table XI's podcast about building better software, careers, companies and communities. I'm Noel Rappin. Today on the show, we're talking about engineering management. Allison McMillan is an engineering manager for the Atom Team at GitHub. We talked about what her role is within her team, how she helps the team grow and improve, and how the management role is different from her previous developer jobs. We'd also like to hear from you -- what makes a great engineering manager? Let us know what you think at TechDoneRight.io/55 or on Twitter at @Tech_Done_Right. This week on the show, we have Allison McMillan. Allison, would you like to introduce yourself? You're a repeat -- a second time Tech Done Right guest. ALLISON: I am. I'm so excited to be back. I think I was one of the first guests that you had, which is exciting. Let's see. I'm Allison McMillan. I work as an engineering manager for GitHub. I am based in the Washington DC area. I've got two kids, a toddler and a baby and I also have a podcast called Parent Driven Development, which is about being a parent in tech and I am excited to be here. NOEL: There's something about, "I have two kids and a podcast." ALLISON: It's like my third baby. It's like my baby, then it's also almost one. My baby is almost one and my podcast is almost one because I started it just before I had my second. NOEL: That's good, so you can give the podcast cake. ALLISON: Yeah. NOEL: We are here to talk about engineering management and being an engineering manager and I guess, I'm going to start with the complete, most basic question because engineering manager, for instance, is not a title at my small consulting company and I would imagine there are a lot of places where it is not explicitly a title. What do you do as an engineering manager? ALLISON: I think what an engineering manager does is very different based on what company you're at. At GitHub, as an engineering manager, I have a team of individuals that I make sure that they are growing and advancing in their careers, that they're provided with feedback that helps them grow and become even better professionals. That's sort of the people side and on the project side, I'm also responsible for working with the PM, working with a variety of folks around the company to execute on the product. I'm the manager for Atom, so I'm thinking about Atom's roadmap and where we're going and what we're doing and talking to different departments around the company, as well as a little bit of talking to users. That is what engineering management is for me. NOEL: You're not the project manager because you said you meet with a project manager. ALLISON: Correct. NOEL: And you're not quite a personnel manager because you seem to be doing stuff that's outside of that realm as well. Is it more like being a product owner or not, I guess, would be the question? Who, in this context, is responsible for setting the long term roadmap, the short term roadmap and the day-to-day implementation details? ALLISON: We all work together as a team to do that, so nobody says like, "Here are the features that you're building, go build it," and this is I think a little bit unique because Atom is also open source, so we're listening to the community and we're working with the community as well and together with maintainers, with the team, with leadership, with all of those individuals, we think through what do I want to build, what's the ultimate goal, what are users asking for, what does all that look like and then breaking it down. I guess part of my job is making sure that I'm looping in all the correct people and making sure that I don't jump into the code in terms of like I'm not responsible for shipping but I also have those conversations when there are questions about what direction should we go in, what do we want to do. I sort of jump in and help just ask the questions -- what directions are we looking at? And what are the tradeoffs of each of those directions? How do we decide together as a team? What we want to do? Are we making sure that we're communicating, documenting, etcetera for future us? Why we made this decision? What do we think it's going to look like? -- those sorts of things. NOEL: That's sounds like a little bit of keeping the engineers on track. How many engineers are you engineering managing? ALLISON: I manage four right now. NOEL: It sounds like you kind of balancing everybody's input and making sure that the whole project continues to reflect all of the different stakeholders. Is that a fair assessment? ALLISON: Yeah. I think that sounds about right. NOEL: I used to... I don't remember who the comedian was, who used to do a lot of crowd work and somebody would explain their job and he couldn't understand it and he would say, "What would have to happen for them to say, 'Oh, my God. Get Allison.'" What would have to happen if somebody say, "Oh, we really need Allison on this?" Are you spending your day meeting with engineers? Are you spending your day meeting with project managers? How does that break down? ALLISON: I try actually not to meet with my team a lot because you want your engineers to have lots of open time and not have so many meetings. I do weekly one-on-ones with everyone on my team. We do retrospectives and sprint planning. I mentioned this idea of incorporating everybody's feedback and ideas and making sure that we sort of know what direction we're going in and why. I think a lot of my day is spent on -- outside of improving the team and making sure that the people that I supervise are happy and feel like they're progressing in their careers, etcetera -- it's meeting with other departments and talk about what ways can we work together. I think Atom is also a little bit unique that there are a handful of folks that are sort of on the Atom Team but report to someone else because it's very cross-functional. I also do one-on-ones with them to just sort of talk about what's going on with the team? How are you feeling about our roadmap and what's on our plate because I think for us, there's a technical roadmap but there's also how we engage with our maintainers, how we're engaging with the community, when is the next release, what's that looking like, etcetera. It's a lot of moving parts, a lot of consensus building, a lot of doing things like that. NOEL: This is something that we've actually talked about on the show in the past but what in your situation does an effective one-on-one meeting look like? What do you do to prepare for it and what makes you think that it's going really well? ALLISON: That's a great question. I did longer one-on-ones when I first started and now, they're a little shorter. I think from my first couple of months, my one-on-ones were longer because I was really trying to get a sense of each of my folks and I really wanted them to get a sense of me, so instead of having to directly dive into business or what was on their mind or whatnot, I wanted to get to know them as people and I wanted them to get to know me as a person. It's also really important because everyone's remote. My whole team is distributed and if I'm trying to limit the amount of meetings that they have in a week, that one-on-one time is sort of our primary face time. We talked a little bit about ourselves. I really wanted to get a sense of what influences their day-to-day work, what motivates them, what things they love about being on the Atom Team or the specific thing that they're working on, what things they dislike, what things they love about GitHub, what things they dislike, etcetera. They were a little longer in the beginning. We also were setting goals and just talking through that process. Now, actually, at GitHub, we generally use repositories for everything, so each of the folks on my team has their own private personal repository and that's where we take notes from one-on-ones to make sure that we're on the same page. That's where they will track goals, all those sorts of things. One thing that I actually did that I learned from someone else was I have an issue template in there and so, I do ask all of my folks or at least, we're doing this right now and it seems to be working for most folks. There's an issue template and it basically starts with what's on your mind, what can we celebrate this week, what is frustrating or confusing to you right now, and any feedback that you have for myself or other folks on the team and then also, what is the most important thing that you want to accomplish in your next week. In that top part, under what's on your mind, I also have a link to about 30 different conversation starter, one-on-one questions, so that if they're not sure what's on their mind or they're not ready to talk about what's on their mind, they can always look at that list to sort of jog some thoughts or just say, "Oh, this is a really interesting conversation. I want to talk about this with Allison." Some folks will fill that out beforehand. They'll spend a little bit of time prepping for the one-on-one and they'll send me a link, so I can see what our quote-unquote 'agenda' is. Some folks, we just use it as the template and I'll take notes while we are having our one-on-one and the nice thing about that is that I will comment on the notes and it's their responsibility to close the issue and closing issue means yes, these notes make sense to me and we are on the same page about things before our next one-on-one. A successful one-on-one to me is one where folks feel like their achievements have been validated and acknowledged, where they've been able to talk about anything that's on their mind and where they feel like they've received some sort of clarity or at least, had a conversation about anything that was potentially confusing or frustrating or whatever to them. NOEL: Do you use the previous issues as input to the next meeting, to go back and see like, "You said that you wanted to accomplish this this week." Did that happen and if not, what stopped you from doing it? ALLISON: Yeah, we do. When I take notes, usually there's a section for action items and anything that we've decided is sort of like a follow up that they're going to do or that I'm going to do. It gets put as an action item. Then I'll make sure to revisit those and see sort of like did I fail, were there action items that were assigned to me that I didn't get done and if so, I need to explain to them, like what my issue was and why that didn't get done. If that was on their plate, it's a conversation like, "Did you have a chance to do this? Why or why not?" About halfway through the quarter, we also usually revisit goals to make sure that there's sort of progress being made and I try to give a little bit of end of quarter feedback. I'm a sort of like an early and often feedback sort of manager, so just to make sure that we're touching base on stuff. NOEL: Do you also own that quarterly goals process with them? ALLISON: Yes. NOEL: How does that work? This one, I'm really curious about because I'm really curious about how different companies handle this kind of thing. ALLISON: At GitHub, there's no formal quarterly goals process. It's sort of manager preference. I have, I guess a helper worksheet that I've developed, actually based on a conference talk that I did. The goal is to have SMART goals -- goals that they can accomplish within a quarter, that are measurable. Each goal has set out the goal and then you outlined two or three action items, what are the smaller things that they'll do in order to make that goal happen. I really encourage folks to not relate their goal to specific roadmap items. Let's say there's something that we want like a feature that we are going to move forward or something that we'd like to do for that product. I don't want someone's individual goal to simply be like, "Help roll out X feature," because things change and the feature might take longer. We might decide to deprioritize it. We might decide to do something else and so, I try to encourage folks to think about like thinking about your career progress. Where do you want to be in five years? Where do you want to be in one year? And in order to be there in one year, where do you sort of need to be in six months, to think about a goal that gets them there. It could be learning more about a specific topic and then action steps or reading a couple books or doing tutorial or whatever. It could be improving a team dynamic in some way. I also encourage folks to think about individual, team, and company. Thinking about this career progression, thinking about where they want to get to in their career, what can they do to improve themselves? What can they do just for themselves? What can they do that will be something that they can learn or do more effectively that will ultimately help the team? That might be like become a more effective pair or mentor or something like that and then, what can they be doing as an individual that improves them but is in service of the larger company. Those are a little more difficult but that's sometimes a conference talk or blog post, or different things like that. They don't have to have three goals. They don't have to have a goal for self, team, and company but I find that they're sort of good lenses when you're brainstorming goals and when you're thinking about like where you want to be and what you want to do in life and what you want to do in your career. There are three good levels to help sort of jog, thoughts, and brainstorming and whatnot. NOEL: I really take the point about not tying those things to roadmap things. Not at Table XI but in the past, I was in a company that had a six-month cycle and invariably, you'd set the goals and invariably, the project will get cancelled and six months later, you sit down with your manager and you'd look at the goals and be like, "I don't even remember what that project was." ALLISON: Yeah. Really, the big thing is like, "You know, if I look at your goals in three months and I say like, 'Oh, none of these are accomplished,' so therefore what? You're not eligible for a promotion?" or you don't meet expectations because the goals failed because something change that was completely outside of your control? That's just crap. NOEL: Yeah. How do you evaluate that? The goal is to ship Project X and Project X got cancelled two weeks in -- failed? Success? I have no idea. ALLISON: Yeah. NOEL: And a quarterly cycle -- we have a six-month cycle but with pretty frequent check-ins and it's not the most rigorous SMART goal process that we explicitly are tracking individual things but where does that information go? The goal information, is that an input to something else? Is that an input to your regular one-on-ones? Is it an input to annual reviews or anything like that? ALLISON: Yeah. We have sort of like a more formal six months process with larger year-end reviews or larger annual review cycle. GitHub has, for engineers, their engineering levels and there are things that you should be doing in each level. With quarterly goals, I asked every one and this is something that I continually asked them where do you think your strengths are and where do you think your areas of improvement are? And then we look at the areas of improvement and see where that maps to these different levels: in order to maintain in an engineering level or get to the next level, this is a place where you need to improve in order to get a promotion or make it to the next level. Setting some quarterly goals based on that, so that there is regular progress. We don't get six months or a year in and say like, "I know that you want to grow but we actually didn't take any time to ensure that you are taking the steps towards that next level. Sorry about that. Try again next year," sort of thing. The other interesting thing for me, which has honestly been a challenge, is I think, well I won't say, especially GitHub because I think this is anywhere. Some folks are like they've reached the level that they want to reach and their goal is not necessarily promotion to the next level. Maybe they're just really happy with where they are and the influence they have with the company and the kind of work that they're doing, etcetera, and their goal is not to get to the next thing. In that way, their ultimate goal is to maintain but continue getting even better at the items that are in that level. In that case, we really drill down like, "This is list of things that are in this level. You're obviously doing all the things in this level but even within that, what do you think you could improve upon?" because there's a difference between achieving a thing in a level and kicking ass at a thing in that level and so, we'll talk about like, "These are the things you're achieving and these are the things that you're like kicking ass on. Let's figure out what personal goals, what professional goals can be set so that even if you don't want to go to the next level, you're continuing to grow, continuing to be challenged and kicking ass on even more of these components." NOEL: We have two separate processes. We have an annual review process, which is in transition and changing right now, so I can't even really speak to exactly what it is or what it's going to be but we have this six-month cycle process that is bounded by a thing where we have the employee and their -- the internal term is sponsor and then another relatively senior person. They all get in a room and they just do a big brainstorm on sticky notes of what success will look like over the next six months. I've sat in on this and I've facilitated this for a lot of people and I definitely see that it's definitely easier to identify new career goals for somebody who is like an entry level or relatively new developer. I think that a lot of times, as people move on in their careers, it's not that they don't continue to get better but that sort of like rate at which they increase, like their acceleration, for lack of a better term, kind of decreases like as you were saying, it's sometimes very hard to identify a set of goals for somebody who is kind of mid-career and comfortable with what they're doing. Not looking to break into a new technology but looking to continue to do the things that they're doing, only better. ALLISON: Yeah. I think also as you become more senior, you decide what you like and what you dislike. You say like, "I could be like architecting systems but actually, I really like -- NOEL: Performance optimization or something like that? ALLISON: Right. Exactly. Theoretically, that's an area of growth or maybe like the next level. It's like architecting systems, design but that's actually not your jam and that's not what you're into and so you're okay with not doing that and just sort of like hanging out where you are. But I think that, especially folks that enter this industry, I think that if you're not challenged, then you're bored and so, you still need to be growing and developing and learning new stuff that you find interesting but doesn't necessarily have to be something that you're not, that you sort of like tried before and just you're not really into. NOEL: Right. Using myself as an example, I've been a Rails developer for a long time now. I'm very comfortable and happy as a Rails developer. I do sometimes look for new things, so it's not a perfect example but even if I was just wanted to be a Rails developer, they're still new stuff: Rails itself changes, there's new tools. You can't kind of standstill and still be a viable developer for more than a few months or a year or something like that. ALLISON: Yeah. There's also a whole huge skill set of like, "It's great if you're really comfortable with Rails but how do you teach other people the love of Rails? Or how do you communicate with others? How do you weigh in on team conversations that make other people feel like valuable important members of the team as well." NOEL: Yeah, those are the team level goals, like how do you leverage your abilities to build up a team, which is in some ways, the definition of a more senior developer. ALLISON: Uhm-mm [affirmative]. NOEL: You were a developer and you became an engineering manager. What sort of drew you towards that engineering manager side of the development process? ALLISON: This is interesting and I think that for me, they're always like both a push and a pull. Before I became a developer, I was a manager in a different industry and so, the draw of engineering management for me was that I do really enjoy figuring teams out, helping them be better, helping to facilitate conversations, facilitate really interactive, interesting ways of moving products forward and moving teams forward, helping individuals recognize where their strengths and areas of improvement are, how to get there, how to set goals. I do really enjoy that kind of work and enjoy that space and enjoy just recognizing how people and teams can improve and can really just be an amazing experience for individuals and also, just being somebody who's supportive and kind. I've had a lot of bad managers. I feel like a lot of people have had a lot of bad managers and managers can really make or break work experiences. Being a manager that helps people really enjoy coming to work and enjoy seeing what their future path is and where they say, "I'm looking forward to going to work because I'm looking forward to talking with my manager and my team, that it's more than just sort of like a clock in/clock out thing," and they feel just appreciated. I would say that was like the pull towards engineering management. I think for me, there is also honestly a bit of a push and that was that I've held a couple of positions as an IC and I feel like I was always looking for the company that was just really great at leveling me up at taking all of the excitement and passion and motivation and just like brute force learning that I wanted to do, just being able to sort of foster that and catapult me to the next level. I think what I found was that a lot of companies just don't really know how to do that well or really effectively. Because when I took this position, I actually wasn't really looking for an engineering manager position. I was just sort of trying to figure out what next steps might look like and where I wanted to go in my career. I always thought that I would stay technical for a little while longer and continue to be an IC and continue learning but I guess, when I realized that I just wasn't finding that structure or that experience that would quickly catapult me technically and so in that way, when this opportunity me, when this opportunity for engineering management came along, it was both a really interesting opportunity to do management and to do the things that I loved within management and also that I felt like I wasn't finding that right fit, that right company, that right place as a self-taught, career-changing developer as an IC. NOEL: You needed to have yourself as a manager, is that what you're saying? ALLISON: Yeah. Not myself because I've had some really good managers. It's not just a manager. It's a team too, so it's like a company that has a good structure in place, that has the right team with the right manager. NOEL: I don't think it's that unusual for somebody who has the systems intelligence and the systems outlook on the management side to wind up being frustrated in an IC role if you're the person who can see how the team works, how it should be working but you're not the person who can really move those levers, I can see why that would be frustrating. ALLISON: Yes. It was sort of like the opportunity to go into engineering management at GitHub come along, it was just a really phenomenal opportunity and I wasn't finding what I would see is like the best right next step compared to this management opportunity. NOEL: So has it been what you expected? ALLISON: Yeah. It's interesting. I recently did a little bit of reflecting on since I've been a manager, what -- NOEL: How long has that been, by the way? ALLISON: It has been full time since the end of June. I say that because technically I started while I was on maternity leave. I've been at GitHub for longer but it wasn't full time until the end of June. NOEL: So that's a little more than six months as we started taping. ALLISON: Yeah. NOEL: Okay, sorry, so you look back and reflected on your six months and --? ALLISON: What I thought about was actually what I feel like I love and what I feel like I've lost and what I feel like I need to look out for because when I did my reflection, when I was thinking about, was like the challenges between the two roles are so different. To me, the challenges are so, so different. I thought about like what are some of the things that I love, what are some of things that I feel like I've sort of lost and then, what are some of the things that I know that I need to keep an eye out for to make sure that it doesn't become an issue. NOEL: I really like that as a framework for looking back: what do I love? What have I lost? What do I need to look out for? ALLISON: Yeah. I like thinking about what I lost because I've lost it. Not necessarily upset, it's not necessarily an issue but it's just the reality. NOEL: I feel like when you're thinking about changing job roles, the hardest thing to predict is the stuff that you have in the current job that you're not going to have in the new job. You just assume it's going to be there whether it's responsibilities or perks or team things like that. Where I have been surprised switching jobs or switching roles is where I assumed something would continue from what I had been doing before and it just didn't. ALLISON: Yeah. NOEL: I don't know if that matches your experience at all but -- ALLISON: Yeah, absolutely. NOEL: You said the challenges are really different, one way or another. How would you characterize? Is there a theme to how you would characterize the difference in the challenges? I guess there's an obvious answer, which is that I used to type code all day and now, I don't. But is there something that's a little bit like less obvious or was more surprising? ALLISON: I think it's sort of a more complex version of that. My challenge used to be like this is a really hard problem. How can I break this problem down? What are the technical components of this problem? What are the tradeoffs? What do I need to Google or what blog post should I read? How do I sort of move forward? Who are the people that I can talk to? But it was all sort of architecting or like what are the right inputs for the output that I need and now, it's people. You're still sort of like who can I talk to? Who may have been in this situation before? What can I read that can help me? But there's so many more nuances to thinking about like who is this person? What's their personality? What's going on in their life that could be affecting what's going on? What are they talking about and why are they talking to me about it? Do I think it's really the problem that they're having or is there something potentially deeper that we need to uncover? And how do we move forward on it? I think that any time they you're dealing with people and emotions and what's going on in their life and all sorts of things, it's just different. That's why I think the challenges are so different because technically, how do I move forward on this or what can I just I try? This is maybe the good explanation, like with a computer, you can try 100 things to see if any of them moves you forward at all. With a person, if you try 100 things, it's going to be mentally and emotionally exhausting for them. NOEL: And they'll going to get very mad at you. ALLISON: Right. You don't want to try to go down one path and be like, "Yeah, it actually isn't working. Let's go back and let's try the tough love approach. I'm going to yell at you a bunch. Oh, that's not working for you? Let's try if I just like ask you a whole bunch of questions. Oh, that's not working for you?" You can't do that because it's confusing and it's not effective. NOEL: You can't recompile people. ALLISON: Right. NOEL: A couple of months ago, I was talking to Jamey Hampton and they said, they'd just taken on a more senior role at their company and said that one problem that they had was they were used to measuring their day by the amount of code written and that when the day-to-day responsibilities were no longer writing code, there was a psychological effect that it was harder to feel productive. Did you have something like that too? Or was the fact that you have had management positions in the past sort of insulated you from that? ALLISON: Yeah. I think because I have had management positions in the past, I was a little inflated from that. It's funny because one of the things that I have on my lost list is shipping. I think that I knew that going into this role, you have to measure yourself and your progress differently. You have to look at as it's not necessarily going to be a day-to-day thing. It's going to be like in the last three months, where is my team? How are they feeling? How are they doing? We've had some tough conversations, have we come through those tough conversations? Is there a trust? Is there a relationship developed? You really have to look at it on a much larger scale and so, oftentimes, I won't, at the end of my week, sort of look back and be like, "Great. What did I accomplish? What did I ship?" But I'll try to say like, "In the last month, I know that I wanted to have these conversations or kick off these conversations with people, how did those go?" It's interesting. One of the things that I've found that I need to keep an eye on for myself is making sure that I don't drain my emotional bandwidth at work. You're dealing with people, you're having so many conversations with lots of different individuals, that all have lots of different emotions and different things going on in their lives and at home, I have a three-year old and a baby and toddlers have big emotions and part of my job as a parent is also to help my son recognize the feelings he's having, recognize the causes of those feelings, sort of like work through what he needs to do for himself in order to cope with these big, big emotions. There is a time at work where I felt like I was giving all of my emotional energy at work and I found that at the end of the day, I didn't have as much patience for the meltdown because the cheese was on top of his pasta, instead of next to his pasta or something, which is like... I don't know. As the mom of a toddler, you just need to have patience around that stuff and be like, "Yes, I understand. This probably feels like the worst thing that's happened to you in your whole entire life and maybe it is, because you're three. Let's talk through that." That's something that I always keep an eye on is making sure that I'm not maxing out my emotional bandwidth at work so that I still have some left for my family. NOEL: I did want to have one more question that I was curious about. What is something that you have either done over the six months or hope to do over the next six months that you think has made or will make you a better manager? ALLISON: I think right at my six-month mark, just a little while ago, I put out a survey -- an anonymous survey -- to everyone that I have some sort of one-on-one with. That's both the people that directly report to me, as well as the folks that don't directly report to me but work on my team in some capacity. I asked questions like where do you see the places of improvement? Have you had any sort of conflict with me? How do you feel like it was handled? Do you feel like there was a resolution? I looked at the GitHub company values and just on a scale of one to five, rate me on how you feel like I am upholding the company values. It was really helpful for me to see and actually, it sparked conversations with a bunch of folks on my team because there were a few folks who were like, "We don't really want to fill this out anonymously but let's talk through these questions because we feel like they're really interesting and we want to give you this feedback." It sparked a bunch of really good conversations and then, just also gave me some really positive and some really constructive feedback about where I can go and how I can move forward as their manager and really, pinpointed a couple of really immediate things that I could work on and even since receiving those survey results, I've gotten feedback from my team that said like, "We gave you this feedback a while ago and we've seen improvements. Thank you so much for putting that on your mind and working towards improving." NOEL: That sounds great. Where can people reach you online, if they want to talk to you some more about engineering management or Parent Driven Development or anything else? ALLISON: Parent Driven Development is ParentDrivenDevelopment.com and you can find me on Twitter at @Allie_P. Those are probably the easiest places. NOEL: Great. Well Alison, thanks for being on the show. It's great to have you back again and we'll do this again in a year or so. ALLISON: Sounds great. NOEL: Tech Done Right is on the web at TechDoneRight.io and on Twitter at @Tech_Done_Right and it is available wherever you listen to podcasts. The show is a production of Table XI, which you can find on the web at TableXI.com or on Twitter at @TableXI. It's hosted by me, Noel Rappin. I'm on Twitter at @NoelRap. And it's edited by Mandy Moore who is on Twitter at @TheRubyRep. If you like the show, tell a friend or a colleague or your social media network or me or random people on the street. That would all be very, very helpful and a review on Apple podcasts helps people find the show. Table XI is a UX design and software development company in Chicago, with a 15-year history of building websites, mobile applications and custom digital experiences for everyone from startups to storied brands. Find us at TableXI.com where you can learn more about working with us or working for us and we'll be back in a couple of weeks with the next episode of Tech Done Right.