A day in the life of a Technical Writer
Technical writers don't just solve complex problems, they churn information that sounds like a layman's second language. Even a tech topic gets simple to read when infused with the freedom of expression, intention, value, individuality, and a dash of creativity.
How I got started… and where am I now with Technical Writing
My love for technology, exploring how things work, and trying out new gadgets have always intrigued me. Moreover, my previous experience as a digital content strategist was helpful in getting me a break in tech writing at BETSOL.
What I feel is that it was my passion for technology and writing that opened the right professional doors at BETSOL. Or rather, I should say what fast-tracked me landing into this job was the hybrid nature of experience coupled with the passion, that was recognized here. I realized - no matter what your previous job title was, the right skill sets followed by determination and passion always tick!
My key responsibilities as a Technical Writer
What I actually do, varies with the nature of the project. Some of the responsibilities that I handle at BETSOL span across how-to guides, instructional manuals, technical documentation, and knowledge base, or similar educational documents.
Apart from developing articles and blogs, I am also involved in the whole development process from the very outset to create documentation on an ongoing basis.
The technical writer is the mediator between the end-users and the business. While authoring IT documents, manuals, blogs, and knowledge base materials, it totally makes sense to first understand the technology, software, or hardware, comprehend and then conceptualize to successfully complete the project. I believe that it's the skills and not education that is pivotal. If you know how to translate an informative piece into layman's terms, you hit the bullseye. It's the art of translating an experience for the users that impacts the most.
How can I miss out on some of the exciting perks of working as a technical writer?
Ah, the exciting perks of developing documentation and articles
My work process is pretty agile, say, built around two-week cycles. What keeps me motivated are the interesting projects for a plethora of products. No two projects are ever alike. Each day brings along a fresh set of new challenges offering a bounty of exciting opportunities to use new tools and bring fresh perspectives to the table.
What I enjoy the most is the unlimited freedom and opportunity to shuffle between the "just the facts" approach for the product documentation or the storytelling, problem-solving, or marketing approach (feature-related) for the blog. Regardless of the approach, the key is to enjoy making the reader feel smart through the writing.
Alongside, I get plenty of opportunities to interact with multiple software development teams, multiple departments, and diverse personnel such as SMEs, developers, designers, programmers, etc. - Sometimes a part of me feels like a journalist and at times- an investigative reporter!
You will have the opportunity to try out everything.
A sneak peek into my life
A WFH day looks casual and relaxed as I don't need to be on the clock at the office, and I have all the luxury with a WFH outfit. (At my home office, no one's watching; so no pesky inhibitions of dressing up nicely) Jokes apart. This is how I start my day with a nice, relaxing cup of tea
(11:00 AM - 11: 15 AM ) - Regular Calendar and email check while sipping a steaming cup of tea
My day usually starts with a sneak-peek into the regular calendar, emails, and the Jira tickets. It gives me a glimpse of the meetings scheduled for the day, the KTs (knowledge transfer training) on technological product updates that I need to follow through, my major dependencies for the blog requests, and upcoming feature-related articles that I need to plan for the day.
I receive most of the emails from the Senior Director of product marketing and the Team lead that assigns various documentation requests or product feature-related articles (if any) that I need to cover.
(11:30 AM - 12:15 PM) - Daily stand-ups with the Manager
Once I filter the most important task of the day to be done, it becomes time for me to share share the updates in our team meetings. Each meeting typically lasts for 15 minutes. It starts with the task list broken down into sub-tasks to be accomplished throughout the day, figuring out the major roadblocks and how each team member can help to make the day more productive. (I thank my lucky stars to have some of the amazing coworkers that make WFH rather enjoyable!).
(12:15 PM - 1:30 PM) - Attending documentation meeting on Microsoft Teams
A major task entails gathering inputs from the subject-matter expert (SME) or troubleshoot any roadblock that I may encounter. SME's are the techies who dream of code. So, whether it's dumb questions while extracting information or admitting 'not getting it'- whatever technique works to get the output.
(1:30 PM - 2:30 PM ) - Lunch break
Home-cooked food with family to share a happy meal: A major stress buster for my day!
(2:30 PM - 4:15 PM ) - Research, research, & research
Documentation for engineers is highly technical, and that's the way it is! And it's okay if someone spots me thinking on my feet under pressure. Before I start writing, I prefer independent research, finding the right pieces of information, and then fitting them together for the users. The target audience comprises Engineers and IT admins, which means no-nonsense for technical documentation.
(4:15 PM - 4:30 PM ) - Virtual tea break with an office buddy
Tada! that's my daily dose out of the mundane shift to feel connected. Catching up with my colleagues over a video to chit-chat and talk about things other than work makes my day brighter.
(4:30 PM - 6:00 PM) - Starting to build the first draft of documentation
I've done technical writing for internal teams, and external customer bases so far. While working for long-standing documentation, I realized that whoever the target audience is (end-users, programmers, or stakeholders), what matters is to make the information clear, searchable, and helpful for them.
I act by the mantra of simplifying the concept and sentence structure such that anyone can pick that up! And to accomplish that, I need to play multiple roles - part mind-reader, listener, translator, writer, editor, and possibly adept at SEO or XML.
(6:00 PM - 6:30 PM) - Conducting peer review
For any documentation, instructional manual, blog, or manuscript, conducting inspections in the form of peer reviews is an important step. The goal is to discover the blind spots that I might have missed. My peer reviewer (who acts as a dummy end-user) hones my skills by spotting the functional errors and optimize readability that often goes unnoticed.
(Post-6:30 PM) - Saying sayonara to work and a hello to family
Once when I'm done checking the follow-through emails on how my next day's meeting schedules look like and responding to the messages, I finally call it a day (well, night).
Luckily, evening work and meetings are rare for me, so I can get some time with the family and be rested and ready for the next day.
One of the many things I love about working for BETSOL is that they recognize the hard work we put in during the day, and in turn respect evenings and weekends as our own time. It's one of the many reasons I love working here and makes me excited to log back in in the morning.
Ready to explore a career at BETSOL?