Getting Things Done as a Knowledge Worker

I often imagine myself greeting my tech writing students as they graduate and enter the technical communication workplace. I imagine myself saying to them, “Welcome to the professional world. You have now graduated from being a tech writing student to a knowledge worker. And the key to succeeding in this role is not writing well, or being a good team player, but knowing what work to do.”

You see, in your days as a student, you knew what work was to be done that had pre-determined success metrics. You had set courses, with defined assignments and grading rubrics. You knew if your work was finished or not, and if you met the success criteria or not.

However, in the professional world, you will not be given a well-defined assignment. Instead, you will be given a “project” – a fluid, ever-changing best-guess scenarios developed by others in the organization. The success metrics are not defined either. As David Allen puts it, “There is usually no right answers; there are choices instead”.

As a technical writer, this is the part of the job I struggled with the most. With a never-ending stream of emails and Slack messages, changing roadmaps and company priorities, I was drowning in an information overload. I couldn’t get a handle on all the things that need to be done, let alone actually doing the tasks. At a time, I was juggling three highly technical projects that each required a considerable amount of brainpower and writes and rewrites. On the brink of a breakdown, I found David Allen’s Getting Things Done: The Art of Stress-Free Productivity (affiliate link). The book has been my savior. It has led to massive increase in my productivity and helped me maintain my sanity.

The Concept of Stress-Free Productivity

Anxiety quickly builds up when we begin to think about all the tasks we have to complete each day. It’s impossible to rely on our brains to remember it all!  The Getting Things Done (GTD) strategy works on the premise of relieving our brains of the stress of remembering all that needs to be done by appropriately capturing everything in writing.

Capturing this information in what is dubbed our “external brain” allows us to be fully focused on what we’re doing in the present moment. This increases efficiency and creativity.

My GTD workflow

GTD Workflow
My GTD Workflow

Develop the 4 Vital Habits for GTD Success

Applying GTD effectively requires more than just recording your to-do list. Making the GTD system truly work for you means embracing the following essential habits: capturing/collecting, daily processing, organizing, and weekly reviewing.

Capturing: Record ideas immediately. Keep notepads in places you frequent, make use of your smartphone’s virtual assistant (such as Siri or Cortona), or create a bullet journal. This helps your brain release the pressure of having to hold on to something to try to remember it. This ultimately releases your mental space so that you can focus on the present.

Daily Processing: Schedule time at the end of each day where you review each captured item and determine if you want to carry out the idea. If you do, you then need to determine the subsequent actions that must be taken.  Actions that require extensive attention should be added to a project list.

Organizing: Actions that can be completed in 2 minutes or less should be further categorized into calendar lists, next actions lists, and follow-up lists. Calendar lists are for time-specific items. Next actions are important, but don’t need to be done within a specified time-frame. Follow-up list items are those that are dependent on additional information or actions from another individual.

Weekly Reviewing: Schedule about an hour at the end of each week to check the progress of your task completion. Reflect on where you see yourself in the next 3 to 5 years. Think about the projects and tasks that will help you accomplish that vision. Prioritize the action items that must be accomplished in the following week to make this vision real.

Reward Yourself

The GTD productivity strategy may seem like more work than you’re prepared to do. Hard work deserves a reward. Treat yourself to something you like at the end of your weekly review. The trick is that you can only effectively complete that weekly review to get the treat. Approaching your weekly review this way increases your motivation to get it done.

Bonus resource: An excellent YouTube video that discusses the GTD method:

 

 

So there you have it: the secret to my productivity and success as a technical writer. Next week, we will discuss another of my favorite productivity tools – the Pomodoro technique. Subscribe to stay tuned!

 

Day-in-the-life of a Technical Writer

In January, we discussed how to get a job in technical writing: how to search for a job, craft your resume, write a cover letter, and build your portfolio. Graduates of professional technical communicator programs tend to have a sense of ambivalence about what to expect in their new careers. Several questions flood their minds. Is the work world really like the picture my lecturers have painted it out to be? What can I expect? What should I really be looking for? This article chronicles a day in my life as a technical communicator. I hope that sharing my experiences will help you better understand what to expect when you enter the real world.

Starting the day right

Preparation for my workday begins the night before. I follow the Getting Things Done (affiliate link) method by David Allen for planning out my week and workdays (detailed blog post here). By the end of my planning session, I know the meetings I have the next day, which deliverables are due (if any), and what documentation project I need to focus on that day. I juggle several projects, so it’s important to have a focus project for each day to reduce context-switching.

I then break down the focus project into tasks I need to get done that day. Some of these tasks include: meeting people to get information, drafting, editing, reviewing and publishing.

This night-before preparation helps me start my day right. My morning routine begins with a nice, relaxing cup of coffee, cereal with oats, nuts, and apples/bananas, getting ready for work, and a half-hour commute.

Deep Work

I am lucky to work at a company that understands that every individual has different work environment and timing preferences, and encourages us to figure out a schedule that works best for us. For me, I love getting my writing tasks done in the morning even before I reach the office. Most workdays, I go to my favorite cafe at Union Square, get myself a Chai Latte, and put in an hour of Deep Work (affiliate link) (detailed blog post here). In this hour, I work on tasks that require a fresh mind and focus: drafting a technical document or studying how a piece of technology works. I time myself in Pomodoros (detailed blog post here). Once I get at least 2 Pomodoros of the most important task of the day done, I walk to my office at around 11 AM.

Maker:L,Date:2017-8-27,Ver:5,Lens:Kan03,Act:Kan02,E-ve
View from my favorite writing place in NYC (Peet’s Coffee – Cap One at Union Square)

At the Office

The first thing I do when I arrive in the office is pour myself a large glass of water and sift through emails and Slack messages. I adjust my task list based on these emails and messages, if required.

I then do some “shallow work” for an hour at noon. Shallow work includes editing something I had written before, processing GitHub issues, and publishing stuff to our Docs site.

At around 1 PM, I have lunch and check my emails and forums such as Reddit and Hackernews. All my meetings are usually post-lunch. This is the time to socialize, meet my colleagues, discuss work projects with them, get information, and so on. The 1 PM to 4 PM time slot is when my energy is the lowest in the day. So, I don’t do any writing tasks then. I leave work around 5 PM and head home for another Deep Work sprint.

Free Fridays

At Cockroach Labs, we have a thing called Free Fridays, which basically means you can do whatever you choose to do. You can continue working on your work projects, or put work is placed on the back burner and work on any personal projects, or just take the day off. I usually do my most difficult writing tasks at home on Fridays, and also get in an hour at the gym.

This is just a basic outline of my work day. Each technical writer may have a different experience. Following are some day-in-the-life blogs of other technical writers that I found interesting. I hope that sharing my routine and the routine of other technical writers gives you a clearer picture of what it is like to work in the industry:

https://heroictechwriting.com/2017/11/13/whats-a-day-in-the-life-of-a-technical-writer-really-like/

http://idratherbewriting.com/2007/12/21/could-you-please-tell-me-what-the-job-of-a-technical-writer-is-like/

http://idratherbewriting.com/2016/09/02/the-never-ending-list-of-tasks-to-complete/

https://kaiweber.wordpress.com/2011/03/28/a-day-in-a-tech-writers-life/

Now that we have discussed what a technical writing job looks like on a daily basis, let’s move on to how to succeed at a technical writing job. In my opinion, the most important skill for a technical writer is figuring out the scope of work and planning it well. And that’s what we will discuss in detail in next Wednesday’s blog post. Subscribe to stay tuned!

Everyday Tech Jargon

In January, we focused on building our tech skillset:

Now that you have familiarized yourself with the basic architecture and programming of apps and websites, you might want to scale your app, host it on a cloud platform, and deploy it on a orchestration platforms such as containers. Sounds daunting? That’s because it is.

Yet that is what deeply-technical writers do at their everyday jobs. The technologically complex products that our companies develop do not work in isolation. These products are used in an even more technologically complex environment. And to document these products well, it is imperative to understand the ecosystem they are used in. For instance, to document CockroachDB, me and my fellow technical writers at Cockroach Labs need to learn how to deploy CockroachDB on AWS, Google Cloud, Azure, and how to use orchestration technologies such as Kubernetes and Docker. And we have to evolve our knowledge in parallel with the evolving technological landscape.

This can definitely seem daunting for a beginner tech writer, and rightly so. But the important thing to remember is you can never familiarize yourself with all the technology out there – no one can. What you can do, however, is become comfortable with the technology and its ever-evolving nature. In my experience, learning how to learn is the mandatory skill for a technologically-literate writer.

To that end, let’s familiarize ourselves with the common tech jargon that forms the everyday vernacular of developers. Understanding these technical concepts will help you to communicate better with the developers and take on technically challenging documentation projects with confidence. This month’s resources will discuss:

  • How does the internet work? (Scheduled for 02/09/2018)
  • Cloud computing for beginners (What is cloud computing? Introduction to AWS and DigitalOcean) (Scheduled for 02/16/2018)
  • Containers for beginners (What are containers? Introduction to Kubernetes) (Scheduled for 02/23/2018)

HTML for absolute beginners

In the previous post, I shared a resource for Python, which is an excellent language for server-side programming. This week, I want to share a resource for the web client-side programming. This week’s resource is HTML for absolute beginners. It is an hour-long video that shows you how to build a web page from scratch. I love that it’s so hands-on and builds up from the basics of HTML programming. Check out the video here:

 

Bonus tip: Learning HTML makes it very easy to learn authoring languages such as XML and Markdown.

Why “be more technical”?

On the topic of how “technical” should technical writers need to be, the Technical Communication (TC) community is divided into two camps: Those who think it is absolutely essential to be tech-savvy to be a good technical writer, and those who think being too tech-savvy is actually a handicap for a technical writer. I belong to the camp that says being technical is a blessing for your career.

The camp you end up in depends on the product and company you work at and your end audience. If the product is a UI-based product, then yes, being technical is not a requirement. You need to explain the terminology and workflows, which does not require technological knowledge. But in today’s usability-focused world, products are getting intuitive and not needing extensive documentation. And to simplify the user-experience, the complexity is moved to the backend. With the rise of modular software architectures and plug-and-play software modules, the need to good technical writers is increasing in the developer documentation arena. Developers now don’t need to tell users how to use the products; instead, they need to tell other developers how to integrate the products with their own. And this is where, in my opinion, the lucrative opportunities for technical writers lie.

My experience so far validates my belief. Granted, my academic background is in engineering, so I am naturally inclined to the technical side of things. However, I think even if I was not an engineer, I would still have learned all things technical that I possibly could. Let me show you how “being technical” has helped me in my career so far:

I started my career as a VLSI engineer at Wipro. There, I was asked to document the Application Notes for the Integrated Circuits we were designing, and thus began my love affair with technical writing. After a year, I switched fields and moved to Symantec as a Technical Writer. At Symantec, I learned the on-the-job skills required for good technical writing. But the job wasn’t technical enough to retain my interest and the engineer in me started cribbing about it. So I moved to Druva as the Engineering Technical Writer and this proved to be the inflection point in my career. At Druva, I documented the software architecture and design of our products for internal developers. I reported to the VP of Engineering and worked closely with the CTO and the developers. The documents I created helped developers understand the overall architecture of the product, know what their colleagues were working on, learn what design decisions were made and why, and helped them better collaborate with their peers. Also, they were relieved that they didn’t have to write the design docs anymore. At most, they would have to write a rough draft and I would take it from there. As a result, I became a valued and highly visible member of the Engineering team. The position opened up several growth avenues for me, one of which led me to the MS in Technical Communication program at Missouri S&T. My work helped me develop an amazing rapport with our CTO – he offered me a summer internship in the California office, which was later extended to a remote part-time internship that lasted throughout my second year at Missouri S&T.

In the last semester of my grad program, I started looking for jobs. I didn’t want to go back to California. This time, my heart was set on New York. As an international student, I knew I would have to prove my worth for a company to take a chance on me. And the way to do that was to build my portfolio. So I researched open source projects where I could contribute documentation and build my portfolio. I came across an interesting project – CourseWorld – and started contributing software design docs to the project. This project helped me demonstrate not only my ability to understand and document technology, but also my knowledge of GitHub and online collaboration tools. In short, it helped me “show, don’t tell”. And it worked! I got interview calls from exciting startups for deeply technical positions. One of the calls that got me super-excited was from Cockroach Labs. After an intense interviewing day, I was hired as a Senior Technical Writer at the New York office and offered a six-figure salary. So you can see why I am biased to being more technical 🙂

Being technical has helped me leap through my career. It has opened up avenues of career growth that I didn’t know existed. And honestly, it’s just fun to dive into the inner workings of a product and understand how the magic happens.

Update: I made a video to discuss how tech writers can work on becoming more tech-savvy. Check it out:

If you have questions, suggestions, or blog post requests, drop me a line at hello@amrutaranade.com

Subscribe to follow this blog via email