Customer Obsession in Action - Case Study from Mailchimp

Customer Obsession in Action: Case Study from Mailchimp - Interview with Maura Kelly (VP of Engineering, Mailchimp)

Customer obsession is a great value that’s helping many companies reach their maximum potential.

But it’s not at all obvious how it translates into practice. Especially not in software engineering.

We bring you a specific story about implementing customer obsession into your engineering team via an event. It’s told by Maura Kelly, VP of Engineering at Mailchimp, and she details how you can sell customer obsession internally, organize a similar event and more. This post is written based on episode 57 of the Level-up Engineering podcast hosted by Karolina Toth.

This blog post covers:

• Customer obsession in software engineering
• Customer obsession event
• Origins of the customer obsession event
• Getting buy-in from leadership
  • Prepare the pitch
  • Find the decision makers
  • Reach minimum viable buy-in
• Getting buy-in from software engineers
  • Impact
  • Improvement
• Feedback for the customer obsession event
• Customer obsession changing development
• Pitfalls of customer obsession
  • Rigid vision
  • Lack of direction
• About Maura Kelly

What is customer obsession in software engineering?

We did an experiment last summer that we named a customer-obsessed sprint. ‘Customer obsession’ is one of our core leadership values; that’s where the name is from. Outside this, even the general idea is to prioritize the customer’s needs and to work backwards from there.

We’re using our own version of agile software development at Mailchimp. We normally work in two-week sprints and dedicate one of them to focus solely on bugs and customer issues rather than new development. Everything we do is aimed at making the product better for our customers, but teams tend to prioritize building new features, so taking a pause and solving lingering issues was valuable.

We didn’t involve the entire company, only the functions that were directly responsible for the product. This included everyone from engineering, design and product.

What did the customer obsession event look like for your teams?

We’ve been working remotely for the past few years at Mailchimp, so the event was remote as well. We used to do events in-person and even fly remote workers to the office to get everyone together. This posed the additional challenge of drumming up excitement in the teams.

We used asynchronous tools to coordinate the work. One of these tools was the shared dashboard that collected the issues and helped us keep track of progress and who was working on what task. The event ended up looking different for each team.

The teams

We deliberately chose to leave the teams as they normally are for this event. I considered letting people choose their own teams based on what problems they wanted to work on. I think that’s a valuable idea, but we decided against it, so the teams got to keep going with their regular meetings and normal workflow.

We may experiment with this in future iterations, because choosing your own team makes the event feel more like a hackathon.

We gave the teams a list of ranked high-profile customer bugs. The rankings included their impact and how old they were. Some bugs were reported by customers years ago and still hadn’t been fixed.

The teams also knew their domains of the product, and what needed extra work there. So each team worked on a mix of old bugs and lingering issues in their own areas.

We had a dashboard where everyone could see the issues that had been tagged in the customer-obsessed sprint, and which ones were open or resolved.

We timeboxed the event into a sprint, so it lasted two weeks. This enhanced decision making because it forced us to take on issues that could make the biggest impact in that time.

Where did the idea for a customer obsession event come from?

This idea didn’t originate from one person. It came from different parts of the company. People on different teams and different levels started thinking about similar ideas, and we all came together and made it happen. It came from engineering, management, and from our support team.

I had co-conspirators who helped me plan it out and make it happen. Shout out to Mehdi, Lee, Cal, and Ariana for all the help. They were working on their own pitches about similar ideas.

Cal and Ariana are from our customer team, and they had worked on a pitch for the development teams to focus on knocking out as many customer bugs as possible. Mehdi and Lee are from our engineering team and our Q&A team, and they were planning an event to deal with technical debt and bugs in their domains.

My idea was to take a hackathon and flip it on its head. We broke the regular day-to-day work, but rather than telling the developers to work on anything they wanted, we made customer issues the focus for everyone.

We all got together and worked out the common patterns across our ideas that resulted in this event.

How did you get buy-in from leadership for your customer obsession event?

Selling my ideas to other leaders is one of the aspects of leadership I still struggle with. Trying to get someone to do something you assume they don’t want to do can cause negative feelings.

People in engineering tend to fall in love with their new idea, and they assume that when others see their point, they will immediately support it. In reality, this rarely happens. Even if you have a brilliant idea, you’re going to have to sell people on it.

Prepare the pitch

I had informal chats with other leaders, and I did a presentation to our executive leadership team about the event. We worked together on the pitch with my co-conspirators to get everyone to understand what we aimed to do. We considered these questions:

• What is the priority for leadership?
• What do they value?
• What will be the impact of this event?

We have a set of core leadership behaviors, and one of them is customer obsession. It became one of the selling points that this event would deliver tangible benefits to our customers, which is in line with our customer obsession value. This helped our case.

Another selling point was the impact to our customers. Most of our customers’ busiest season is Q4, so the engineering team typically focuses on bug fixes over deploying significant changes to our systems to avoid potential outages. Taking the time to get rid of bugs before that time had a significant impact on our customers’ experiences with the product.

Find the decision makers

Organizational decision making is often complicated and makes it difficult to figure out who should have the final say in certain matters. In a leadership position, permission often isn’t binary. As long as key stakeholders don’t oppose your idea, most of the time you can go for it, and ask for forgiveness if necessary rather than wait for permission.

Cross-functional leaders

I’m part of the customer delivery team; we call it CDT. This group consists of the cross-functional leaders across all disciplines. We meet every Tuesday to give each other an overview of how we’re delivering the product for our customers and how the teams are doing.

This was the natural place for me to start getting buy-in. If you’re a VP and you don’t have a team like that, you should still start by talking to your cross-functional peers.

The biggest question we always had to answer was whether it was an engineering-only event. Our plan was to take it beyond engineering, and make the most out of cross-functional collaboration, because for every bug in the code, there must be a designer out there thinking they can make the interface better. Involve your cross-functional partners, and make sure to hammer home the impact of your idea on the customers and their teams as well.

Another difficult question was picking a date for the event. We worked with project management to find the right time because they know everything when it comes to the calendar and the teams’ rhythms.

Executive leadership

I did a presentation for the executive leadership team about this event. I emphasized the event’s impact on our customers and it’s alignment with the company’s values.

Reach minimum viable buy-in

I heard the term ‘minimum viable buy-in’ from one of my team members. You can’t expect to always get an explicit blessing on your idea, but you can go ahead with it when you reach minimum viable buy-in.

At this event, I realized we’d reached minimal viable buy-in during a meeting with our product leadership team. Someone asked, “Who says we can do this?” I told them, “We do.” That moment felt great; that’s when we all knew we could move forward.

How did you get buy-in from your software engineers for this customer obsession sprint?

Impact

Software engineers generally want their work to have an impact, so I aimed to show them what the impact of this event may be. Our customer team has many tickets in Zendesk about customers reporting issues. In this one sprint, we resolved about 1,300 tickets.

We created dashboards for everyone to be able to track our progress and get a feel of the impact.

Improvement

Engineers are learning all the time, so even if they’re doing a great job, they can likely make the code they wrote six months ago better with their current knowledge. You can tap into their natural perfectionism to get buy-in from them for an event like this.

What was the feedback for your customer obsession event?

Positive feedback

We've received mostly positive feedback. People enjoyed it, especially the aspect that they had more freedom in deciding what they want to work on and we fixed some old bugs along the way.

Some people have even asked when we’re doing another customer obsession event - that’s always a good sign.

Constructive criticism

Provide more direction

We talked a lot about how much direction we wanted to provide for the teams. In the end, we left it more open-ended, and let the teams figure out what they wanted to work on. Since then, we’ve received some constructive criticism for not being more directive; we’ll consider this next time.

Communicate earlier

We managed to pull this off relatively quickly, with just two weeks of preparation. We also received some constructive criticism about not communicating it early enough. If we do it again, we’ll make sure to communicate it more and further ahead of time.

Repeat

Currently, we don’t have specific plans about repeating this customer obsession event, but the feedback and the impact was positive, so we’re likely to do it again. It may become a regular annual or bi-annual event, as long as it won’t put our teams in the mindset of ignoring bug fixes outside them.

Has this customer obsession event changed your development process?

Increased customer obsession

I don’t have a quantitative answer to that at the moment, but qualitatively, it was great to raise the customer problems in the minds of everyone on our teams. Putting the customers’ experience on everyone’s mind is always a win. It definitely increased my empathy for the customers and affected my way of thinking.

Keep bug fixing in the routine

The customer obsession bug fix sprint was successful, but that doesn’t mean that you can forget about bugs in between these events. We typically prioritize bugs at around the end of the year to make sure that the platform is stable for our customers, but teams are always working on outstanding issues and bugs during their normal sprints.

What may be the pitfalls of a similar customer obsession sprint?

Rigid vision

When you’re organizing an event of this size, you have to stick to your vision while staying flexible. When you involve so many people, you’re going to get feedback along the way about timing and other areas.

You have to be flexible enough to take feedback while sticking to your core vision. Stick to your core vision and goals, and people around you will take note of you working to accomplish something specific.

Lack of direction

If we repeat the event, we intend to be more directive about priorities, communicate better, and make the teams more comfortable with the event. We’ve received constructive feedback about this, so we’ll iterate on this aspect.

About Maura Kelly

Maura has been at Mailchimp for seven years and is currently VP of Engineering. She’s leading teams working on the product side alongside her cross-functional partners in design, marketing, and product.

She majored in computer science and started her career as a backend engineer. Her favorite language is Python. Since then, she has transitioned to management.

She lives in Atlanta, Georgia, with her husband, her five-year-old daughter, and her dog. She loves playing Wordle, she loves to read and run, and she’s been working on learning German as a hobby.