This is the transcript of my conversation on @FromSourcePod with Zoe Gagnon, an engineering manager at Meetup. Zoe has worked across a wide variety of environments, technologies, and methodologies. Zoe’s goals are to help companies learn how to build and sustain those teams. We talk about Zoe’s thoughtful approach to engineering and people management to make the best products.
This has been edited for clarity. This was recorded in 2019 and Zoe is no longer at Meetup
Michelle: Zoe, can you tell us your current job title and how long you've had that job?
Zoe: Yes, I'm an engineering manager at Meetup. I've been there since July.
Michelle: What does an average day look like for you?
Zoe: It actually varies quite a bit. One of the primary goals that I have at Meetup is helping the engineering team learn better ways to build software. A lot of my time is spent with my particular team, teaching them basic practices like test driven development and pair programming. A lot of my time is also spent with the broader organization, helping them to identify, reinforce and amplify things that are going well. Also helping them to find places where our practice isn't as strong and identify the tweaks and changes to get better.
Michelle: Are there metrics that you use to determine if a process is going well versus a process that is failing your engineers?
Zoe: Yes and No, I find that metrics by themselves tend to tell us part of a story. They don't always give us a clear path forward. One of the first things I'll ask people is how they feel, whether or not they're enjoying what they're doing. Whether it's easy or hard, whether it's kind of joyful, or whether they have anxiety about it, or if they're afraid of something. Often, those sorts of baseline feelings can give a lot of color and depth to see how different things are going.
Zoe: Beyond that, I might look at some hard metrics in order to help me understand why people might feel that things are hard, why people might be afraid. A thing that I like to pay paticular attention to is the stories cycle time, which is how long it takes to go from started to finished, to actually in the hands of users and being used. I also like to look at the team's volatility, which is how much their points delivered varies from week to week, or sprint to sprint. Those two things can also help me identify, in general some kinds of challenging places that a team might be in. But it really comes down to asking people, how does it feel, do you actually have an easy time doing this? Do you feel like you're going fast enough? Do you feel like you're being blocked? That's often the biggest indicator to help people find good paths forward.
Michelle: It sounds like a very holistic approach. Not all managers are obviously as proactive as you. If someone is not feeling happy and their managers don't do this, would you suggest they bring it up with their own managers?
Zoe: Absolutely. My philosophy in management, particularly in engineering management, is that the manager's main role is the success of the people that they are coaching. Success both in their current job and in their career overall. If people aren't feeling that success, they won't be able to perform at a high level. The ultimate goal is to create high performing, not people, but whole teams. Whole companies that can perform at a high level. Being satisfied, feeling that you are succeeding, feeling that you're growing. that's a really key part of that.
Michelle: I definitely agree. I think sometimes managers can focus on one high performing individual rather than the success of the entire team. What's the most boring but essential part of your job?
Zoe: Required training is probably the most boring but essential part. When you're a people manager, there's a lot of responsibility that comes with that from a legal standpoint. It goes beyond just you're getting your work done, but it's also about making sure that the company's liabilities are covered, that you're standing up for your legal responsibility. It comes down to staying up to date with different trainings. Once every quarter or so I have to take different online trainings, and it's quite important, but it's also terribly boring.
Zoe: There's another boring part that I'm actually trying to reduce, which is a lot of status meetings. Often status meetings I feel are much more of a sign that you're not communicating enough. You're not being transparent enough, especially proactively. Right now, I do go to a lot of status meetings, but my goal is to make those obsolete just by continuing to communicate more and more.
Michelle: What is the most stressful part of your job?
Zoe: On an ongoing basis? The most stressful part of my job is being on call, just because it's very very disruptive. Beyond that, there's definitely times when people are not succeeding. In that case, as a as a manager where I view my goal is to help people succeed, it can be really difficult and stressful to help them navigate a way to get back on track. It's something where we could fall back to the lowest common denominator of management and just tell people what to do. But that's not something that really helps people in creative roles like engineering really succeed and thrive.
Michelle: I find it interesting that you're on call because I generally think of on call as a DevOps or IT manager position. Can you talk about why you are on call and how often you are called in?
Zoe: One could almost think that is like the theory of creating software. First off, I feel like DevOps is a philosophy for how to approach deployment, rather than necessarily a role that a person fills. In a DevOps kind of philosophy, and this is something that I encourage my team to work for, I have developers stepping into most of the ops roles. My goal as an engineer and my goal of teaching my team and the company around me is that product engineers are responsible for solving users’ problems using software.
Zoe: Everything from start to finish and beyond finishing, the product engineer is really responsible for that ultimately. If a user cannot do something, if they can't get their problem solved, then that product engineering isn't done yet. I help my team learn how to not just write software, but how to deploy software and how to own that software for the rest of its life. This has some really good effects at the end of the day, because the person who is most capable of debugging a problem that happens to some software is the person who wrote that software in the first place and the people on that same team who share that knowledge. This is particularly true on my team since we pair program, often. Whoever's on call directly had a part in writing the software that is breaking.
Zoe: That extends to me too. As long as I'm writing code that gets into production, I'm also going to be in the on call rotation. That's something where we can provide a much healthier experience, because we get to see how does this break? How do our users suffer from this? How does it make their experience worse? So that we can not only stop whatever the current page is about, whatever that alert is, but in fact, go back and fix the problem so that it doesn't happen again.
Zoe: As far as the kinds of problems I often see these days, we're actually transferring ownership of some code. With that, we're looking at the different things, the metrics that we want to alert on. We've written a whole bunch of alerts, and many of them are not actually very good ones yet, because we haven't seen the impact that our users are having. The last time I was on call, I got a lot of pages that didn't really mean anything. That was really particularly frustrating.
Michelle: It sounds like the next step is wading through the too many pages and figuring out what the right alerts are. The ones that are actually show stopping.
Zoe: Absolutely. What we want to do is realign our alerting to things users want to do. This is Meetup, where people can join groups. From those groups, they can attend events. Those are the places where we really want to focus our alerting in the future. When people can't join groups, when people can't find the group that they want. When people can't join an event, when people can't find an event that's interesting to them. Those are cases where we really want to start focusing our learning.
Zoe: We need to say the things that really make us, us the things that users come to our product to do, we need to make sure that those things are working all of the time. Users can always find the groups they want to join and the events that they want to attend, so they can meet up in real life. That's the core of business and who we are. We want to make sure that we're always providing that at the highest level. That's where we really want to start taking our alerts and focusing them.
Michelle: It sounds like you're going to have a very core product focused alert system to cut down on the noise. To make sure that if the users can't use the core functionality, a fix is immediate, but otherwise it can wait until business hours.
Zoe: Exactly. That's a really great kind of balance to strike. Being on call is stressful, being woken up is bad. If you're at brunch, and you have to pull out your laptop and spend the next hour fixing a page, that's not going to make you very happy. It's not going to help you recover from your workweek. It's just gonna carry that on. We really want to find the right balance where we're staying focused on the user's core capabilities. We're also saying there are things that we're willing to create an error budget around that's a little bit higher, we're going to let more slippage on these other functions.
Michelle: What skills do you find the most essential on a day to day basis?
Zoe: The most essential skills that I have to practice, particularly with my goals of helping my team and my broader engineering division find better ways to do things, are empathy, listening and patience, which is a lot harder than it might sound. However, I really need to engage with people on an emotional level to answer these questions. What are the things that are making it difficult? What things are they doing right now? What things have they tried? How can you help them find new things to do and new things to try that will make it easier.
Zoe: Patience and empathy aren't commonly associated with engineering practice. However, I've found, both as an individual contributor and a manager, practicing those skills to be vital for helping move my team forward. They are vital to me moving forward as an engineer as well. It's definitely something that I don't hear talked about much, but I find to be super, super important.
Michelle: It's fascinating that this is only my second episode, but that was also the answer on the first episode.
Zoe: Yeah, I think that there's a growing understanding that building software products in a way is very different from physical engineering. It's much more akin to industrial design in a lot of ways. Where previously an engineer might say, Okay, I need to cut something and create a blade, but the blade is very bulky, it's not good for people. Whereas an industrial designer would take into account the shape of a hand, the way that your thumb can move and the materials that they have in order to create a pair of scissors that work very comfortably. Software engineering is much closer to that second version, where we need to take many factors into account. We have exactly one material, but it's extremely versatile and flexible. We can apply it in a lot of ways to solve our users problems. But we have to really listen and find out what those problems are. Then it doubles back because building software itself is a very, very complicated pursuit.
Zoe: Don't use this as a one to one comparison, but it's kind of an analogy. A passenger car that has something like 50,000 moving parts in it. A 747 that has something like 7 million moving parts in it. If we look at every one of those moving parts a decision that needs to be made for the thing to work well, Windows 2000 also had 7 million moving parts and that 7 million decisions. Software is easily as complicated as the most complicated things that we build. We can't do it by ourselves, we have to do it together. When we're going to engage in something creative and feeling together, we really need to nurture that creativeness and that feeling this for each other. We need to empathize very strongly with each other in order to come together and build something we can't do by ourselves.
Michelle: I definitely agree with that. Actually, one of the pieces of advice I often tell people who are just coming up or career changing, is that software engineering is a team sport. If you've worked in teams before, those are transferable skills. Whether it was a work project or you were on a rowing team, knowing how to work together is really important.
Zoe: I have a friend David Edwards who one of his hobbies is linguistics, but he's a professional software engineer as well. He likes to talk about the different metaphors that we can use. One that really struck me is that making software is like a jazz band, where we get a bunch of talented people together, and we jam for a little while and release something and then we jam a little bit more and release something. Maybe we get a third release, and then people decide, well, now it's time to go jam on something else. It's very fluid, but very personal interactions like that, that I see on a lot of really successful, high performance teams who can build really great software.
Michelle: Are there any skills that were on your job description, or you were advised to have that you never use at all?
Zoe: I don't know. I never saw the job description for this job. In this case I was lucky enough to be pretty personally headhunted by a friend of mine. My interview did have an architecting session to it. I think architecting is a skill that we as an industry and as a profession tend to put a really heavy emphasis on, even though I don't think it's the healthiest activity that we could be working on.
Zoe: Architecture is generally going to be the decisions that are the hardest to change after you've made them. So starting to make those kinds of decisions before you've even begun building your product seems a little bit premature to me. It's let's make this decision when we have the least information we're ever going to have about it. If we solve one tiny problem that the user has, and another tiny problem, well, now we know two tiny things more than we did before we started. As a result, our architecture is going to be at least two tiny bits better than it originally would have started off.
Zoe: The more of those things we can do, the more we can understand what our architecture is. Rather than focusing on architectural skill, I focus on trying to identify what the problems are. What are the decisions that I have to make right now? What are the decisions that if I wait any longer to make, it will be irresponsible, I will have actually caused harm. What are the decisions that I can put off for tomorrow until I know more? What's the stuff that is in like, I can responsibly wait to answer. What are the things that have to be answered right now. It's a little bit more difficult because you're trying to see trends and forecast things. Looking into the future is really hard. On the other hand, I found it to be much, much more successful for creating software that is easy to change, and therefore easier to own for years, which is I think, the ultimate goal with most software.
Michelle: That's a really interesting outlook that I haven't heard before. If someone wanted your job, what path would you advise them to take?
Zoe: I would advise working with teams who emphasize learning and empathy over delivery or knowing. I would particularly look for teams that have a core focus on people growth, and I would dive into those teams. A lot of what I learned and what I do, I learned at a software practice consultancy. At Pivotal Labs the teams have the explicit mission of working with client developers in order to teach them better ways to deliver software.
Zoe: Of course, you can't just show somebody like, hey, you're doing it wrong. Here's a good way. Nobody's going to engage with that, right? We're going to get people to push back, especially if those people feel like they're experts. Often, of course, those people are experts. They've been doing this for 10 or 15 years. They are experts and it's very important to be able to engage with them on that level, to say, here's the things that you've been doing, that you're fantastic at. Here's things that we can tweak and being able to engage with them in order to bring them along.
Zoe: That's the kind of skill that is really vital if you want to get into a role where you're a changemaker at companies going beyond. In general, look for teams that focus on empathy and learning rather than delivery. In specific, look for consultancy roles, where you're explicitly teaching people how to find better ways to deliver and build their software.
Michelle: It sounds like it's important to we make ourselves and our teams better and that will help us build better software.
Zoe: What could help people move into the things that I enjoy doing, the things that I'm really working towards, is to build the skills to connect with people and elevate everybody. Make ourselves better and bring other people along with us. It's only successful when it's an in calling kind of activity where you're bringing people in with you. You're asking them to come along with you. You can't push people to become better. When people try to push you oftentimes, we will fight back. When somebody comes along and says you're doing it wrong, our first reaction is going to be no I'm not. You're wrong.
Zoe: Finding teams where everybody's focusing on this mutual lift, this bringing people along to say, we're we're doing pretty good, but we could be doing better. Let's work together to do better. That is a place where we immediately want to come together and we want to go on that journey together, right? We don't push back. We don't say no. We say, you're right. We are doing pretty good, but we can do better. Let's start looking. The best teams I've ever been on the and the best teams I've ever observed, they are teams that bring people along with them. Instead of dictating, they're like, hey, let's go together. Let's do it. Let's learn together.
Michelle: It sounds like you really enjoy having team members who have a sense of humility. Where it's like, okay, I've done something great, but I can probably do better. Maybe I can think of a better way, or maybe someone else in the team has a suggestion on how we can all do better.
Zoe: Absolutely. My role models are people who, frankly, they're surprised when I tell them that I have them as a role model. The really, really impactful people that I've ever worked with have all been, I wouldn't necessarily say humble, in that they won't say that they're good at things. It's not humble, like they don't want to be looked at, but they're very honest. They're very honest about their strengths, and they're very honest about their weaknesses. They're very honest about the fact that they're in the middle of their journey. They aren't done growing as software engineers. They probably won't be until they retire. They're very, very honest and straightforward about both. About being good at things and being bad at things. That's something that I really look up to. That's something that I personally strive to emulate.
Michelle: When you are interviewing someone who has not a lot of technical experience, either a student or a career changer, what do you look for in terms of potential or team fit? When there's not a very specific technical questions you can ask?
Zoe: That's that's actually a really great question. I'm going to answer it, but in a different way because I don't think either of those things you suggested are things that are really very good to look for at all. Potential is a way of opening the door to bias. When we look at somebody's potential, what we're being asked to do is prejudge them. This is certainly something in other context, we're saying, oh, I'm going to prejudge, that sounds like an alarm bell. In this case, I don't think it's quite as bad. I'd much rather look for things that people actually do and can demonstrate rather then things that they have the potential to do later.
Zoe: I don't think we're very good at judging potential of people. That falls kind of in a downward direction. We assume people don't have the potential to do things, but they actually do. I don't particularly like considering potential either in hiring or in promotion decisions. In both cases, I really want to look for things that people are demonstrating that they are capable of doing.
Zoe: In interviews, this means if I want to see somebody demonstrate a skill, I'll construct an interview specifically for that. For a person who has never programmed before I will construct an interview where I watch them learn. That's the thing I'm most interested in this person's ability to do. Somebody who's just graduated college, obviously, there's quite a few things about building production software for users that they won't have had an opportunity to learn. We want them to pick that up and then continue learning. The primary job of individual contributors in software throughout most of their career is to become better at what they do.
Zoe: Then doing that is the number two job. I structure interviews, particularly to look for the things that I'm interested in, and to see them actually be demonstrated. I'm looking for learning. I'm looking for empathy. Those are the two primary things that I want people to demonstrate, regardless of, if they are just entering their profession, or if they've been in their career for 10 years.
Zoe: Team fit is often weaponized against marginalized people in order to get rid of them in a way that doesn't open the door to unintended legal liability. It's not something that I encourage people look for at all. Rather, again, that empathy, ability, and often patience and judgment.
Zoe: During interviews, I like to look for situations that can test those things. I generally run a pair programming interview. Often if I question somebody's patience, or their empathy, I will participate in those and I'll get into an argument as a way to see how will they handle being confronted. How they handle being told that they're wrong, or seeing somebody who's obviously wrong. I might get in an argument about something that's ridiculous and be completely incorrect about what I'm saying in order to particularly see how somebody handles that. Those are things where it's looking for, again, specifically demonstrated skills that align well to potential without being as open to bias. And to team fit, without being open to bias.
Zoe: Being a person who has patience, has good judgment in how they interact with people is highly empathetic. Those people are going to fit in well to teams. People who demonstrate a joy of learning and willingness to do so, those people are going to have high potential and I specifically look for demonstration of those skills.
Michelle: That's a really cool way of finding people and a very forward thinking way. I hope more managers take that to heart instead of focusing on specific technical skills,
Zoe: The team fit one in particular. Once upon a time I was fired for team fit two years after I began working at the job, so it obviously wasn't team fit. I had coincidentally just come out as transgender in that office. That definitely informed my view of team fit as a metric ever since. I've had first hand experience of how that it's often leveraged in ways that are not very fair.
Michelle: Absolutely. When I talk to people about this, and they say, oh, they told they didn't get the job because of cultural fit, I sometimes say, well, that sometimes is just the person thinking, this is a person I wouldn't want one have a beer with. Which is a terrible metric for judging a person you want to work with. Because maybe they don't want to have a beer or maybe you should have people that challenge you and not just want to hang out and tell you how great you are. So that's the phrase I feel like we use in tech a lot of times to hide that, just as you're saying to hide the bias of people who are just like me.
Zoe: Absolutely. Absolutely. In general, I find that whole concept of team and culture is often a way of very, very softly saying no, actually, I'm just interested in people who look like me, people from the same background as me. That's not who I want to be. That's not how I think, really, really high performing teams operate like either.
Michelle: How are you going to A/B test if everyone's answer to how should we solve this is always A?
Zoe: Exactly. What if we get enough people in the team that we can find the ABCs Ds, Es and Fs? Our A/B testing is always stronger the more variants we have and the more solutions to a problem we have. That definitely comes from people who have different backgrounds and experiences.
Michelle: I would say, personally, as an engineer, some of my favorite activities is when a couple of us get the same challenge. When we say let's get a room and talk about all the solutions we've come up with. Let's find the best bits from all of them and put them together to get the strongest solution.
Zoe: Completely why I'm a very big advocate for pair programming as well. Many people think of it as a live code review, which I would find particularly pretty boring to do. The way I've approached it, the way many people I've worked with approach and the way the people who taught me how to do it all approach it is different. It's really a collaborative effort to get more than one kind of viewpoints about what code you're going to write even before you write it. It's a conversation with a side effect of producing some great software. Spreading that out to as much as the team to as many of the activities as possible, is a really successful route to take.
Michelle: I've found many occasions where I proposed an idea and a co-worker has mentioned a danger zone that I missed. Then I say oh no, good thing you told me this before I started or I totally would have missed it. Which is only possible because they have different experiences and maybe stumbling in the same way.
Michelle: What are you looking forward to doing next? What are you working towards?
Zoe: As a personal goal, I'm moving towards enabling larger groups of people. To have them learn not necessarily better ways of building software, but how to identify weak spots, solutions to those weak spots and move forward by themselves. Right now I'm working with a team of five people and a broader audience on a less hands on less daily kind of way. It's very hands on to say like, okay, here's a skill that can help solve your problem. Here's different technique that can shore up your practice here. What I really want to move towards next is to take broader audiences and say, here's how you identify the places that could be better. Here's how to identify those places where not everything is as smooth as it possibly could be. Here's how to find techniques that can help patch those holes. I'm really looking towards a second level up where I'm less hands on technically, but more broadly impactful at a basic level.
Zoe: I don't know necessarily what that role might be called. I have one role model that I'm looking at for that and his title is head of engineering. So that's, I guess, what I'd like to do, but I've never seen anybody else fill that particular role. I don't know what other companies might call it, but that's definitely where I want to be. At the company that I'm at right now, that's some place where it would be helpful for the engineering team there to move in that kind of general direction. More broadly saying where are the places where it's not as smooth, not as easy? How can we make it easier.
Michelle: So not just inspiring individual contributors and supporting them, but also creating and helping leaders. You wouldn't be just a leader of individual contributors, you're a leader of leaders, broadening out your impact.
Zoe: The next step to follow the path that I'm on is to help engineering business units or departments or engineering teams. I want to help them to develop the idea of engineering as a practice, as a set of tools and techniques that they apply, and constantly improve on, sort of like we look at a legal practice, where it's not a routine.
Zoe: You don't solve every case, you don't argue every case in court exactly the same. Instead you have a set of techniques that you apply to real world data in order to come up with your argument. There's a good parallel to be made there in software as well. To say we have a set of techniques that are fairly successful. We're going to apply those to real world problems in order to build software that delights our customers. When we run into problems that we don't yet have a technique to solve, we'll go out and we'll find a technique. That's my idea of an engineering practice, and the thing that I really want to start engaging with large organizations to help them build. Because that's something I take particular joy in.
Michelle: Are there any technical organizations that you enjoy being a part of?
Zoe: Yes. I work with an organization called Write/Speak/Code. We have the mission of helping elevate women and non binary people in technical thought leadership through the activities of public speaking, professional writing, and open source coding. We have chapters across the United States in New York, Chicago, Seattle, San Francisco, Los Angeles, as well as an annual conference in the summertime. I'd really love, if you're in one of those cities, and I might have forgotten one so definitely check our website, look for a local chapter and attend one of their events or more. As well, for the conference, this spring, we're going to be putting up our CFP, call for proposals, for talks for that conference. I would particularly love it if all of your listeners submitted a proposal for our conference so that we can get the best talks in. If any of them wanted to get involved with their local chapter, as well, that'd be fantastic. But just showing up and participating in the workshops or viewing our talks, is already something that I would really want to encourage people to do. It's delightful.
Michelle: If our listeners want to reach out to you via social media, how can they reach you?
Zoe: That's a terrible idea, you shouldn't do it. But if you wanted to, I do have a Twitter. It is @unusedpotential. I check that maybe once every two or three days, so I'll definitely see messages and get back to people.
Follow @FromSourcePod for more episodes and to continue the conversation about what tech jobs are really like, from the good, the bad, to the boring.
Apple Podcasts ~ Spotify ~ RSS ~ Web
Rate & review to support the show!
Top comments (0)