BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Podcasts Mailchimp’s Culture of Production-ready, Momentum, Togetherness, and Pragmatism

Mailchimp’s Culture of Production-ready, Momentum, Togetherness, and Pragmatism

Bookmarks

In this podcast, Shane Hastie spoke to  Eric Muntz of Mailchimp about how they attain production-ready, momentum, togetherness, and pragmatism.  The value of internal apprenticeship systems, growing teams deliberately and removing friction in the developer experience.

Key Takeaways

  • Production ready does not mean waiting for perfection.  Perfection is the enemy of momentum and serving customers.
  • Togetherness means involving everyone and collaborating rather than encouraging individual heroism
  • Momentum needs to be sustainable over the long term
  • Pragmatism requires careful balance to maintain quality while responding rapidly
  • An internal apprenticeship program allows people to cross-skill and brings people with different backgrounds and experience into the development team

Transcript

Introductions [00:21]

Shane Hastie: Good day, folks. This is Shane Hastie for the InfoQ Engineering Culture Podcast. Today, I have the privilege of sitting down with Eric Muntz. Eric is the CTO of Mailchimp and joins us from... Well, good question, Eric, where are you?

Eric Muntz: I'm in Atlanta, Georgia in the US, and I will apologize in advance. Those who know anything about Atlanta know that on April 1st, this is not a joke, it is pollen season in Atlanta. You may hear me clear my throat a little bit here as I am dealing with all of the allergies that come with living in the Southeast United States in spring. Thanks so much for having me.

Shane Hastie: Thank you. A good starting point, who's Eric?

Eric Muntz: Eric is the CTO at Mailchimp, which is a Vice President at Intuit as Mailchimp was acquired this past year. I live in Atlanta, Georgia. I am originally from Honolulu, Hawaii. I call myself a Hawaiilantan, very proud of that. I am a father of a 14-year-old and 11-year-old, a very happy husband of a woman named Katie, raising a family here in Atlanta. Love technology, love driving technology with a business and really focusing on business culture and how technologists participate in that culture and provide a great ecosystem for everyone in the business to succeed with technology backing it.

Shane Hastie: Let's just jump straight in. Tell us about the engineering culture that you've deliberately designed at Mailchimp.

Mailchimp’s mission around production-ready, momentum, togetherness, and pragmatism [01:49]

Eric Muntz: At Mailchimp, we have about 450 engineers, and that includes back-end, front-end, infrastructure. We are actually co-located today and working on a cloud migration. We even have folks who go to data centers and deal with hardware, which is awesome. They call themselves the metal engineering team. For those who can't see, I just did the rock on hand signal. We also have corporate IT in the group. What we really center on is we have built a mission statement that really speaks for how the team works together. The mission statement is two simple sentences and it's we give marketers production-ready software designed to help them grow. We succeed through togetherness, momentum, and pragmatism. And so, if you really think about that, there's four words there that you can sort of pluck out and picture tension across all of them, production-ready, momentum, togetherness, and pragmatism.

We really believe that adhering to those and making sure that we are living those every day helps us build great software, helps us power the business the way that business needs to be powered with, engineering has wind in its sails instead of headwinds, and making sure that our customers can succeed, which is the important part. This is why we're all here. It is a huge part of Mailchimp's DNA and what we really care about is empowering our customers and making sure that they're successful. And so, we've been very intentional about making sure that everything we do in engineering is in service of that and in service of partnering with the rest of the business.

Shane Hastie: Let's delve into those four statements. Production-ready, well, surely. That's what we do, isn't it?

Production ready means being observable and observed [03:23]

Eric Muntz: Right. It's interesting because I've had conversations where people have asked why is the word production-ready in there? Is that sort of pointing to a time where you weren't production-ready? The answer is yeah, maybe a little bit. When we started, it was a thing we really needed to intentionally call out, but what production-ready can easily be mistaken for bug-free or perfect. That is not at all what we're looking for. Perfection is certainly the enemy of momentum and serving customers.

For us, what production-ready really means is that what you're building is both observable and observed. It means that when you build something and you put it out there, you know whether it's working, how it's working and if it's not working, you get alerted to it and you can go and deal with it. If it's not working and it alerts, that is not the proverbial sound not heard in the forest but is actually something that is heard and people know how to go and deal with it and make sure that customers are supported. It's really about those two things. Is it observable and is someone actually going to be observing what happens with it?

Shane Hastie: Togetherness.

Togetherness over heroism  [04:28]

Eric Muntz: Togetherness, in far too many engineering cultures, heroism is a little bit too celebrated, where there's the one 10X engineer who can do everything and everyone is sort of in chorus around that person. With togetherness, what we're really talking about is coming together as a team, helping each other understand what the customer problems are, helping each other understand what the solutions are, getting all of the input that's necessary to get the work done, and then driving forward from there.

Togetherness actually extends past the engineering teams. It's along with our partners in customer service, our partners in design and everywhere else in the business and making sure that we are doing things together and it really goes toward that production-ready piece. When you launch something, make sure everybody knows you're launching it. Do it together. Of course, there's the proverb about if you want to go fast, go alone, you want to go far, go together. That's really a big component to what we're talking about here.

Shane Hastie: Momentum.

Momentum must be sustainable [05:25]

Eric Muntz: Momentum actually can be sort of perceived difficultly or maybe even negatively with engineering teams. It sounds like what you're saying is go, go, go, go, go, go, go, go, go, death march, run. I have a great product partner who has said there's a difference between work you plan and work you do. Sometimes, there's work that you just have to do and you just have to get really going on, and nothing creates progress in learning and iteration better than momentum and just getting started. It's sort of like an object that's in motion tends to stay in motion.

As engineers, sometimes we can reach the word perfection and let's not do that, let's actually get momentum and learn and take that momentum forward. The other big thing here is we're serving small businesses and growing businesses and their world is all about change. If our customer's world is about change, then our world has to be about change. Momentum is really a way for us to make sure that we're not sort of resting on our laurels and stopping and slowing down and really meeting the demands and the needs of small business.

Shane Hastie: And pragmatism.

Pragmatism requires careful balance [06:25]

Eric Muntz: Pragmatism is maybe my favorite. I shouldn't have a favorite. It's like your children, but pragmatism is really all about, again, not going overly perfect on your solutions. It is about finding the right way to meet customer needs without setting yourself up for harm in the future, but making sure that you're not going too far into perfection and becoming the enemy of good enough, or done, or really finding a way to get things in front of customers. It can be dangerous if pragmatism gets turned into just always cut corners. Pragmatism is about finding that middle ground where you're not always cutting corners and just throwing duct tape on things, but you're also not paralyzing yourself with perfect architecture.

Shane Hastie: One of the things you mentioned when we were chatting before the recording was being super intentional about building and growing the team. How's that playing out?

Being intentional when growing the team [07:18]

Eric Muntz: It's going really great. We have just a phenomenal team. One of the things that is really important for me and for us and leadership at Mailchimp is that we are sort of the team for anybody. What I mean by that is that we don't really focus on, you have to have X years of experience and you have to have a degree of this type and that type, or even a degree at all, but also that having a degree is also totally fine and great and making sure that what we're looking for is people who are curious, people who will be able to follow those four tenets of our mission statement and really care about small business.

Internal apprenticeships for cross-skilling [07:55]

Eric Muntz: One of the things that we started several years ago is an apprenticeship program and the program has evolved throughout the years. When it started, of course, it started small and it started with just one engineer trying it out, actually one person in customer service trying it out. But the way the program works is folks f rom Mailchimp can apply to apprenticeship positions in other areas of the business. It started out with technology and it has extended to, I think, basically any function in the business.

They essentially interview as if they're a fresh graduate out of college or a fresh graduate from a bootcamp or coming into an entry level position. Then they're given that position for roughly three months. Then at the end of it, it's sort of a try to buy. Both sides say, "Is this working? Do I really want to be an engineer now?" Then they come into the role and it has been incredibly successful because really, we've gotten a lot of people from our customer service organization. One of the things that I think can be hard to teach is empathy and compassion and understanding for what customers are going through and what small businesses are going through. Maybe it's easier to teach people how to break code than how to have that.

And so, what it does is it creates this really nicely-blended team, where you've got people from traditional backgrounds and non-traditional backgrounds and they're in it to help each other, and today we have about 450 people in engineering and roughly 70 on that team who started at Mailchimp, not on the engineering team, which feels like a really, really solid number.

Focusing not just on size but considering the shape of the organization deliberately [09:25]

Eric Muntz: Another thing we have focused on aside from that is focusing on what we call the size of the org or the shape of the org. What we mean by that is if you look at the numbers and you map early in career, midway experienced in career, or then extremely experienced in career, we want that to sort of look like a bell curve. When you think about it, you divide it into thirds and you say, the small side of the curve should be on early in their career and super advanced in their career, and the bigger part of the curve is that middle part where they're advanced in their career.

A hugely grossly overgeneralized way of stating what those three cohorts do is that the earlier ones are learning, the advanced folks are doing, and the super-advanced folks are teaching. Now, all three cohorts should be doing all three of those things all the time. Everyone is always teaching and learning and doing, but the majority of the job is learning, doing, and teaching. And so, we very carefully look at the size of the org and what we call the shape of the org, because it should look like that curve and that helps us figure out where we need to be hiring actively.

If we've got a little bit more on the advanced side and less than the other two, then we will not hire so much on the super advanced side and hire into the other two or vice versa. And so, that's been really helpful for us to make sure that the team is well-balanced across all of those things and across to where they are in their careers and everyone's getting what they need from the rest of the organization.

Shane Hastie: How are you tackling diversity?

Being intentional about creating  an environment where people from diverse backgrounds can be super successful [10:51]

Eric Muntz: We are tackling diversity by again being super intentional. I think a mistake that leaders make when they're talking about diversity is saying I want to hire a certain number of people from diverse backgrounds. I understand the approach there and the intent there, but what we have discovered is it's better to have a secondary goal on certain numbers and the primary goal being, I want to create an environment where people from diverse backgrounds can be super successful. Then, if you think about that, then the numbers end up coming or it's possible that the numbers can come, because if you just focus on, I want to hire 50% from certain diverse backgrounds, you may hire them and then they can't be successful, so they're going to just leave on the back-end.

Retention and success really is the key and really is the goal. If you really want to have a diverse environment, well, retaining them and making an environment where they can do the best work of their careers is the real goal. It's not just having some sort of number on my hiring headcount or numbers that I can go out and show. It's about being able to show that those folks are able to be successful and that you're intentional around all of that. We do have those numbers where we're looking at what pipelines look like and all of that, and we're focused on all levels. Within that shape of the org, I think people also make a mistake of like, let's bring in entry level folks to fix diversity problems and no, it needs to be all across the board and we need to make sure that we're hearing from those folks about how they're successful.

The other thing that we have done is started a program that we call TAG and it's the technical advisory group. What we do with that group is we're super intentional about the diversity of that group. Then, engineering leadership decisions are run through that group as an advisory board. We hear from that group on decisions that we're either going to make, or we just did make and how to refine them and whether those future decisions that we're looking to make are going to be well-received and make it so that diverse groups from all various backgrounds really do feel like they're able to do the best work of their careers. That's been very helpful.

Shane Hastie: You mentioned working collaboratively across the whole organization. How does that work for you?

Collaborating across the whole organisation [13:03]

Eric Muntz: That's my job, so that's what I'm doing all day every day. I have really great partners across the entire organization. And so, I look at my job as making the business successful and making every single other organization and department successful with the technology behind it. I have a fantastic partner in leading products and he and I really work extremely closely together. We co-signed messages together and we've actually combined our staff meetings and we've had just a really great rapport and approach to building things really together.

Then, I really partner tightly with marketing leader, and our customer service leader, and of course we've got so many alumni of other functions in engineering. That's super helpful as well. A few, even from engineering and other functions also, and it's great because we've got such just phenomenal leaders at Mailchimp that the more I engage with leaders in other departments, the more I'm learning constantly.

Our customer service leader is just a fantastic leader. My biggest learning of the last maybe year or two was a way to think about the way we talk about problems and not assume they're all customer problems and really think very pointedly about it and say, "Is this a Mailchimp problem or a customer problem?" She really jumped out a few times and was like, "You are stating a Mailchimp problem. We need to reframe that as a customer problem." And so, that has been just extraordinarily helpful. Highly encourage all engineering leaders or budding engineering leaders out there to make sure you have really, really solid relationships across the business.

Shane Hastie: Moving on from that to budding engineering leaders, how do you grow leaders within Mailchimp?

Growing leaders [14:41]

Eric Muntz: We've been growing so much since I started here. I started here 12 and a half years ago. I was the 33rd employee and we're at, I don't know, 1,300 or so today. And so, we've seen so much growth. I think we get a lot of great support from our people team and we have managerial programs and we do a lot of help to make sure that if people are in leadership roles or in desired leadership roles, that they get solid mentorship and solid help along the way.

The other big note is for us, leadership and management of people are two different things and leadership is in every one task, but we're also really careful about having individual contributor roles that are treated as leadership specifically within engineering, but also within other functions, and making sure that people understand what it means to be truly part of leadership and what leading people through change and leading people through tough times and celebrating the wins of your colleagues and that togetherness piece is super important. We've got lots of programs around that and we're just super intentional about the difference between leadership and management. Then, from a management standpoint, we get a ton of support from the rest of the org.

Shane Hastie: As you mentioned, you've been there a pretty long time. Your career has grown, you've said to me from software engineer up to CTO. What advice for people who want to follow those sort of footsteps?

Career advice [16:03]

Eric Muntz: That's a great question. It depends on the org that everyone is in. For me, what's been super successful is asking myself how can I be helpful? When I came into this company, I took it as an opportunity to say, "What's my brand been in my career? What do I want my brand to be going forward?" I know that thinking about yourself as a brand is kind of icky, but I thought about that. I said, some past career, I was the grumpy engineer, the grumpy engineer who didn't really listen a lot. I had a phenomenal manager teach me the power of listening. And so, when I came into this role, I said, well, I want to be known as the helpful engineer and the helpful leader.

And so, when I came in, I really took the time to tour every department and find out what their needs were. Our finance department had the biggest needs at the time, so I did a lot of work to help them initially. Then, having that humble moment where you hire the engineers that are just way better than you. Within the first year I was here, hired a couple of engineers and just realized if I can figure out how to help them and maybe remove obstacles for them, it's going to be way better for the business than me just trying to do a bunch of work because they're just way, way, way better at this than I am. And so, maybe I'll try to learn how to do the more business-y parts were, understand what customers need, and understanding what the rest of the functions need, and figure out how to help these people not have obstacles in their way.

That was really helpful. That was really a thing that, in hindsight, got me to the position that I am. I think just making sure that you take time to stop and pause and reflect on where you are, where the organization needs to go, ask stakeholders those questions, what do you need from engineering, what do you need from technology, what are we not doing today, and then building a plan to make that happen. That's really helped me along the way. I'm super fortunate that the founders created an environment where someone like me was able to be successful and fail a few times and still get himself up and get better and really build this team. I think it takes partnership on both ends.

Shane Hastie: One of the phrases you used when we were chatting was this distance to magic. Tell me about it.

The distance to magic as a measure of technology greatness [18:12]

Eric Muntz: What I mean by that, there's a saying somewhere, it may have been from The Mythical Man-Month or at least quoted in that book that any great technology is indistinguishable from magic. I just think that's such a really, really cool quote. And so, as I think about that, I think about if you expand that a little bit, I think just about any technology, if you take it back in time, some amount of time it'll feel magical. Today, our cell phones are not indistinguishable for magic, but if you went 25, 20 years back and you showed someone today's iPhone, it would feel magical.

And so, the way that I extrapolate that as I say, the best products that we build have a short distance to magic. The amount of time you have to go back for someone to go, "Whoa, that's magical," really is sort of a litmus for how great the piece of technology is. The thing that I think is really empowering and sort of great for folks to think about there is it doesn't actually have to be super complex and amazing technology. An example is Google Translate. If you bring up Translate on your phone and you hold it up to something and it translates that image in real-time, it's just like unbelievably magical. But I think most engineers look at that and go, "Well, that's a pretty high bar, Eric."

Making something that's as magical as holding my phone up that translates is a pretty high bar, but I think we have to remember that there's also magic in the way a piece of software can just make you feel. If your software takes a task on for you or recognizes that you're struggling with a certain task and just says, "Hey, I see you're struggling with this. Can I help?" Or even just throws up an empathetic emoji at a time you need it.

One of Mailchimp's biggest magic moments was when customers hit the send button, you get this little animation of our mascot with his fingers sweating, bouncing up and over the send button and is asking, "Are you sure?" Just that little image showing people that we understand the sweaty moment of pressing send to thousands, hundreds of thousands, maybe even millions of subscribers, and there's not a huge technical bar to meet that requirement, but it's magic and it feels magical the first time you see it, the second time you see it, way on down the road.

One of my other super favorite examples here is we have an engineer named Mardav who noticed that one of our icons for scheduled campaigns is a clock. He was like, "Well, they're all static clocks that are just sitting at 12:00. What if we actually made all of those icons actually be the time the campaign is scheduled to send?" He went and did that work and figured out how to do it, and it's one of those things that when users saw it - the Tweets, just the joy that that provided, it was super magical. I think he was able to get it done in a very short amount of time, a week or a sprint. That's the kind of thing that has such a short distance to magic and that distance stays small. If you're delighting a user, they're delighted every time they interact with it, so it stays small as it goes along. Those are really just some of the greatest things.

Shane Hastie: Another phrase you used that intrigued me was the transitive property of people.

Exploring the transitive property of people [21:19]

Eric Muntz: This one, I think, is really interesting. I've been trying to figure out how to write something about this and a former colleague who's a great engineering leader herself and I have talked about this a few times where there are these phenomena that incur. I actually talked to my daughter about this. She's 14 years old and she goes to school and she's talking about her friends. I realize that what she was talking about is the same thing. It happens in an organization a lot, especially in leadership circles or especially when people sort of change reporting relationships where Malik and Susie really work together super well, and they bounce ideas off each other and they never really feel like they're stealing each other's ideas and they just have that great relationship where they're working together super well and making huge impact and just things are going great.

Then, Susie goes and works with Chris and they have the exact same experience. Then, Malik and Chris get together and it is oil and water. And so, it's sort of like A is the B, B is the C, A is not the C. It is the non-transitive property that happens there and it's something that I think people just sort of instinctively think is going to be true, like the transitive property of people is going to be true. I think as a leader, it's important to be really thoughtful and careful about that, especially as you start working on reporting relationships and you start moving people around a little bit and well, this person was great with that person, but now they're reporting here and they're really unhappy or things are just not working so well.

I think keeping an eye on that and understanding that people are complex, super complex. They're more complex than numbers, which totally meet the transitive property in a ton of ways, and just making sure that you're really thinking about that, being intentional about it and asking questions around it. I think that doing that will drive a team to be super successful together and reduce barriers, and just sort of make sure that maybe your distance to magic is small for employees. Maybe that's a way I could sort of tie those things together.

Shane Hastie: In that distance to magic for employees, one of the topics we've been looking at a lot in InfoQ lately is developer experience. How do you remove the friction for your developer experience?

Eric Muntz: Internally or externally or both?

Shane Hastie: Let's look at both.

Removing the friction in the developer experience- deploying over 100 times per day and testing in production [23:28]

Eric Muntz: Internally, there's a lot of things. We are working toward no meeting days by starting with one specific day of no meetings. We are a CI/CD environment. We deploy about 100 times a day and making sure that the distance from developers, machine to production is small. We also don't have a stage environment. Sometimes I like fake ducking when I say that. We test in production through feature flags. We launch dark and then we can slowly ramp up to internal accounts and make sure that we're protecting the overall user base from change, but what that does is reduce the number of steps developers have to go through to get things into production and get momentum really going. We're also always thinking about and working on our overall development environment and making sure that that's easy enough. You press one button or type one command and all the things happen and you're off running to the races trying to get work done for customers.

From an external standpoint, Mailchimp's API is pretty robust. In fact, a little more than 50% of our HTTP traffic at Mailchimp is actually serving API requests. The development ecosystem is really huge for us and huge for our customers. Because it's so huge for our customers, we put a good bit of emphasis on making sure that it's working well, it's documented well, it's easy to understand, it's easy to grok and it's not just so complex and you have to run through all these hoops and do all this and that.

One of the big things there is code that you can copy paste from developer documents and just go to town and bash commands. Just copy something that you can just run in the terminal. It's got verbose flags already on, so you're going to see all of the things that are happening when cURL requests are made. That kind of thing is hugely important.

One thing that I really love is all APIs are going to error at some point and I have always found that so hard to test. You can code it, but you have to wait for the service you're integrating with to fail or error out. Can I test a 500 or can I test a bad error? We've, over the years, built a few headers that you could drop in that'll return error codes so you can just drop those tests in automatically. I find that type of thing to just be really great and really useful.

The other last thing is our mobile team makes almost complete use of our public APIs when they build our mobile apps, which gives us this really great internal feedback loop that you typically wouldn't get. We have sort of like a first group of users who are hugely important and internal, so they can give us great feedback on how things are going there.

Shane Hastie: Thank you so much. If people want to continue the conversation, where do they find you?

Eric Muntz: They could find me on Twitter at @Muntzen, M-U-N-T-Z-E-N. I have open DMs, so reach out. Of course, the plug we are hiring! We are remote-friendly, so we're hiring all over the place also in Atlanta, Brooklyn, Oakland, and Vancouver, where we have office locations. Also, just find me, Eric Muntz Mailchimp on LinkedIn. I'm pretty active there. Those are the two spots to get me.

Shane Hastie: Thank you so much.

Eric Muntz: Thank you. It was a pleasure.

Mentioned

About the Author

More about our podcasts

You can keep up-to-date with the podcasts via our RSS Feed, and they are available via SoundCloud, Apple Podcasts, Spotify, Overcast and the Google Podcast. From this page you also have access to our recorded show notes. They all have clickable links that will take you directly to that part of the audio.

Previous podcasts

Rate this Article

Adoption
Style

BT