It may seem like there’s a new feature every time you log in to your MailChimp account. That’s not far from the truth. This is great news for users, who take advantage of these new tools to meet their business objectives. For the Technical Content team, as grows the MailChimp app, so grows the need for more documentation.
As the technical writer manager, it’s my responsibility to lead hiring and onboarding writers.
What do we look for?
We’re often asked what we look for in new hires. The ability to string together words to form a complete sentence is obviously important. But our role requires much more than strong writing chops.
My personal philosophy in hiring is that it’s more important that a candidate have well-developed soft skills than a deep portfolio. Soft skills make for a more pleasant coworker and also allow the writer to easily tap into the needs of an article’s audience and welcome any feedback that can make it better.
Here are some other things we consider.
Behind every good article is a handful of people across departments. We need writers who are clear and concise communicators in both written and verbal forms, with the readiness to advocate for the importance of well-crafted docs.
Comfort without ownership
During an article’s life, several writers will iterate on the work someone else created months or years ago. Writers need to be fulfilled by the collaborative process and proud of the work they publish, even without a byline.
Everyone communicates differently. This goes for users as well as coworkers. In our collaborative environment, it’s important that writers communicate with coworkers in a way that gives them the information they need without inadvertently causing stress. Then, they need to produce a document that educates users without overwhelming them.
Organized in chaos
Because article creation requires the input of so many people, writers often start work without all the details. It helps if technical writers often have to efficiently shift between tasks and remember to follow up on missing information.
Love for feedback
Writers need to love feedback, especially when it’s constructive criticism of their work. We have pretty rigorous standards for our articles, so it’s important to have writers who view a lot of red ink on their drafts as an opportunity to refine their skills.
We like to keep a balance of internal and external hires. Internal hires already know the application and our company culture and tone. External hires approach the application like a new user, which helps us identify areas where we’ve made assumptions. Plus, external hires are free from the status-quo bias that can prevent us from seeing better ways to do things.
What about onboarding?
It’s tough enough to choose the right candidates for your team. Once they’re in, you have to help them acclimate to your culture and process, and hope it’s a good fit.
We recently hired two writers to help keep up with the demand for documentation. It’d been a year since our last round of hires, so I knew we’d need to reevaluate our onboarding process. Here’s how I developed our plan.
Evaluate current training options
For this latest hiring round, we brought on two external hires who would need app training.
In the olden days, technical writers would either go through the multi-week support agent training or take a two-day bootcamp course designed for people whose roles don’t regularly engage with the app. Our writers tend to need something in between, with a lot of app focus but not a lot of agent training.
Given this Goldilocks situation, I decided to create my own customized plan that would hopefully be just right.
I spent a surprising amount of time writing training courses from scratch before I finally remembered the team I work on. After all, we create the knowledge base, a thing with suites of articles that are designed to empower users of all levels to become experts at the app. Why not use that to teach?
Having new writers use the knowledge base as their primary training tool allows them to 1) empathize with how a new user may self-educate, 2) get used to our style and structure, and 3) catch any typos we missed.
Define goals and needs
It probably goes without saying that to be a good technical writer is to be an expert at the app. However, the app is vast. I knew it would be foolish to think anyone could become an expert in a couple weeks.
Sure, we could dedicate more than a couple weeks to training. But the truth is, so much of any job is learned after you’re thrown into it. So it made sense that the focus of training should be to inform the writers of available resources in an applied way.
My goal was to develop a training plan that would give them the tools to recognize what they don’t know and where to go for the answers they need to be successful.
Develop, get feedback, refine
I settled on a two-week intensive onboarding process that consists of reading knowledge base articles and completing assignments. The third week is pretty loose, so the writers can work on areas they still feel a little lean on. By week four, they are integrated into the team.
I asked our current writers to review the plan, and recruited our editor to design assignments. I stepped away from the plan for several days and came back with fresh eyes to see what I missed.
All told, it took about three weeks to arrive at something I felt pretty good with.
Did it actually work? Good question—I’m asking the same one. In an upcoming post, I’ll reflect on this plan to pinpoint what went well and what we’ll do differently next time.