Maura Kelly is VP of Engineering at Mailchimp. With over 17 years of experience in the tech industry, Maura is an expert in software development and programming. She joins Melissa Perri on this week’s Product Thinking Podcast to provide engineering’s point of view, and to share helpful tips that will improve the way you as a product manager are collaborating with developers.
Show Notes
Here are some key points you’ll hear Melissa and Maura talk about in this episode:
Maura’s traditional path to engineering, and her experience at Mailchimp, where the culture is about empowering the underdog.
Mailchimp’s first product managers came from other internal disciplines and were workers who already knew Mailchimp and their customers very well. Over time, they continued nurturing people into product managers and started hiring people with product management experience externally. They also mixed up the teams, so that people new to Mailchimp could learn from veterans of the company.
There is a misconception that engineers don’t care about customers and should keep their heads down doing code, Melissa says. “Engineers want to work on stuff that matters,” Maura claims. They want to be part of a larger mission that makes a difference; it motivates them and enhances their performance. If your head stays down, it’s hard to know the context and information that can help you build a better product. “First solve the problem, then write the code,” she adds.
Why engineers should be involved in the discovery process, and how this can be done.
Combining something that someone wants to do with something the company needs, is a great way to both solve a problem and motivate an employee. Maura shares how Mailchimp conducts this ‘management magic.’
Melissa and Maura explore how product managers and engineers can work with leadership to ensure their teams focus on the right things. If there are people that aren't a good fit or aren't doing the best work that they could be doing for whatever reason, that should be discussed at the leadership level.
One thing people don’t realize about engineering is that there is a lot going on behind the scenes. Not only do they write code for solving customer problems, but they also have to write that code to certain coding standards; they’re also getting code reviews, giving them to other people, thinking about the security of the feature they’re writing, among other things.
Product managers often struggle with understanding the technical side of building a feature. Melissa asks Maura how they should be checking in with the engineering team about the timeline of things that need to be done.
Resources Maura Kelly on LinkedIn | Twitter MauraChache.com
Episode Transcript
Melissa: Hello, and welcome to another episode of the product thinking podcast. Today. We have more Kelly, who's a VP of engineer at MailChimp here with us to talk all about how product managers and engineers can work better together. So welcome Mara. Thank you, Melissa. So Maura, you came into MailChimp when it was very early, but before that you had an illustrious career in engineering, we were talking about how you kind of got involved with it. Tell us, like, how did you end up at MailChimp? What was your to get there? And what was it like when you started?
Maura: Yeah. So one of the things I love about MailChimp, we have a lot of folks in engineering who did not follow traditional path into engineering. They're amazing and creative people. I followed a pretty traditional path into engineering. Um, I majored in computer science and I worked at a startup to start. And then in, in Atlanta I worked at the Atlanta general constitution and then its parent company at Cox enterprises. So I came to MailChimp in 2015 and it was much smaller. Um, we were about 350 people and everyone was wearing a lot of hats at the time, had just really great energy, but I've seen it grow and scale a lot in my time here.
Melissa: Yeah. What was it like when you walked in? Can you describe kind of like the culture and the people and what was going on those days? Yeah.
Maura: So one of the things I always tell people early on when I was, when I would interview other people to come to MailChimp is I had this idea about the MailChimp culture and just sort of creative misfits. And we're all about empowering the underdog. And it was true. Everything I heard was true, just, just a really great energy. Uh, we were in a building at, on a street here in Atlanta called means and call it mean street. Then later we moved into pond city market and everyone just sort of sitting together, working really closely together. It was, it was a really exciting time.
Melissa: And MailChimp was really founded by design people too. Right? Like that, that was the founder's big push was, he was a designer. He wanted to make really cool emails for people. What was it like in the early days? How did like designers product managers and engineers all work together? Yeah. So
Maura: The funny thing is that when I, I started, we definitely had engineers and designers, but we didn't have any product management at the time. Everyone was kind of wearing many hats and kind of everybody was a product manager at that time.
Melissa: Did that work? Like did, was it confusing? Was it hard to prioritize or, you know, things just worked fine.
Maura: I think every organization, you know, it works for the size that you are and you know, it might change over as you scale. So, you know, at that time, one of the stories I like to tell is we had a billing part of the application obviously to take the money and we had one engineer working on that. And nowadays we have a whole team of a whole cross-functional team working on that. And that's just the, sort of the evolution of the company growth.
Melissa: So now though MailChimp does have product managers. Right. Right. So, you know, when did you guys all decide like, Hey, we actually need this role and what caused that?
Maura: Yeah. So I think that that was really just a, kinda a company wide scale thing, right? So we were going from, uh, we would always say internally startup to grown up. We were going from a, a team of generalists and starting to build out teams of specialists. One of the metaphors that we used a lot during that time actually comes from an article by Molly Graham who was at Google and it's giving away your Legos. So you have to, it feels very worrisome to sort of give away parts of your job, but it's all about scaling the org to do more. What worries.
Melissa: Some of the, the problems that you were kind of seeing that made you go, Hey, we could use product management for this to give some context. I get asked this question a lot is like, when is the right time to hire your first product manager? Usually it's the founders who, you know, were the product managers.
They have this really strong vision for what the company is. And then you start scaling, like you said, and we start to think, think about, when do we introduce the first product manager, three 50 people sounds like a lot to get to without product management. So I'm curious like how decision making was made before then if you're all the product managers who was really like leading that prior decision decision, the vision decisions, and then what broke where you were like, Hey, we need product managers now.
Like we need to specialize. We need to keep going. Yeah.
Maura: So I think the, probably some of the driving force behind that was taking MailChimp from an email platform to a marketing platform. So the complexity of the product grew and that's, that to me would be like a really obvious time to start thinking about having product managers, focusing on different areas of the product. And of course, different maybe customer segments that might be served by those.
Another thing that we did at that time was our first product managers actually came from we're all internal. So they came from other disciplines into product management. So to start, it was people who already knew MailChimp really well already knew our customers really well.
Melissa: And those people who transitioned into product management as well, how did they learn what to do? And, and how did you make sure that they were set up well to succeed in their role?
Maura: Yeah, so obviously we're all learning how the job every day, but over the time, introducing product at MailChimp, we've both nurtured P people from internal to become product managers. And we've also hired some, um, outside people with experience and product management. So kinda doing both.
Melissa: Yeah. I find that helps a lot is like, if you can mix up the teams and have people to learn from who have not worked inside that company before, or have done that before, to me, that's been the most successful thing to getting product managers up to speed. But I also have a question about like the rest of the organization. Was there any tension between the engineers and the product managers when this started, if you guys were playing the product management role, did anybody go? No, that's like my job, what are you doing? Are you taking it over?
Maura: Yeah, of course, right. Like this is a change and like all, all changes. It requires communication navigate. There's definitely a learning curve and change curve to get people through. Again, we talked a lot about the Legos metaphor and how to grow up as a company. We needed to have people specializing in different areas and we would, we would all do more together that way.
Melissa: So what types of things do you do as a team at MailChimp to make sure that the engineers and the product managers and the designers like all work really well together,
Maura: This gets into planning, uh, one of my favorite topics and we have tried a, a number of different ways to do MailChimp one way we did for a long time, which ended up sort of just becoming too difficult as we scaled to manage the whole team, but we would do a planning week and that would, every single team would, would stop their in progress work for that week. And everyone would get together and just really dig into the next quarter of work. They wanted to do understand all of the needs from all the disciplines.
So from product, from engineering, from design, what we would need to do to accomplish that work, we have gotten big enough that doesn't really work for us anymore, but we do try to look at like quarterly roadmaps, usually kind of planning out for a quarter. And we do a lot of review on those from an engineering perspective. And then maybe also a design perspective to see, you know, kind of like what dependencies that we have, what gaps we have, what sort of resourcing we might have.
So one thing do now is we do quarterly road mapping and we do some reviews both with the teams, but also at the leadership levels to understand what dependencies might be in those roadmaps, what resourcing needs that we might have, you know, kind of just what pitfalls might befall us and then work with our teams to, to address those. So as like
Melissa: A VP level engineer, what types of activities do you do with like the VPs of product and with the VPs of design, what's your kind of, I don't know, week to week, month to month quarterly, big things that you do.
Maura: So at Mailchimp, I'm a member of a team. We call the customer delivery team or CDT. And so that's folks at a senior director and VP level. And so we actually spend all Tuesday afternoon together with each other, just looking at what the teams are doing, anything that we can help with. We'll have teams come and, and report to us, or really it's more about them, you know, sharing, progress us in getting any support or advice that they need.
We'll also take a look at kind of like our customer metrics. So we do, um, a voice of the customer voice of the customer session on a regular basis. So that's my Tuesdays. And then of course, other ad hoc things will come up during the week where I'm partnering closely with my peers and other departments.
And then of course I have one on ones with my here's another department, just keep in touch that way as well. How
Melissa: Are you involved with the product management team when it comes to like setting strategy, figuring out like, should we go into these markets? What should we do to like extend MailChimp? Like I know you guys went through really big transition that you were kind of talking about just a little bit before from moving from an email company to a marketing company, and now you've been acquired, you've got this massive platform.
It does so much more than just emails. Right. It does a lot of different things. I think from a product perspective, a lot of the people listening to this know how product strategies set from like our world, but how do you bring the engineers into that? What types of questions do you wanna be asked?
How do you wanna be involved in that?
Maura: I think the thing that maybe people don't know is that there's a lot going on behind the scenes that they maybe don't see. And I would guess this is true for every discipline, right? Like I'm not a designer. I don't know what's going on behind the scenes and design. But you know, if you think about, especially like a modern engineer's role, they are not only writing the code for whatever customer problem you're trying to solve right now.
They need to be writing that to probably to certain coding standards. They're getting code reviews, they're giving used other people. They're trying to think about the security of the feature that they're writing. They might be having a transition to a new framework or maybe they used to write everything for managed servers.
And now they're running everything in the cloud. There's just like a whole world of things going on behind the scenes that might make everything that, that sort of simple thing you're asking them to do actually be a lot more complicated.
Melissa: Yeah. That sounds like a lot. I imagine too, like the engineers don't know how often product managers are like sitting in meetings, arguing about things, trying to like help the prioritization or deal with difficult stakeholders. So, so much behind the scenes on, on both of these parts, one of the things that we were talking about as well before was getting the engineers more in tune with the customers, making sure that they really think about their problems.
And you were telling me about this customer obsessed sprint that you did at MailChimp, where you all just took time off to, to work on it. Can you tell me a little bit about what that was and how engineering was involved and, and what that actually looked like.
Maura: Yeah, absolutely. I love to talk about this. So over the summer we did, um, a two week sprint, which we called the customer obsess sprint. And the cool thing about this project was kind of at the time, there were a lot of folks and even in different departments thinking about something like this for our customers, their busy season is the, is the end of the year as the holiday season.
We're trying to not to be disruptive. So we're not trying to like push out big changes right now that might mess anything up. We try to kind of keep it very calm right now. And this is the ti the time of year that we usually maybe dig into some of these customer bugs and maintenance work. But if you think about it being the busy time of the year for customers, we actually wanna fix these things for them earlier.
So a lot of folks that kind of been thinking about like, how do we, how do we pull this, this work up earlier in the year? So I had talked to several folks from other departments about this and that started to sort of coalesce into a proposal that we put together. And I, you know, kind of hopped that around with my peers.
I, you know, I, I talked about it with our executive leadership team and said, Hey, let's take two weeks, all the teams at the same time and say, Hey, let's just, let's fix cut customer issues. Let's, let's work on things that are affecting our customers. And you know, it ended up being strangely a really nice break, like a nice, a nice time to sort of just focus on kind of smaller things in these big sort of project product initiatives.
But we were able to resolve a ton of issues, a ton of JIRA tickets. We have Zendesk is what we use for our customer team. And so a ton of those issues linked to those share tickets.
Melissa: But so what was the result of the customer obsessed sprint? Like you put all these things out there really fixed a lot of issues. Did you get feedback on like, oh my God, this is amazing. What was the success metrics after that?
Maura: So we started with, we did this in a couple different ways. We have a large team and so kind of, wasn't kind of one answer that worked for everybody. But we started with a prioritized list from our customer team of kind of like top burning, burning issues and especially some old ones that have been out there. But again, with kind of having everyone involved in the process, we also encourage the teams to look at their product or their area of the product and things they know that needed to be worked on as well. And all the teams sort of prioritize that for themselves with those inputs.
Melissa: I feel like these types of things, sometimes the customer problems come from, from our support teams or from customer service or for product managers, we funnel that down. But then we've also got like all this tech debt that we usually have in these companies to fulfill. Right. And I, I think it's amazing that you've did the customer of self sprint, cuz I usually hear about tech debt sprints.
So that's U that's like what I, what I've heard from other companies. So I love that this one was focused on changing things for customers that were bugs or things that just not working for them. One of the top issues that I hear from product managers as well is understanding like what the cost is of tech debt.
And I feel like from a customer obsess sprint perspective, if it's like a UI thing, bug, something that you know is coming through support, people can put like a number on it a little bit or they can understand the problem. I think where product managers sometimes struggle is understanding the technical side, right? Like, Hey, it's gonna be 10 times slower to build this feature on this old platform that we've been using.
We have to restructure it or re architecture it. How should product managers be checking in with the engineering team about the health of the platforms to when those things are coming up and to make sure it's not too late, you know, when you go back and look at it and what types of questions should we be asking? How should we be having that dialogue?
How often should we be really looking at that? Yeah,
Maura: That's a great question how you should at, you know, but I think about twofold, you know, I think of is the result of decisions that we've made and honestly frequently they were the best decision at the time, right? There was a decision we made at the time with the information that we had. I think that in order to go forward in a low tech debt world, we wanna be asking questions like, do you have enough time to do this?
What are the implications of doing the, this, you know, some things we just have a fast turnaround time on and that's fine, but not everything is like that. Other things can be negotiated. So we wanna be having that dialogue on a regular basis, every sprint to make sure we're just not rushing everything out the door as fast as possible and creating technical debt.
And then I think for the things that are, that are longer running, like you talked about, you know, I find those always those always surface and they often surface this, maybe a little bit of that behind the scenes stuff, technical debt will surface and cause issues for teams and product managers. Don't always see that, right? Like if someone gets paid because something's broken, you know, product manager might never see that.
So you can ask questions about that too. And I, but I also think that sort thing is on engineering to, to product management as well. Like, Hey, this area is really causing a lot churn. And if, you know, if an engineer is getting paid for it, that means a customers problem. Right. And that's all of our problem to solve.
Melissa: Yeah. Definitely. One of the things that I've seen teams do is take like percentage of their sprint and just work on like technical issues or tech debt. Do you advocate for something like that or do you think there's better methods to make sure that we're paying down our TETA as we go?
Maura: I like that method in the sense that you're doing it all the time. I think that we're kind of setting ourselves up in a bad spot. We're just like, oh, we're just gonna take one sprint to do TETA and then it'll be solved. Like we kind of know that's not the way it is. I would rather stay on top of this on a regular basis and be talking about it on a regular basis.
Just personal philosophy. I think that I like rules of thumb that you might break sometimes. So like if you said that I wanted 20% of my sprint to be spent on tech debt every time I think that's great now. And again, you know, you're gonna have to either like lower that or raise it depending on the current needs of the team.
Melissa: Do you know, like you should lower it or raise it, like what types of things would make you go 20% is not gonna handle this? Like we have a huge problem here.
Maura: one of the things that can maybe drive that is if you're gearing up for something big, like maybe you're working towards something large where building on a, on the old platform isn't gonna work for you. That might be like a really good indicator if you're getting a lot of pages or, or dealing with a lot of customer complaints, that might be another good driver. Great.
Melissa: Yeah. I think those are really good things to look out for when product managers are thinking about prioritizing it. I'm curious too, like on the VP level, how do you have those conversations? You know, leadership level, when you have to do a massive overhaul or a massive re architecture, like have you ever had to like rebuild the platform from scratch and how do you decide whether to just build it behind the scenes and transition or do it in stages? What types of conversations happen there?
Maura: All of those ways that you talked about doing it, I've probably done it all of those ways. Sometimes that might happen. Like you said, a little bit more behind the scenes. One of the things that we've been working on at MailChimp is migrating more of our infrastructure to the cloud. And that's a thing that is pretty technical in nature.
It is gonna affect the product and product managers, but you know, a lot of the, there can be done on the engineering side. And so that's a thing that you can prioritize, make the business case for that, you know, you need, you need people to do that sort of work for other things. It might be something like putting together a pitch, just like you would just like a product manager would for, you know, a certain initiative where, you know, if you wanted to modernize a part of your platform, that's gonna have deep product implications.
I would write something up. I would talk about the benefits of it to the product, to the customers, you know, hopefully the sort of the sort of, you know, making a business case for things be familiar to your listeners, but kind of depending on the nature of the project, that one of those things
Melissa: That, yeah, so a lot of these decisions, it sounds like are happening on every level, right? Like not just on the team level about prioritizing tech debt, but also like on the VP level, all the way up to the leadership levels and the executive level of how do we keep our systems moving? It sounds like it's just more of a conversation between product managers and engineers all the way up and down the organization, right.
Of what's going to make this better for our customers. How are we gonna solve these problems? How do we transition our product into creating new value? Which I really like so more covered a lot of stuff in this podcast, which is awesome. I think it's really gonna help product managers understand how to work better with engineers, but I wanna hear what's your biggest tip for that?
Like how, if you could give any advice to all the product managers out there listening, what would be your biggest piece of advice for how they can work better with their engineers?
Maura: Yeah. So I'll say two things. The first is all sort of reiterate something we talked about already, which is both involve engineers and creating the, and give them space and time to work on that solution. So involve them, but try to definitely give them space where they don't need to be in meetings and can do their work. But if there's one sort of one tip I could take away that you could put into practice right today would be, don't use the word, just, I think engineers here a lot, get a lot of request. Like, can you just do this? And I think that makes engineers feel like people don't understand all the technical work that might go into that little just request. So I try to take just out of my vocabulary when I'm talking to
Melissa: People. Yeah. That drives me nuts too. So I totally see how we drive the engineers nuts. I think we all have really complicated jobs out there, whether you're a product manager, an engineer or a designer and using the word, just kind of belittles it a little bit. So lots of work that goes into building great products for people on every side, especially the engineering side as well. Thank you so much for being on the podcast today. If people want to learn more about you, uh, connect with you, what's the best place to get in touch. Yeah.
Maura: So I'm on Twitter. You can also reach out to me on LinkedIn and I'd be happy to talk more about this with product managers and Melissa, thank you so much. I really, really enjoyed it.
Melissa: Thank you more. Thanks for being here. So thanks for listening to this podcast. If you liked it, please subscribe to the product, thinking a podcast, anywhere that you listen to podcast. We always like that and stay tuned next Wednesday. For another episode of Dear Melissa.
