Divya Upadhyay, friend and coordinator for MITWA News, encouraged me to sum up my typical week at work. Here’s what I came up with…
As I settle down to write this article, I realize it’s going to be hard to describe my “typical week” at work. The beauty of a week in the life of a technical communicator at my workplace is that there is no standard week. Every week is dynamic and brings with it new opportunities, challenges, and projects.
For starters, technical communicators are titled Content and Community Lead at my workplace, which implies that “conventional technical communication” forms only a fraction of our work responsibilities. The organization itself is called Community Help and Learning (CHL). Community Help is the guiding philosophy that documentation should be a curated body of content that leverages user community-created content just as seriously as it leverages conventional technical communication. As an organization, we are pretty focused on tracking how users are searching for and “consuming” the information that we create. Based on search and content-consumption patterns, we decide if a particular article in the documentation is “doing fine” or needs further improvement. This analytical engagement also empowers us to quickly identify the top issues that our customers are facing and drive those issues to closure.
Another core tenet of our organizational culture is multiplexing. While all content leads have their primary product assignments, most of us also work on additional projects and initiatives. We divide our time amongst these projects, constantly reworking our priorities. While that may sound like an awfully busy schedule to an outsider, most of us here would not have it any other way!
Here are some of the ground-level tasks I end up performing every week:
Meet colleagues: I engage regularly with my counterparts in the product engineering, customer service, and business intelligence roles. The discussions with the product engineering teams are largely centred on new features/enhancements and how to best create user assistance content around them. Discussions with the customer support organization, on the other hand, give me insight into the top issues that may require me to create troubleshooting/best practices articles or optimise already-published content. All of these interactions translate into a number of meetings through the week that we keep short and focused.
Also, since most of Adobe products are developed in an agile model, I attend a lot of product scrum meetings in addition to the CHL-level “stand up” scrum meetings every day.
Author content: For much of my working week, I plan and author content deliverables. When I author content, I strive to identify opportunities to represent concepts/procedures as graphics or instructional videos. Infographics, in particular, are an area of interest for me. Doc reviews happen in Adobe Acrobat and I work with the CHL production team to push documents live once they’re ready. Unlike the traditional doc-publishing model aligned with product milestones, we post and update content around the year.
Amplify content: I blog pretty regularly and engage users through social networks/other channels throughout the week. At one level, this engagement helps me drive customers to high-impact content. It also lets me lend a willing ear to customer issues and work with product engineering to address them.
As part of content amplification, I also moderate and post articles to the relevant content community pages—for example, http://blogs.adobe.com/cqpost.
Optimize content: Content optimization involves using Web traffic/content consumption parameters to optimize the reach/effectiveness of key documentation articles. I also keep an eye on the channels — doc landing pages, forums, community pages, etc — through which customers are reaching high-impact content and ensure that I maintain my presence there.
To optimize my content, I rely on reports from my business intelligence counterparts as well as my own research. Over the years, I’ve strived to develop specific skills in this area, including an Adobe Certified Expert certification in SiteCatalyst.
Give product feedback: Internally, technical communicators are recognised as power users of several Adobe applications and suites. Therefore, I often find myself alpha or beta-testing software. My experience helps me suggest usability improvements, workflow tweaks, or even new features that end-users like me find useful. It’s a privilege playing a part in the development of software that enables creative content creation and digital marketing initiatives all over the world.
Dream big: As an organization, we’re involved in several initiatives beyond our core responsibilities. Some of us have a keen interest in text analytics and developing new methods to further human understanding of language. To that extent, we keep preparing, writing, and publishing IP deliverables. Like many of my colleagues, I also keep working on article ideas/papers for journals and conferences.
My workday, naturally, is also governed by my personal working style. Instead of “switching off” work at a particular hour, I tend to stay connected and work late into the evening. This pattern sometimes spills into the weekend as well. I usually prioritize tasks for the week ahead on Sunday evenings. My “to do” list (often an Evernote document) is flexible and has room for the surprises that the week may have in store. I also maintain a rolling list of long-term tasks essential to my professional growth. This list may include research topics, identified areas of learning, and often an audacious feature/product idea or two. As the week progresses, I ensure that I make some progress on these long-term “to do” items, however small that progress may be.
With that, I’ve pretty much summed up the exciting, challenging time I call my workweek. It offers me a lot of opportunities and little room for inertia. And that is the part I love about it!
- Samartha Vashishtha
No comments:
Post a Comment