Getting Others to Work for You -- The First Step Toward Scalability
During my annual performance review last week, my manager gave me a few tips to work on (as the format of the review requires). One of his suggestions was to get others to work for me. This advice (somewhat nontraditional), is something I've been mulling over for the entire week. I'm convinced that it is probably the best career advice I've ever been given. It's the first step towards scalability.
First, a little background. I confess I have a bad habit of wanting to do everything myself. I like to do things my way, because I always do it best! I always hated group work in school, and I carried this idea forward into my career. When I receive projects, I produce the content, and everyone is happy.
Not really. Here's what happens. When I take the whole world onto my shoulders, I don't have much time for anything else. My output is relatively small, given that it's the output of one person. Sure it's great (in my eyes), but it's not much.
The problem with this whole model is that it doesn't scale. The amount of content and influence I can produce remains miniscule. As a result, and based on my manager's advice, I have been looking for ways to get others working for me. Below are five ways I am trying to implement this advice.
One of my projects involves getting regular content on tech.lds.org, which is a collaborative site for community projects that features a blog, wiki, and forum. I would normally write each blog article myself, but doing that takes a lot of time. I want to publish several new articles a week. Doing so would require me to devote all my time toward the task -- while a handful of other projects get neglected. So here's what I'm doing instead:
- I'm contacting each community project leader to write an article about their project (or to assign it to their technical writer, if they have one). The project team knows the project best, after all. I give them a few questions to answer and try to keep it short.
- Knowing that not everyone will respond, and knowing that not everyone who responds will write something, I'm soliciting three new people a day to write articles. We have 30+ community projects, so there is plenty of material to cover.
- When the project teams produce an article, it will no doubt need some editing. I could apply my editorial acumen to shape and hone these articles, but why not leverage the 60+ volunteer technical writers available on a listserv I run? (I haven't done this yet, but it's a possibility.)
- Once someone has edited the article, I need to submit it through our formal review and approval processes. I could surely do this myself, but why not rely on our approval process liaison to handle it?
In essence, I am no longer the content creator. I have enlisted a team of content creators to "work for me." This frees me up to work on other tasks.
Granted, curating this content (to use a popular term) still requires effort. Sending out three emails a day takes about 20 minutes, and responding to other feedback, and lining up other editors, and so on, takes time. But none of the work is creatively exhausting, and that's a key point.
On another project I work on, I was initially planning to create a series of video tutorials to instruct users. I'm good at creating screencasts, I have the equipment, and I have the know-how to do it. So why would I enlist others to do the work for me?
It turns out that when you work for a large organization, lots of other people have skillsets comparable to your own or far exceeding your own. This is the case with my organization, where we have an impressive audiovisual department more than eager to create these screencasts (and also to translate them into 10 languages -- phew!).
I finally gave in and passed the screencasting baton to Audiovisual. Now that I relinquished control, all I need to do is draft up some outlines for the scripts. A media specialist will flesh them out into conversational narratives for the voiceover professional. Someone else will create high fidelity prototypes for the screen interface. This frees me up to do something else I've been wanting to do: reduce user frustration with other applications.
One of the interesting things about working for a large and very public organization is the amount of feedback that pours in when you put a simple "Feedback" email on a website. I try to provide documentation for several apps on this website, but I've been neglectful in monitoring and responding to the feedback. After all, isn't that a role for Support? I thought the feedback would eventually go away, but so far it hasn't.
As I was rifling through some feedback for an app, one of my colleagues (who created the initial documentation for the app) asked if I wanted his help. Bingo. I'm now setting up an automated workflow of feedback for this particular app to be sent directly to my colleague, who can tackle it himself. I'll still monitor things and check in, but I don't need to be the guy who does everything.
I noticed another group tackling responses to another app. I'll monitor their responses and glean them for answers to add to the wiki too, rather than trying filter through the feedback first.
I have yet another example of enlisting others to work for me. We have a large SharePoint infrastructure, and are just rolling out SharePoint 2010. Not many people understand how to use it. I volunteered to create a screencast last week explaining how to complete a profile and locate interesting content on a newsfeed. I liked the screencast. It took me a couple of days to produce. I was hoping that I could produce these screencasts on a weekly basis, until I started to calculate all the time it would require.
And then I remembered that on this SharePoint team, there's a guy who is a former trainer. He's already a subject matter expert on SharePoint, and he enjoys training. The only drawback is that he's busy, but it makes more sense to free up some of his time rather bring in an outsider (me) to the team. So voila, rather than producing these myself, I plan to help identify and designate a better person to do it instead.
I also have a side job at home doing WordPress consulting. By far the most popular request I get is to convert a regular website into a WordPress theme. This process is time consuming and sometimes tricky. I'm decent with CSS, but I'm more of a content person than a designer, so I learned long ago that subcontracting these projects out to an inexpensive designer in China was much more practical than doing them myself.
Now I mostly manage the projects, scoping the work, defining expectations, interacting with the customer, checking over the work, making it live, and so on. I would not be able to do a quarter of the work if I hadn't enlisted someone else to work for me.
So What Do You Do?
At this point, you may wonder exactly what I do all day. If I get everyone working for me, at some point doesn't this become somewhat of a joke? Am I sitting back, emailing people all day with requests and updates? Maybe. Theoretically, as you get more and more people working for you, you take on more of an interactive management role. It takes a lot of work to make sure the pistons in the content engine are firing properly.
And now that I have some people working for me, I have more time to focus on .... you guessed it, the strategy behind all of this content. I suddenly understand why content strategists don't produce content themselves -- because if you spend heads-down time creating content, you have little time to do the meta-content tasks that the content strategy discipline focuses on.
I confess that I do have some projects where I am still the primary content producer. It will probably stay that way, too. But I am trying to avoid that where possible, in part because I work in a non-profit organization with tons of volunteers, and also because the model simply does not scale.
Eventually, if I get good at this, I could get others working for me to manage those who are already working for me. In other words, I could add another layer of management between levels. In that theoretical world, I would no longer contact the community teams asking for articles. Instead, I would designate an intern to make these inquiries and track the progress. The intern could report on a weekly basis to me. I'm not yet to this point, and I'm not sure I want to move toward that. But you get the idea. The model scales.
Overall, I'm excited about this model. It may not be right for every organization. I'm in a bit of unique position, working for a church with a large volunteer force. But as I learn to perfect this model, I hope to magnify my output tenfold.
Now, there's one more realm where I can enlist others: my blog. Anyone interested in writing a guest post? :)
I'd Rather Be Writing Newsletter
Get new posts delivered straight to your inbox.
About Tom Johnson
I'm a technical writer based in the California San Francisco Bay area. In this blog, I write about topics related to technical communication — Swagger, agile, trends, learning, plain language, quick reference guides, tech comm careers, academics, and more. I'm interested in , API documentation, visual communication, information architecture and findability, and more. If you're a technical writer of any kind (progressional, transitioning, student), be sure to subscribe to email updates using the form above. You can learn more about me here. You can also contact me with questions.