These past few months, we’ve published a few posts about 18F’s Writing Lab — what it is, the documentation we’ve created for it, and how a lab can benefit your organization. Today, we’ll be concluding our four-part miniseries by discussing practical steps you can take to start your own lab.
It’s worth noting that, although most folks can fairly easily start their own labs, the process of getting one off the ground will take some time and effort. Don’t panic! If you’re feeling overwhelmed, take another look at the posts we’ve published and peruse our Writing Lab guide — these resources have all the information you need to spin up your own lab.
On that note, here are the steps to take to start your lab from scratch.
Determine user need
Before you dive into planning, ask yourself a very important question: How could my organization benefit from a writing lab? If you have adequate resources to accomplish all the content-related tasks that need doing, you might not need a lab, regardless of how excited you are to start one. (That said, most teams could benefit from a little extra editorial and content help. If you’re one of the rare birds that has every project and task under control, we commend you.)
To best help your coworkers, you’ll need to figure out what kind of writing and editing help they need most; doing this will allow you to solve their biggest pain points. For this reason, we recommend doing a bit of user research to determine what sorts of services your lab should offer.
Not a full-time user researcher? Not to worry — your research doesn’t need to be super formal to be effective. As we were planning for our Lab, we sent our colleagues a short survey asking what types of help they’d most prefer, and we used the survey results to determine our services offerings (more on that in just a minute).
Round up your team
Once you’ve figured out what kind of help your coworkers need, you can recruit fellow lab editors: the folks who will be doing the writing and editorial heavy lifting. The size of your core team of editors will depend on folks’ availability and interest, among other things. When it comes right down to it, there’s no one right number of editors to recruit. That said, here are some tips for forming the strongest core team you can:
-
Find folks with bandwidth: If people have absolutely no time to spend on additional projects, they’re not great candidates for lab editors.
-
Find folks who are excited: Because labs are self-governing organizations (and because lab editors oversee their own progress), it’s critical that you recruit folks who are self-motivated and enthusiastic.
-
Get approval from leadership: Make sure all your editors have leadership’s approval to take on lab work. Getting your leadership team on board with the lab will help all participants feel empowered to do their work.
Though there’s no one “right” number of core team members to start out with, it’s not a bad idea to have at least three editors when your lab launches (and if you have more than that, high five!). This way, if someone is out sick or swamped with other work, someone else can pick up the slack.
Along similar lines, it’s always better to be overstaffed than understaffed. If you’re overstaffed, editors can dedicate lab time to other tasks: writing internal lab documentation, for example, or working ahead on other projects. If you’re understaffed — especially right when you launch — you have a greater likelihood of providing a disappointing experience to your clients and establishing yourself as an unreliable (or unhelpful) group.
Plan what services you’ll offer
After you’ve assembled your core team, you can decide what type of services you’ll offer your clients. Our recommendation is to always prioritize user need, which will help you create a better customer experience by solving the problems people actually have (rather than the ones you think they might have).
As excited as you are to get started, be realistic about the help your lab will be able to offer. It’s a solid plan to identify your top two or three user needs and address those first; you can always expand your service offerings later. What’s more, it’s much nicer — for you and your clients — to scale up gradually than it is to hastily remove offerings from your service menu.
Another way to ensure a great client experience is to offer help at tasks that your lab editors are great at. This isn’t to say that you can’t offer to help with things that aren’t squarely in your wheelhouse, but from a quality (and efficiency) standpoint, it makes the most sense to offer assistance with the sorts of tasks that your core team excels at.
Create a framework for participation
The means by which your coworkers can get help from your lab — in other words, the participation framework — should reflect your team’s unique needs and preferences. Our Lab at 18F uses a GitHub repository and a Slack channel for all of our project intake. Most folks on our team are comfortable using GitHub, and the majority of our project requests come in as GitHub issues. But some folks aren’t as comfortable with GitHub, which is why we offer the Slack option.
As you’re thinking about how to structure lab project intake, think about your colleagues’ needs and preferences. Are they more technical or less technical? What are their communication preferences? What tools do they already use? The answers to these questions will help you identify the most effective participation framework.
Announce and launch
Now that you’ve created your participation framework, it’s time for a very important step: announcing and launching your lab! It might seem like kind of a no-brainer, but in order to attract internal clients, you’re going to need to promote your lab. (When you spend a decent amount of time getting something like this off the ground, it’s easy to forget that not everyone is as enthusiastic about the project as you are, if only because they’re not aware of the work you’ve done.)
Be sure to reach out to people through the communication channels they prefer; if your team loves email but not in-person meetings, promote your lab via email. If your team loves Slack, use Slack. Have promotional materials prepared prior to launch, and pre-anticipate your colleagues’ questions so you can generate thoughtful answers.
Find ways to improve
The feedback we need to improve is generally right in front of us; as long as we find ways to talk to users, we’ll be able to collect the feedback we need to make the lab better. Even if your lab seems to be humming along, take the time to talk to your users (in other words, your coworkers) to see how you can make the lab even better. Whether you conduct formal interviews or gather this information through casual conversations is up to you — what matters is that you maintain an open dialogue with your team so you can always have a sense of how well you’re meeting their needs.
Keep in mind, too, that the updates you make to your lab don’t always need to be massive. In fact, the smallest changes can sometimes be the most effective. For example, when we launched our Lab, we didn’t have a formalized system for clients to let us know how long their tasks would take. Some clients included this information in their requests, but others didn’t, and this lack of standardization made it tough for Lab editors to choose tasks that fit their schedules. Taking note of this problem, we eventually added time labels to our GitHub repo. Now, clients select the time label that best matches their task, and we editors can more easily choose tasks that fit our schedules. Small change, huge gain in efficiency.
Keep in touch
We hope you’ll refer to this post (and our previous ones) as you get your own lab off the ground. Once your lab is up and running, drop us a line: We’d love to hear about your experiences (including which of these strategies worked well for you, and which didn’t), and we’d likewise love to get tips and tricks from you!