I was bleary-eyed, sipping coffee on yet another pandemic morning in the autumn of 2020, when I received a message that grabbed my attention. The subject line read: “Help Mailchimp empower the underdog!”

Mailchimp, I soon learned, was ramping up their investment in developers, and they wanted to bring that to the next level by hiring a Developer Advocate. Admittedly, I wasn’t looking for a new role—and maybe more importantly, I’m not actually a Developer Advocate. But I was curious, and empowering the underdog is my jam. I decided to talk to them anyway. 

In my experience, a Developer Advocate represents the external developer community internally, and the internal developer experience externally. Kind of a mental tongue-twister! Developer Advocates need the right tools to succeed: an internal API strategy tightly linked to Product, for example, or quantitative and qualitative metrics on how developers are working with APIs and other products. How happy are developers with API documentation, or the ability to troubleshoot integrations while building, or getting inspired on what to build in the first place? 

My first conversations with Mailchimp made it clear that developers were an essential part of their overall growth as a company. They’d brought on a stellar agency to relaunch the developer site you see today, and they’d invested in a complete overhaul of their documentation. 

But there were still some major gaps in their strategy. How did they plan to expand their APIs as part of the product roadmap? How were they going to approach their growing community of app builders? And how could they elevate their incredible engineers and showcase how interesting and fun it is to work at a company that processes one billion emails for their customers every day?

Throughout my career, I’ve been lucky to find myself at some pretty amazing companies addressing these very same questions. With a background in B2B marketing, I pivoted to Developer Community and Developer Relations a decade ago, when I took on a “wearing all the hats except directly engineering the API” role at Context IO. I would go on to build foundational developer ecosystems for companies like Intel and Shopify. After a stint in consulting, my last role was at HubSpot, so clearly this whole small business platform jazz is appealing to me. 

There’s no company that cares as much about small businesses as Mailchimp. But they also didn’t realize that they weren’t ready for a Developer Advocate. So I somehow chatted my way into an offer for a new role: Senior Manager of Development Community, with a focus on building out the structures a Developer Advocate would need to successfully listen to the developer community and create resources based on their direct feedback. Helping Mailchimp build the foundation that will empower developers to empower the underdog—our Developer Community mission—was too good an opportunity to turn down.

Listening to developers first

When many organizations start to build developer programs, they only look outwards, at the developers using their products. Shockingly few start inward—with their very own software engineers—but there’s actually no better place to start. 

At Mailchimp, our engineering mission is to “give marketers production-ready software designed to help them grow” and engineering success happens through “togetherness, momentum, and pragmatism.” Our engineers have built some incredible developer products over the years. Beyond our core Marketing API, Mailchimp launched Mandrill—now Mailchimp Transactional—nearly a decade ago; it currently powers email operations for thousands of developers and organizations. And in 2020, Mailchimp acquired Reaction Commerce—now Mailchimp Open Commerce—an open-source-licensed commerce platform that allows developers to customize its API and build commerce stacks for retailers of any size.

Between building our own products and bringing on teams from our acquisitions, Mailchimp has built a prolific engineering team. Like any startup, Mailchimp’s early days were scrappy—in the 2000s, the team was small but mighty. As the business grew, so did the needs of the team: in 2017, we went from a DevOps model to a full engineering model, and today, Mailchimp boasts over 400 engineers across multiple teams.

But with a nearly 20-year history, we’ve certainly seen some bumps in the road along the way. While the complexities of the business changed and the engineering team grew, we didn’t always turn to our own developers before making critical decisions about developer products. Just look at when we changed our Transactional pricing model in 2016, which forced Transactional users to sign up for Mailchimp to continue using the product. This switch didn’t make sense for a lot of Transactional users, and in the process, we eroded developer trust. 

That erosion in trust taught us that we need to listen hard to developers, and turn to our own team before making sweeping changes. That humbling lesson kicked off a series of changes that led us to where we are today—a brighter day for our developers. We’ve spent the last few years holistically researching the developer community, investing in resources like our pretty dope (if I do say so myself) developer-focused website, overhauled documentation, and open source projects. 

But listening hard to developers also means listening hard to our own engineers. What kind of work excites them? What keeps them happy? How can we ensure we have a safe, inclusive work environment to attract and retain the most diverse and talented engineering team? While we’re working on some audacious plans to solve for that internally, I’ve been brought in, in part, to harness the incredible talent and energy on our engineering team and share some of their brilliance with the world.

Supporting a growing developer community

With this group of outstanding engineers helping to pave the way, Mailchimp is investing in the tools, resources, and humans needed to support and grow a healthy developer community. I’m truly honored to be leading the charge as Mailchimp’s first developer relations person. Here’s how I approach DevRel, and how I’d like to translate that to Mailchimp’s developer programs and community.

First, I’d like to see us elevating developer stories a lot more than we do now. Our internal engineers solve complicated and interesting problems, day in and day out, and our partner developers are building cool shit. We want to shout this from the rooftops and start celebrating these wins!

We’re also hoping to share tactical advice, investing in more guides, tighter docs, relevant API and product updates, more sample apps, and more content types throughout /developer—can you say video? Can you say 3D hologram? OK, maybe no 3D holograms anytime soon, but we’re letting ourselves dream! The goal of this more tactical content will be to make building with and on the Mailchimp platform as frictionless as possible for developers. 

And while we’ve always wanted our developer experience to be as smooth as possible, right now we’re especially invested in opening up more possibilities to build on top of Mailchimp. We have 11 million active customers, and try as we might, we can’t solve for every one of them. We want to make it as easy as possible to build the next great app that will empower our customers in ways we couldn’t have imagined. By working towards surfacing more easy-to-use, well-documented APIs, we want to help unlock developers’ creativity to build something great. 

Another way to move toward a less friction-ful, more inspiring building experience is to start making room for community and connection. Historically, there haven’t been any dedicated spaces for developers working on and with Mailchimp to connect with each other: to share ideas and feedback, to help each other work through issues, to build networks, and hell, maybe even to make some friends? I want to change that. These efforts will begin in earnest in 2022, but know that I’m working on the inside to get y’all connected. And now that we’re looking forward to a post-Covid world…maybe we can even meet in person sometime! Freddie stickers are in your future, folks. 

Ultimately, at Mailchimp, we want to empower our developers to empower the underdog, while ensuring we’re building a community that’s inclusive to any developer who’d like to join us in that mission. We want to hear from you. What’s missing from your experience building on Mailchimp? What’s stopping you from building the next great marketing app to support our millions of customers? I want to build these programs and this community around your needs, so get in touch anytime: @SarahJaneMorris, devrel@mailchimp.com

Introducing “Mailchimp Engineering”

So here we are, on one of the first outward-facing steps towards helping developers empower the underdog: our brand-new blog, “Mailchimp Engineering.” We wanted to give our engineers the space to talk in public about those complicated and interesting questions they tackle daily: the unique types of problems they have to solve and the creative ways that they solve them. 

On this blog, you can expect to read some powerful longform posts on software development—problems large and small, and how we approach them here at Mailchimp. We’ll be starting with tales from our own engineers, but eventually we’ll share experiences from the broader community as well, including external developers building apps on Mailchimp, or using Mailchimp Transactional or Open Commerce.

I’ll close with a teaser or two: while 2021 is all about foundations, we have some big things coming in 2022, things you’ll want to be ready for. So stay with us, tune into this blog, and watch as /developer evolves into a complete Mailchimp Developer destination. And in the meantime, keep your eyes peeled—we’re planning on posting something epic here monthly. We’ve been working with actual tech journalists and editors, and I’m so proud of the posts our engineers have in the queue. Can’t wait to go on this journey with all of you!