I used to have the power to email over 250,000 people at my fingertips. We weren’t spammers; far from it: we were publishing a successful newsletter to all those subscribers, and had quite a few who were actually paying for a premium-level product.
But that broadcasting process was nerve-wracking. Our specialized email broadcast utility (you can’t just email 250K people with Outlook) had 4 little checkboxes that you had to click, one at a time, before hitting the big “send this message†button, just to make sure that you were serious. That you had done your double-checking.
I hated it.
Not the checkboxes, or the fact that we were broadcasting to a quarter of a million people. I hated that there were so many manual steps.
I’d get the newsletter in Word format, at which point I’d copy-paste it into a text editor. I’d change headings into ALL CAPS, replace horizontal lines with exactly 68 “-” characters (we determined that 68 characters was the maximum number that wouldn’t wrap on most email clients of the time), and make sure that paragraphs had a space between them.
And then, after the email blast, we’d post the newsletter on our site. That involved turning the headings into anchors, adding a table of contents to the top (with functional links), and basically wrapping every paragraph in a <p> tag.
It was always the same sort of thing: a header, a footer. 7 to 12 sections, with multiple paragraphs of content. So I resolved to build a semi-automated system to streamline the process.
It was another simple sort of web application, with a dropdown menu to ask how many sections there would be, then some text areas to copy the content of each section into place. The code added the appropriate spacing, headings, table of contents and anything else necessary, then displayed a “test” and “broadcast” option: the “test” option sent the message to a selected number of editors so they could preview the output. Then, when they were ready, they could send the content to one of a number of pre-selected mailing lists. And, the program displayed HTML output that could be copy-pasted into our existing content management system, once the email broadcast was out.
The biggest mistake I made with this project was not recording the time/error savings. Anecdotally, I can say that I was able to leave work much earlier on days we did broadcasts, as the editorial team was able to use the new tool without my help. I don’t know for sure that we really reduced the number of mistakes…but quality control was now completely in the hands of the writers.
And that was the first lesson: quantify changes, and do it right away. In this case, there wasn’t anybody on my case to justify the results, but I also wasn’t able to easily show to management that my new system had a real impact. It would have been trivial, at the time, to go through my email and generate some sort of graph illustrating the error rate before and after the new system. But now, years (and jobs) later, forget finding good data.
The second lesson has to do with how much automation I did. My system didn’t integrate nearly as much as it might have: the content that came out of it actually interfaced with the existing email broadcasting system as if it were just a computer-controlled copy-paste. The mailing lists pulled from an external database. The generated HTML was temporary; I don’t believe it even created so much as a text file, instead of some copy-paste-ready text in a textbox. And that text had to be pasted into the existing content management system.
But that was ok. I knew the team, and I understood the importance of delegation: I gave them the tools to be able to perform the technical tasks I usually performed, and reaped the rewards. I saved myself valuable time, and I instantiated a far more reliable proxy than myself—a proxy who couldn’t make accidental mistakes.