Organizing Your Email Team to Scale Without Going Insane

Alex Mohr
8 min readNov 28, 2016

--

Assumptions & Goals

Before we get started, I’m going to assume that you understand the importance of email as a platform. You’re a growing company and you understand how much of that growth is coming from email, so I’m not going to walk you through all of the studies that show the significant ROI of top-notch email programs, the role of email in marketing analytics, the importance of mobile-friendly design. Cool? Cool.

Now when I talk about email at scale, it’s not just sending an extra couple million emails a day, it means adapting to the increasingly complex demands of a scaling startup. Between launching new features, sunsetting old ones, and trying to keep a hockey stick of new users around, the work can pile up.

The goal here is to get a handle on what it means to go from having an ad-hoc email “team” to a high-performing email organization. Part of the point was originally to figure out what we need to build here at Sendwithus, however the result is neither a mission statement nor an advertisement, but hopefully a useful resource for people attempting to build out top-tier email teams. Ready?

Email is a Client, not a Channel

Buckle up — the road to email perfection may be a bumpy ride and a lot of the recommendations listed here are going to require commitment from you and your team. Even people who accept the value of email, often still think of it as an afterthought or just a line on the inbound traffic report.

If you’re having trouble getting buy-in, remember that vision is the cure for reluctance. This means you’ll need to have a clear idea of the team you want to build and the technology they would be using.

Part 1: The Team

1) Commit to Email

Something that has come up frequently while interviewing people for this piece is that a tremendous long-term drain on an email team is keeping people around that understand email development.

Because so many email designers and developers find their way to it by accident (seeing as how there’s not much in the way of Email Development degrees) email is sometimes seen as a sort of purgatory for young marketers, designers, and developers. This gives off the impression that it’s an afterthought, and often the salaries and internal org structure reinforce this belief. But as any good manager knows, if you want to see success out of a team, they have to know you’re committed to them.

Note: Sparkle Motion is not supported in Outlook

This can take many shapes, but most importantly it means giving resources to your email teams and listening to them when they say they need more.

2) Invest in Experience

Killer email requires a killer team. And growing a killer team from scratch using people whose experience is only tangentially related to the task will set the whole team up for disappointment. For some reason this is often the case in email, perhaps because there’s little in the way of formal training for email design/development so junior designers and developers get thrown in the deep end.

We’ve talked about committing resources to email teams being important and one of the most important resources is experience. Good designers and developers with a lot of email-specific experience can be tough to come by, but they are absolutely vital to a successful email program. If you can’t hire one, train one; don’t just throw someone on email duty, present them with viable career advancement opportunities within the email space.

In other words: email is not just intern work

3) Divide and Conquer

Web teams have long overcome this idea that the whole copywriting, design, and development processes are run by the same one or two people, the next step for email to come into it’s own is for email teams to go through that same process.

If you’ve decided to take the leap and build out your “email team” what exactly should you be looking for and how should those people work together?

Division of labor doesn’t always mean everyone working on the same thing at once

Organized Hand-offs

If you’re going to separate out the functions of design and development, the easiest mistake to make is to fail to delineate responsibilities, dependencies, and timelines. The work of these separate teams need intersect only once at a quick hand-off meeting.

Similarly, the order in which things get done matters. In most successful teams, it looks a little like this:

The arrows are not magic; they should be meetings or specific protocol.

Each arrow in the diagram is a discrete meeting where one team can say “here I am done with this” and the other can look it over and accept ownership of it from there on.

Use Fresh Eyes for QA

This is one of the things that I hadn’t really considered until getting into the interview process: you should have distinct people responsible for QA. Obviously you don’t need a team of full-time email QA people, but it’s a good idea to have some people around that are familiar with the complications of email development to give the final product the go-ahead.

Part 2: The Tech

There’s certainly no shortage of Big Lists of Tools to improve your development workflow. But what I’ve found researching this piece–and indeed in my own experience–is that the tools come secondary. There’s rarely a correct tool for everyone, you want to find the tech that fills holes and smoothes bumps in your development process.

As such, finding the right tool often means having a really strong grasp of where the choke points are in your organization, so instead I want to talk about where to look for those opportunities for effective use of new tech.

1) Reduce, Reuse, Recycle

Code reuse is a common refrain for developers, but things like pattern libraries and basic templates can make a huge improvement on your development process. This could be as simple as storing snippets of code in a spreadsheet (or try the Litmus Community Snippet Library) if you’re a solo operation and your editor doesn’t have the functionality built in.

These kinds of practices will shave some time off of your projects but, more importantly, they’ll help you build good habits and tendencies. The more people you have involved in your process, the more sacrosanct your repositories become. The end goal is for coders to be working almost exclusively in the library, and a little bit of organization early on will go a long way for them.

2) Embrace Automation

This may seem pretty broad, but there are a wide variety of ways in which you can use task runners to improve not only the turnaround time, but also consistency and technical debt accumulation of your team.

Inlining your CSS is no longer necessary since Gmail has stopped stripping style tags, but there are still plenty of arduous, manual tasks involved in creating a new email like uploading images to your CDN and creating proofs (something you’ll probably end up doing a lot more of than you expect.) If you’re using dynamic data, you can also use automation to merge in dummy data for previews.

Some examples:
Lee Munroe — Using Grunt to Make Your Email Design Workflow Fun Again
Victor Garcia — A Workflow for Responsive Emails Using Ink and Grunt

3) Go Modular

This came up with pretty much everyone I talked to in my research. Maybe not always as a “thing we’re doing right now with success” as much as a direction people pointed when I asked what their plans were for the future. This is way too huge of a task to cover in depth here, but I thought it was worth mentioning for anyone who may not have thought about it before.

Modular design is the logical extension of code reuse and automation. The idea is that the designers and developers maintain a library of modules that can be plugged into a template and automatically compiled into flawless designs like LEGO bricks in the hands of a master builder.

This not only means that updates to modules can be rolled out across all of your templates instantly, but also that your team can set up A/B tests, localization, translations, and a host of other advanced stuff more easily.

Now if we take another look at that production flow, you can see that the process for drafting a new email has been trimmed down to decrease the drag between idea and execution.

With the module development separated out, it can move in parallel with email creation and assembly. This is where all your disciplined organization and investment in the team really pays off.

Some Examples and Walkthroughs:
Brian Graves — Improve Your Email Workflow With Modular Design
Geoff Phillips — Accelerate Your Workflow with Modular Email Design

Putting it all Together

The exact form this will take–much like a lego car–depends on who you are and what your goals and resources actually look like. What matters in the end is what works for you.

I’d love to hear more tales of success (or hardship) in scaling your email team in the comments or you can reach me directly at alex@sendwithus.com or on twitter.

Thanks!

And a huge thanks to John Egan at Pinterest, Eric Lepetit at Nest, and Morgan Kazan and Abby Feuer at DonorsChoose for taking the time to talk to me about their organizations and to all the Sendwithus customers that have helped give us direction (and pay my rent) all these years! Also, shoutout to the #emailgeeks community for being such a legitimately kind and generous group and thus making this all possible.

--

--