Case Study:
Building An Email Development Team
The Situation
When I joined Credit Karma's Growth Technology team in August 2024, there was an email development function — technically. On paper, the team existed. In practice, it was mostly dormant. Marketers were building their own email and push templates, wrestling with the code themselves, and losing hours to a process that wasn't really theirs to own. The team that was supposed to help them wasn't being used.
This is a story about how that changed.
What I Was Walking Into
Credit Karma's email infrastructure is genuinely sophisticated. Templates are built in Handlebars and compiled through a Node-based template manager, with all code versioned and committed to GitHub. It's a proper development workflow — which is great for maintainability, but it means that every time a marketer needed a new template, they were also wrangling Terminal, GPG keys, npm installs, and pull requests.
That's a lot to ask of someone whose job is to think about audience segmentation and campaign strategy, not dependency management.
The email development team's job was to take that burden off their plates. But they hadn't established themselves as a reliable resource. Marketers didn't know exactly what the team did, how to request something, or what to expect in return. Without that clarity, most people just kept doing it themselves — or didn't do it at all.
Adoption was sitting at around 10%
What I Did
Defined the Service
The first thing I did was get clear on what we were actually offering. I put together a team overview deck — what the Email Development team does, what we don't do, how to submit a request, and what to expect once you do.
The service covered six categories: template builds, template updates, template support, new module development, bulk updates, and design troubleshooting. Each one had a defined SLA.
Naming what we did — and what we didn't — was more important than it sounds. It gave marketers a mental model for when to come to us, and it gave the team something concrete to hold themselves accountable to.
Built a Request System
Before I got there, there was no formal intake process. Requests came in through Slack, through ad hoc conversations, through whoever happened to be paying attention. It was impossible to track, easy to miss, and impossible to report on.
I built a proper request system using Airtable. Marketers could submit a structured request — specifying the type of work, the vertical, the priority, the desired due date — and get email notifications at every stage: Groomed, In Progress, Completed. When work was done, they'd receive a pull request to review and approve.
A separate dashboard tracked tickets completed by vertical, commit volume by quarter, and average turnaround time.
By Q4 FY25, we completed 51 requests in a single quarter, saved marketers an estimated 75 hours, and maintained an average turnaround of 2 days.
Created Documentation That Actually Helped People
One of the quieter ways I built trust with the marketing org was through documentation. Not the kind that gets written once and immediately goes stale — actual, maintained, step-by-step guides written for the people following them in real time.
I wrote a setup guide for new template authors covering GitHub account creation, Personal Access Token setup, GPG key generation for signed commits, and local development environment configuration. I wrote a Node version update guide with a 4-part walkthrough, escalation paths baked in at every step, and an appendix for edge cases.
These weren't just documentation for the sake of documentation. They reduced the volume of support requests we fielded, enabled more self-service, and — just as importantly — signaled to the marketing org that we were a team that thought about their experience carefully.
The design system documentation I maintained on the internal Google Sites also got a significant overhaul in Q4, with richer code samples, clearer configuration options, and better examples. The result was a measurable drop in month-over-month Slack support requests.
Brought AI Into the Build Process
In August 2025, I presented an internal lunch and learn on streamlining email and push message builds with AI — and it wasn't a theoretical talk. It was about what I'd actually built and what the numbers looked like.
Before: a net-new email template took 60–90 minutes to build, end to end. A lot of manual work. A lot of repetitive steps. A lot of opportunities to make mistakes.
My approach was to focus on three areas that I identified as pain points:
Problem: Searching our large codebase for code. Solution: Reusable snippets. I built a custom Gemini Gem to generate an entire suite of Handlebars code snippets, which could be easily invoked during the build process and eliminated the need to waste time digging around for code.
Problem: Repetitive, manual tasks involving formatting text and working with directories. Solution: Bash Functions. I used Gemini's Coding Partner Gem to write invocable bash functions that automated the most repetitive tasks of template building, like setting up directories, formatting copy from Google Docs, and cloning existing campaigns.
Problem: Syntax errors, missed typos, and off-brand elements. Solution: Leverage an AI coding assistant. As an early adopter, I set up Cursor with custom Commands and Project Rules to act as both a coding assistant and an inline QA layer — checking for spelling errors, color parameter validity, URL formatting, and Handlebars syntax automatically as part of the build.
The result: builds that used to take an hour or more now take around 18–20 minutes. A 70% reduction. Faster turnaround for marketer requests and more capacity for the team.
Read more about the process here.
The Outcome
When I took on this work, about 10% of the marketing org was using the email development team for their template needs. By the time I left, that number was 65%.
That shift didn't happen because we pushed harder. It happened because we built something actually worth using: a clearly-defined service, a reliable request process, strong documentation, faster builds, and a team that showed up consistently and did good work.
The number I'm most proud of isn't the 70% build time reduction, or the 75 hours saved in a single quarter. It's the 65%. That's the number that tells you whether the marketing org trusted us enough to actually change how they worked.
They did.
