From Engineer to Executive: An Interview with Eric Muntz of MailChimp

Episode 8

If you’ve ever wondered about what it could look like to go from being an engineer to the senior executive level of your company, you won’t want to miss this episode. This week on the Programming Leadership podcast, Marcus interviews Eric Muntz, the Senior Vice President of Engineering at MailChimp. They discuss Eric’s career shifts as well as the challenges and lessons he’s learned along the way.

 

 

Show Notes

• One of the first lessons Eric learned in management was how to listen well. It’s about waiting to jump in before you speak and being intentional about when you do.
• When Eric began moving up in leadership, he asked himself, “What types of things do I need to do to go in and actually be perceived that way from people who don’t know me at all?” One step he made was going through the employees’ training and asking them how he could help them do their jobs better.
• If you’re looking for a promotion, know that managers are looking for who is helping and who understands the big picture.
• Address burnout. Talk about it. Especially with those who are prone to care ‘too much.’
• Eric shares that MailChimp’s company motto is, “Listen hard, change fast,” which gives you permission to be wrong — and fosters growth among all involved.

Links

• Book reference: Radical Candor
• Thanks to this episode’s sponsor, GitPrime!
• Email questions to marcus@marcusblankenship.com and we’ll answer them on-air!

Bonus: Eric’s XY graphic for executive level communication expectations

Transcript

Announcer: Welcome to the Programming Leadership podcast, where we help great coders become skilled leaders and build happy, high-performing software teams.

 

Marcus: Hi, I’m Marcus Blankenship and welcome to the Programming Leadership podcast. I am incredibly excited to have Eric Muntz as my guest today. What a guy. Eric is the Senior Vice President of Engineering at MailChimp, which is a product you should be using if you’re not, and just one of my new favorite people, we met recently. Eric, thank you for being on the show.

 

Eric: Thanks so much for having me. Excited to be here.

 

Marcus: Eric, this show is … The whole goal here is to help great engineers become managers and leaders and I’m guessing you may have started your career as an engineer, is that correct?

 

Eric: That’s correct.

 

Marcus: Tell us a little bit about that. What did you do? Was that at MailChimp or some other company?

 

Eric: It was at some other company. So I actually have a degree in Applied Mathematics from Auburn University in Auburn, Alabama with a concentration in computer science. And I actually got my start while I was in college. I couldn’t afford college and I ended up getting a job at a software company in Atlanta doing tech support, which then turned into a quality assurance job where I learned to write some scripts to test what I was testing. Engineers having seen that, then it turned into an Engineering 1 job, helping fix bugs and work on their software. And then when I graduated, they actually started a startup in the late ’90s .com era, and I chose between that and a position with Microsoft who I interviewed with on campus at Auburn. Being super introverted and scared of moving all the way across the country, I decided to stay in Atlanta and join the startup. And that’s what I did.

 

Eric: And so prior to MailChimp, I mainly did Java and C development. First startup was an embedded system for a home. It was in the MP3 era, so it was designed to take CDs and rip the music to MP3 and then give you a home entertainment device where you would play it back. So lots of embedded and Java work on that. And then I moved to Washington D.C. For a short period of time, worked for the government doing web development and then actually started a consulting business in Atlanta where my main client was the Federal Government in Washington D.C. It was a very small little consulting practice. I had one full-time employee in one part-time employee and we did staff augmentation. My niche became Blackberry development, if you can remember back to when Blackberry development would have been a thing.

 

Marcus: I do. I remember that breakout game.

 

Eric: Yeah, that’s a good one. The interesting thing about that is that I decided to stop focusing on consulting and to start trying to build products. And so I built a couple of Blackberry products and because I’m bad at marketing, I decided the best way to do it would be to build a product for a company that has an existing audience but needs a Blackberry app. And my second Blackberry app was called a MiniChimp and it was for MailChimp and I got an email from Ben Chestnut, CEO of MailChimp the day I launched it, asking if I wanted a job. I said, “Nope.” I said, “Nope. Consulting is great.” And we just exchanged emails and the next thing you know, I decided to meet with them and the rest is history.

 

Marcus: Wow. Okay. So did you join MailChimp as an engineer or did you come in with a manager hat on?

 

Eric: I joined as an engineer.

 

Marcus: And so then you have really made the career progression. Owning a consultancy, which I have done, is a lesson in management and leadership. Don’t get me wrong. And sales and failure and at least if you’re like me, lots of other painful things.

 

Eric: Yeah, for sure.

 

Marcus: Let me pause and thank today’s sponsor, GitPrime. GitPrime’s platform allows you unprecedented visibility into your development team. For too many years I’ve had to guess at the status of projects, without any real data to make decisions from. Oh, I have tried everything. Story points, velocity, burn down charts, burn up charts. You name it, I’ve tried it. Worse yet, I’ve made the mistake of promising my boss when something would be done only to be disappointed. When I dug into things with my team, I was always surprised between what the charts show and what’s actually happening. Now, it’s not like anyone’s messing up, but things are happening that I have no visibility of, which meant I couldn’t even discuss it with my team. GitPrime changed all that. With GitPrime, you can leverage git level analytics. That’s where the real work is happening. It provides deep insights to help you have better conversations with your engineers and your whole team. See things better, build things faster. Learn more and sign up for a demo at gitprime.com.

 

Marcus: So you started as an engineer at MailChimp and what was it like then? What was your first step into something where someone said, “Yeah, Eric’s my boss.” What was that title and what was it like for you to take that step?

 

Eric: Yeah, I wish I had a better story than this, but my title was probably still software engineer. We were pretty flat at the time. When I joined MailChimp in 2010, nine years and a couple of months ago, I was the 33rd employee and I was the third engineer working on our product. We had one other engineer who was in charge of email delivery and maybe one other who was doing sort of Cis admin work. So there were about three of us working on our product. When we started hiring a few more folks, there needed to be a manager and I just sort of went and did it.

 

Eric: And for the first little while it was just that someone reported to me from an HR point of view, and I hate saying this, but management was probably described best as what you do in the roughly 10% of the time that you’re not “working,” which is a horrible way to say it. And I throw air quotes around working, because of course management is work. It’s very, very hard work. But that’s just how it was at the time. We were a super, super small team and at that point we weren’t taking that side of the career path seriously.

 

Marcus: I think I’ve described it as like a programmer plus plus. You’ll still do all your normal stuff and everything’s got to ship on time, but oh yeah, you’re now quote unquote responsible, which, I found it means different things for different places. So you took the step into management, it was given to you, whatever it was. Were you managing the peers, the people that had previously been your peers and coworkers?

 

Eric: Only one of them. Yep. Yep.

 

Marcus: Only one of them. And I was just curious, when I went into management, it was not a move I was super excited about because I’d never had a really good experience with managers. Did you have any sort of feeling about the idea that your career was changing?

 

Eric: I did, actually. That was different for me this time because I was actually pretty excited about it and I had had a really good manager at one of my previous positions with the Federal Government. I was sort of the stereotypical grumpy engineer. I think if you asked people I worked with before MailChimp, like, “Tell me about Eric,” they’re like, “Ooh, good engineer, super grumpy.” I had this great manager who, one time we were on our way into a meeting and he just pulled me aside and said, “Hey, I want you to do me a favor. I want you to shut up. I want you to just go in and listen.” And I was like, “What?” Kind of taken aback. And he’s like, “Yeah, I want you just to listen for a little while. And until everyone has spoken and there’s dead air in the room, then I want you to start sharing your opinion.”

 

Eric: He said, “I just want you to try this out for me.” I’m like, “Okay, whatever.” I trust him. So I go in, I just listen. I’m sitting on my hands, biting my tongue. And then finally I realized that, okay, everyone has said what they said, there’s sort of dead air. And then I provide my opinion. The meeting goes actually really well to where at the end of it he pulls me aside and is like, “Okay, did you see what happened?” And I was like, “Well, no, but the meeting went really well.” And he was like, “Yeah, you listened before you jumped in with your super strong opinion. We got to a good place, but people felt heard and felt in on having made the decision because you didn’t do what you usually do, which is just jump all over the process and the people.” And I was like, “Wow. You just totally Miyagi’d me. Help me understand what’s going on here.”

 

Eric: And we spent a lot of time talking about management and people leadership and how to have influence without authority and a lot of those things, and it was really eye-opening for me and a huge turning point. And so I was excited to be able to try that out and try out helping other engineers see that and teach that when I first started managing this team, probably eight years ago.

 

Marcus: Do you remember, did you try that at subsequent meetings, where you would be that intentional about when you spoke?

 

Eric: Absolutely. Yeah.

 

Marcus: Did other people notice?

 

Eric: I don’t know that they noticed that that’s what I was doing, but they certainly noticed that I was listening and that I was really hearing them and taking their opinions in and not discarding them and making them part of the situation. With the previous group of folks I worked with, it took awhile because I already had a reputation. But being able to set a new reputation, it was super helpful.

 

Marcus: Yeah. I hear a lot of people sometimes who are quiet but they are not listening. They are just waiting to speak. And I feel like the way you described it was actually hearing what people were going to say rather than walking in knowing this is what I’m going to say. Or in the first 10 seconds having your opinion formed and then just waiting to drop the bomb. Is that true?

 

Eric: Yeah, definitely.

 

Marcus: You became a manager at some point. You got the big M title and it sounds to me like this really good boss of yours was actually a really important part of your journey. I mean, you’re telling us this story today. Do you use that story, I think you mentioned you did, do you use this story with other people or have you given your own reports this advice?

 

Eric: I do. I use that story all the time.

 

Marcus: Can you help us understand maybe how important it is that someone have a good manager, in your opinion. Maybe not only to model, but also to give that kind of feedback?

 

Eric: Yeah, I think from both perspectives you just listed, from both modeling behavior and being able to get feedback like that, it’s super useful. I think that people talk about the book Radical Candor a bunch and it’s maybe a little overplayed or maybe even somewhat misunderstood or whatever. But that’s really what he was doing in that instance. We had already had a relationship. I knew he cared about me and my career. I knew that he respected me. We got along super well. And so I was able to hear some pretty tough feedback, some tough criticism, and I was able to take it forward into the next part of my career, my next job.

 

Eric: And I was deliberate about it. I said, “Okay, before …” his name was Frank… “Before Frank helped me with that, my reputation was the really good grumpy engineer and I would like to have a different perception going into this job at MailChimp.” So I actually sat and talked to myself and was like, “What do I want to be perceived as? I want to be perceived as the helpful engineer. I like it when people are perceived as the helpful engineer. I would like to be perceived that way. What types of things do I need to do to go in and actually be perceived that way from people who don’t know me at all?”

 

Eric: So I went in and was like, okay, our support team was pretty big, 33 employees, support was probably 20, 25 of them, support was the majority of the company. I’m like, “Well, how can I be helpful to them? That’s a lot of people.” So I asked to go through their training. I consistently asked them what we could do to help them do their jobs better. The same thing with our finance department, which was maybe just one person at the time. And I ended up being the developer that flew around to other departments and helped make the entire company better. And I think it ended up paying off fairly well.

 

Marcus: Well it seems like it did. At least from this perspective. I was going to ask, so when you started at MailChimp, you decided a little bit introspectively that you wanted to be thought of not as the grumpy engineer, but as the helpful engineer, and you had a little talk with yourself, which I really like that, and then you did all this stuff that doesn’t at all sound like engineering. Like most engineers I know would not be excited to go through customer service training or talk to somebody in finance. But why do you think that being seen as a helpful engineer and being interested in other departments, what did that do for you? Why was that beneficial, I guess, is what I’m trying to ask.

 

Eric: Yeah. Well, it was beneficial to the business. It was beneficial to a MailChimp in a bunch of ways. Me personally and my career trajectory, I don’t have concrete evidence of this, I haven’t actually gone to folks and asked this question, but my assumption is that as we started growing the team and people looked around and thought, “Well, we need someone to lead this part of engineering,” what do you do? You sit back and you think, ‘Okay, what about these people? What about that person?” You think, “What have people said about Eric?” “Well, I’ve heard from support, he’s really helpful. I’ve heard from the financial team, he’s really helpful. I’ve heard from this that he’s really helpful.” It sounds like he’s pretty helpful. That sounds like a good thing. That sounds like that would be a good thing to have in a leader of engineering.

 

Eric: I have always, even though I fully acknowledge that I was pretty grumpy, I have always prided myself on being an engineer who can bridge from engineering to other departments, and being able to go and do that in a way that was helpful for the rest of the company. I wasn’t doing it intentionally as this is what I’m going to use to get ahead, but I do think it ended up helping me get ahead.

 

Marcus: Yeah. I think that’s really interesting because you just laid out possibly … For engineers who are listening and you’re wondering, “How do I get promoted?” You just heard how management thinks. They A, usually look around. Who do we have? And then B, who’s helpful? Who’s helping now is probably the primary attribute I’ve seen, and I really liked the way you laid it out. Sometimes engineers don’t really get that that’s why people get promoted. I think that sometimes they imagine it’s who has the best code. I don’t know, but you’re not talking about anything to do with writing really optimized SQL statements or stuff like that.

 

Eric: Oh, definitely not. By the time I was at MailChimp for six months, into October of 2010, I had caused quite a few outages in MailChimp. So it was not “Eric’s code is the best thing ever.” That was definitely not the reason.

 

Marcus: It’s amazing. And I do suspect you’re correct, that exposure to other parts of the business, this is usually an area that I think a lot of managers look for when they think about who to promote is who understands the big picture here?

 

Eric: For sure. Yeah.

 

Marcus: So you stepped into management, you start doing that work. At some point did it become more than just a 10%? It became, I don’t know, like a full-time job? And what was that like?

 

Eric: Yeah. At some point it definitely became a full-time job and that was probably somewhere around … Not that many employees, so that was probably somewhere around four or so reports. I still did a little bit of part-time coding work because the team was still small and I still probably knew the system as well or better than just about anybody else. So I still did a little bit of that until four or five years ago. And it was good. I had a few reports who were just extremely thoughtful people and really helped me become a better manager by helping me manage them better. And one of my first strategies I came up with was I acknowledged that when someone cares a lot, they also have a tendency to burn themselves out. And we did a really good job of hiring great engineers who cared a lot. They cared a lot about their output, they cared a lot about the business, they cared a lot about the team, but burnout felt like it was starting to become a problem.

 

Eric: And what I really wanted to do was find a way that we could address burnout, where “Take a vacation” isn’t the only answer, so that there is a way to sort of even out burnout at work. And then I started thinking about it and talking with the engineers who reported to me about it and they were like, “Yep, that’s definitely a problem. Help me figure this out.” You learn quickly that dealing with that is not a one size fits all problem. So there were two specific engineers who were reporting to me that we worked out a system where one of them was a … sort of, you look up product engineer in the dictionary and there he is staring at you. Which means that, very cross-functional, works with design, does a lot of design, works with support.

 

Eric: But that requires you to be on a lot. That requires a lot of extroverted behavior, and that takes a toll. So what we would do is every couple of months we’d say, “Okay, here’s a Greenfield research project and not a fake thing, a thing that’s really important to MailChimp to understand, and it’s the proverbial put headphones on and tunnel vision and get some stress relief from having to deal with the ins and outs of working with people all the time. And on the flip side of that, there was a woman who, and this one I really resonate with because this is the same way that I think, that you start to get a little bit caught up in all of the architectural decisions you have make as an engineer. So you make one choice and it takes you down one path and then you make another choice and it forks into another path. And the next thing you know, you start second guessing like, “Did I take a wrong turn at Albuquerque? Should I go back and think differently about that?” And it can paralyze you pretty quickly.

 

Eric: So what we did was say every now and then there needs to be a week where you’re doing sort of “mow the lawn” tasks and just go triage bugs and fix bugs and let all of those big worries sort of move to the background and work themselves out. So that’s kind of the first thing that I really started trying to take on in management, and I think it worked out pretty well.

 

Marcus: Wow. I don’t think I’ve ever heard it put so succinctly, this idea of people who really care are more likely to burn out. I think you’re exactly right. If there are people listening and they’re a little worried … Oftentimes they’re best performers, I think, are the ones that care the most, but they’re concerned about that, how can we open up a conversation where we can talk about this and just suggest these things? Because the word burnout isn’t always comfortable to talk about.

 

Eric: Yeah. It’s definitely not always comfortable to talk about. And as with most things in management, the feedback loop is impossibly slow. So as an engineer you get that feedback loop so quickly and it’s just such a great rush and such a great feeling, when you make the transition into management, the feedback loop either doesn’t exist because you’re a scary manager and no one wants to talk to you or it’s so slow that by the time you know if something’s worked, it’s way too late. And so oftentimes by the time you know someone’s burnt out, they’re burnt out, and it’s really hard to reverse.

 

Eric: First and foremost, talk. I think just bring it up and saying you’re the type of person who cares a lot and because of that you’re going to have a more of a tendency to burn yourself out. And let’s talk about what that looks like and how we can start to recognize warning signs together. You recognize it, I recognize it, we both talk about it. And we can talk about it in a way that’s not like you’ve done something wrong. You starting to feel burnt out is not failure on your part. That’s for us to continue working out. And then try to figure out when you are not stressed at work. When you feel relief from having done some work, what does that work look like and what does that feel like and how would I recognize that work and figure out how to say, “Okay, we need to make sure that you’re doing some of that work, and I need to make time for it and protect your time for it. That’s my job as a manager.”

 

Eric: And then we start to do that and you can sort of measure it and talk about it after X period of time, a couple of weeks, months, whatever it is, do you feel like sort of the burnout chart is feeling a little better?

 

Marcus: I think that’s great. Do you find it’s a conversation you at least open with every employee? Or do you look for those that you feel are exhibiting either signs of early burnout or maybe signs of extreme caring?

 

Eric: I personally do it with everyone who reports to me, so it’s part of my like, “Hello, you report to me now. Let’s get to know each other.” It’s part of that conversation and then I try to revisit it often.

 

Marcus: Okay. You don’t have to answer this, so just say no if you don’t want to. Do you feel like you’ve ever experienced burnout?

 

Eric: Oh yeah. Oh yeah. Yeah. I experienced it at MailChimp in 2011 or ’12, I can’t remember which year it was. It was probably 2011, because by 2012 I think our on-call rotation was bigger. But in 2012 there were essentially three of us on call. So you were a primary then a secondary then off. Primary, secondary, off. And it was that way, every three days cycle. And there was just a period where there was 100% guarantee, I started sleeping on the couch because I didn’t want to wake my wife up. We had a young child and my wife’s joke was like, “You’re up growing MailChimp more than I’m up growing our child.”

 

Marcus: That’s kind of unfunny.

 

Eric: Yeah, it’s like, “Ouch.” So we would wake up and triage and then we’d do our best in the day to add enough protection and scaffolding to make sure that things wouldn’t crumble. But it just was a rough period. We were experiencing a lot of growth and we wanted to get ahead of things so we’d get alerted just before a catastrophe and we’d go and get things back to shape. So it was a rough period. There was probably a two week period where I just was not getting great sleep. I was anticipating an alarm going off. There’s stories of the baby crying and me saying, “Check the logs!” That type of story. And I came into work one day and was just like, “I’m done. I’m super burnt out. I can’t take it.” And our COO at the time was like, “Go home and sleep and when you come back we’ll review the alerts and figure out what to do and if that means no feature work for X amount of time, we’ll figure it out.”

 

Eric: And it actually turned out we had done it to ourselves. We were alerting ourselves about things that could have been fixed during the day. It wasn’t like the email sends weren’t going out or the site was inaccessible. It was like, eh, this thing is somewhat bad and if it continues to get bad it will turn really, really bad. And it was like, “We can turn those off for a little while.”

 

Marcus: You cared too much.

 

Eric: Yeah. That’s actually a great way of saying it. We were caring too much. So yeah, I got super burnt out during that time and was able to recover from it by having great folks around me who helped to talk it through and helped find some work for me that was like, “Hey, do some product work. Let’s not triage servers for a little while.”

 

Marcus: And some solid sleep.

 

Eric: Yep, solid sleep. Sleep was great.

 

Marcus: And to rewind back to something you said that that feedback loop, especially the new manager, but management feedback loop is long and slow. And in this case it sounds like your manager wasn’t aware of how difficult that situation was until you, I don’t want to say got fed up, but you walked in and said, “I’m done.” And I don’t quite know what that means. That’s okay. But it sounds like we’re not going down this path anymore. And maybe they were a little blindsided, whatever, but that feedback loop, that’s oftentimes how managers find out about things, isn’t it?

 

Eric: Yeah, it totally is.

 

Marcus: Do you have any suggestions on how we might build feedback loops with the people on our team so that sooner we can get data or maybe we can find out before things are at crisis point? Or maybe we can even find out how we can do our jobs better.

 

Eric: Yeah. So I have thought a lot about this actually. And I think with individuals, it’s all about having frequent one-on-ones and knowing the person enough to know what the right questions are and talking openly about what their stress behaviors are and what their stress signals are and just being super open about about that with the individuals. That makes it sound easy. It’s definitely not easy. It takes a lot of time and practice and lots of creating room for one-on-ones and all of that. Now with a group, what I have been really leaning heavily on is this notion of trusted advisors, and my reasoning there is I now run a team of a couple hundred. And if we as a management team are going to make a change, it’s really hard to predict how that change is going to land, but if we have folks who we have good relationships with that are in those jobs and are tight with those people and connected with those people in a way where … Like for example, we have a role called Principal Engineer and it’s the highest level in the IC track, the individual contributor track for us, and so they are leadership but they are not managers, meaning they don’t have direct reports. And it gives them a very unique ability as leaders in our organization because people can go to them with problems and help get problems solved and not have the fear of it affecting their careers because they don’t report to them.

 

Marcus: That’s beautiful.

 

Eric: So those same people, I can say, “I’m thinking about making this change, how’s it going to go?” And it’s almost like canary in a coal mine behavior, where they can say, “That is not going to go well. And because they’re high level, they’ve been around a bit, they are willing to provide a tighter feedback loop to someone with SVP and their title. And so that sort of trusted advisor group is super helpful for getting a feedback loop that’s faster than it would be otherwise if I didn’t have that and I said, “Okay, I’m going to make this change,” and crossing fingers, “I think it’s going to go well. I hope it’s going to work.” And then I communicate it through an all-hands, through a bunch of emails, and through all of the change processes that you go through, by the time those are done and you’re weeks in, if half the team is upset about it, I’m going to hear about it all at once that 50% of the team is unhappy or more. But instead, if I can hear it from one, or three or four, however many of these folks in these roles, it can really help adjust and tweak beforehand.

 

Marcus: I love that idea. Not only because it does give the individual contributors another place to bounce ideas off of and get advice, but because the canary in the coal mine. And I know that when I was a programmer, the feedback loop was me and the compiler. It gave me pretty fast feedback. But like you’re saying, in many ways you’re like tossing a … okay, this sounds like a war metaphor, you’re like tossing a grenade out there. You’re tossing something out there and the impact of it is really hard to gauge. And after whatever has been announced weeks later, oftentimes it feels like it’s too late to do anything about it. Or what I found at a big company, maybe this doesn’t happen anymore, but when senior management puts out an idea and it doesn’t go well, they are not always very willing to admit that it didn’t go well because the title pressure and other things cause them to feel like it’d be better just to not talk about it than to make a retraction or an adjustment. Have you ever felt that sort of pressure?

 

Eric: That one of the huge blessing of working at MailChimp. Our company motto is “Listen hard, change fast,” which gives you permission to be wrong. And just that simple statement really does give everyone permission to say, “Hey, we listen hard and you’re right. We’re going to make a change here. We’re going to do this slightly differently.” So, I don’t want to make that sound like “Oh, then cool, I’m cavalier about change. No problem. Change is cake. Let’s just change things all the time.” We’re still very careful about it and we think about it heavily, but because of that, I am not at all afraid to stand up in front of the entire team or the entire company and say, “This was a mistake. We’re going to rethink it. For now, just let’s roll it back,” whatever it was, “Let’s go do this other thing.”

 

Marcus: You’re not going to get fired or people aren’t going to like …? I know you’re shaking your head, we can see each other on video during this podcast. But I think you know, because you kind of mentioned it, it’s a very special place to work. And it’s not an accident that that kind of place gets created. And I don’t think it’s just because you’ve got a great slogan. Right?

 

Eric: Right, for sure. It’s not that. And there’s a great history behind it too. You know, you said, “You’re not going to get fired.” Actually, right after we finish with this, I have a meeting that’s a monthly VP chat, where myself and the other VP of Engineering here do a chat with every new hire group as they come through engineering and we talk about our origin stories and some sort of timeline history of what’s happened at MailChimp specific to engineering, and where we’re headed and we open it up for questions. Well, there’s definitely a part in there where he and I, his name’s Joe, so Joe and I talked about failures we’ve had and times that we’ve broken MailChimp or times that MailChimp has broken for other reasons and we’ve fixed it. And it’s just an important note that like our CEO has said, “You look back and there’s no dead bodies.” Everyone came forward and it was totally fine. We acknowledged it. It is a place that embraces failure in a way that I’ve not seen before.

 

Marcus: That’s pretty awesome. I know one of the things, I worked at a big company that I would say did not embrace failure in the same way, but I was able to create a local team atmosphere where at least between me and my direct reports, I started opening up about my screw ups. When I brought the server down, that time I just deleted the database and the entire window manufacturing plant had to go home for the week. Just talking about those things somehow … And laughing. Like again, no dead bodies. Just talking about my own failures seemed to make it safe for other people to admit that they were human and maybe even to point out and give me feedback when they saw something that I couldn’t see.

 

Eric: Yeah, that’s a great point. Humanizing yourself and your mistakes also probably does make it more likely that people will be open with you and reduce that feedback loop.

 

Marcus: Yeah. I’ve never been an SVP, but I was curious, did you find that you get less feedback and less information the higher you go in an organization, generally?

 

Eric: Yes, I have found that. And I’ve never been an SVP either, until this job. So that’s new. And yeah, I have definitely found that, especially when you’re in a growth curve like we’re in. So I think 60% of MailChimp employees, maybe just engineers, have only been at MailChimp for two years. So there’s people here who don’t know me as an engineer who broke MailChimp or as anything other than a VP or now SVP. And I’ve been there, I’ve worked at a company with thousands of employees and gone to the holiday party and shaken hands with someone and they said, “Oh, I’m Senior Vice President of” whatever, and I was like, “Ugh, they’re scary,” because of their title. So I get it. I totally do get it. And I think that’s why having these trusted advisors who don’t see you that way and are willing to talk to you a little more is super helpful.

 

Marcus: I feel like that model of trusted advisors is actually something that anybody could cultivate by choosing those folks who they have more trusted special relationships with, or maybe it’s individuals, maybe it’s by role. Like you said, you’ve got principal engineers and maybe part of the expectation of that role is to give you that kind of feedback. And so that’s maybe even part of the criteria for putting people in that role because it’s a very important function.

 

Eric: Yeah. Yeah, that’s a great point.

 

Marcus: Well, we’ve got just a couple minutes left. Give us the nickel tour of your rise from manager to executive, which is very fancy.

 

Eric: Very fancy. You’re wearing glasses, you should have put your monocle on for that one.

 

Marcus: Oh, I should have. Yeah.

 

Eric: Yeah, so I was first promoted to VP, actually VP of Product, which at the time for MailChimp just meant engineering and design together. We didn’t have a single product manager, we didn’t have a single project manager. So at that time product just meant the engineering and design teams that make MailChimp go. So at that point my role really became more about leadership and connecting business strategy to execution from our teams, than it was so much about managing people and individuals and driving that forward from that angle. I still do manage people in the sense that people report to me and I take that very seriously, but my main role now is to help form MailChimp’s business strategy and then deliver it down to the rest of the teams, and pull up from the teams where execution is either struggling or needing some help because of lack of clarity around strategic decisions or whatever else that is.

 

Eric: I know this is a verbal podcast, but I have this little drawing that I do that’s in X and Y Axis, that on the left side of the X-Axis is Execution and on the right side is Strategy and on the bottom of the Y-Axis is Single Function and the top of the Y-Axis is Cross-Functional. And then you basically draw some circles that go from bottom left to top right and it shows you the responsibilities and expectations of people in each role as you climb from line level manager up to C-suite executive. And it helps me to clarify with people two things. One, what people want from you is the opposite direction that they are on that spectrum. So if you’re an SVP, people want to hear about strategy and they want to hear about cross-functional work. If you’re a line level manager, they want to hear about your function and they want to hear about execution.

 

Eric: And because of that, the other thing that really gets us out of that is that the easiest jobs are the ones on the far ends, when it comes to communication, because you’re not context switching. So as an SVP, I don’t have to context switch that much. When I meet with the C-suite, they want to hear a little bit more about execution than they do strategy or about my function than they do about cross-functional. Just a little bit more. But for the most part when people want to hear from me, they want to hear about strategic initiatives and they want to hear how cross-functional work is going. And the sort of toughest job is that person right there in the middle, which is like director level, senior manager, that level, because they might go to a meeting with a C-suite who wants to hear about single function and execution and they might immediately leave that meeting and go to a meeting with line level managers or a bunch of individual contributors who want to hear about strategic work and cross-functional work. So that’s been sort of the eye opening thing for me in my switch from manager to director to VP to SVP, is knowing what people are expecting to be communicated outward from me.

 

Marcus: That is huge. And if you have a drawing or a picture, send it to me. I’ll put it on the show notes when we drop it on the website. I know I’m envisioning it, but I’d love to see what you’ve got. I think you nailed it. Being in that center, the cross hairs, it almost seems like, is exactly where you might be giving opinions on how to name functions one minute and on a something incredibly strategic the next minute. It’s very easy to get knocked off your feet, I’ve found. And most of the time I was sort of struggling in that. Well, we’re rounding out the show here. I’d love to hear, is there one particular thing that you hope to learn in 2019?

 

Eric: Personally, this is probably the third year in a row that I’ve said I want to learn to sew, and I have just been unable to make it happen. And it turns out someone pointed out to me, there is a place in the building that MailChimp’s office is in that has sewing lessons. Yeah. Yeah, totally. So I think I’m going to go try to figure out how to get some sewing lessons.

 

Marcus: I think that is awesome. I have it on my list to learn to ride a unicycle. And I am not good at this. I have tried now for about four years to try and quit falling and I keep setting it aside. But thank you, Eric, for being on the show. It was such a pleasure and I just really enjoyed hearing about your journey. I don’t know, now I’m stammering around because there you’re an SVP and I don’t know what to say.

 

Eric: Give me a feedback loop.

 

Marcus: That’s right. Well, thank you so much. This was really valuable, the ideas were useful, and I appreciate you sharing your trip from individual contributor to SVP and all the fun and pain along the way.

 

Eric: Yeah, you’re welcome. Thanks so much for having me. It was really fun.

 

Marcus: Absolutely. Thank you.

 

Announcer: Thank you for listening to Programming Leadership. You can keep up with the latest on the podcast at www.programmingleadership.com and on iTunes, Spotify, Google Play, or wherever fine podcasts are distributed. Thanks again for listening and we’ll see you next time.

 

Announcer: This has been a HumblePod Production. Stay humble.