I read this essay by Tom Johnson recently. He was laid off about seven years back. Now after seven years, he reminiscences on the various factors that led to the layoff in a six-part essay. He had spoken to a few former colleagues on what they had been doing after that incident.

His essay makes an interesting read with several good nuggets of information that is very useful regardless of which stage of their career they’re in now.

Disclaimer: Till date, I have not experienced a layoff in my career. So my thoughts here are from inexperience but also from my experience. This is also a lesson to my future self.

I agree to some of the points he makes about providing value by not only looking at oneself as the person who writes documents. So I made a few key highlights from his essay and added my thoughts to it.

In the comments, Mark Baker took another point of view about the reasons for low value. He said the value of tech writers in companies is low because of the way tech writers pitch themselves to others. When technical writers argue that they can quickly learn what they need to know, they’re ironically describing how expendable they are, not how critical they are. One tech writer can be let go and another can be hired and quickly come up to speed and write the necessary documentation. When companies consider who to lay off, these ideas about quickly ramping up play into the assessment of who to let go. Companies choose instead to keep those resources that require long on-ramp and deep knowledge accrual. —via Part I: Introduction and background

If ever someone asked me if I was a quick learner, I would answer Yes in a heartbeat, Heck, I pride myself on being able to hit the ground running. This observation about writers saying they are quick learners and can start contributing is also something I would say and also most writers would say too. Unfortunately, the above quote somehow felt a bit true to me. And thinking about it, I see how damaging it is.

I also agree that the point about being seen as non-essential would be something that raises a writer’s hackles. But it is true. It is part of a writer’s life and you have to understand and accept that part and move on.

Technical writers need to identify what the high priority projects are for their group and align themselves with these projects in deeply integrated ways with these priorities. It makes no sense to focus on low-priority projects. —via Part II: Personal layoff stories and reasons

This is a major item that we tend to lose sight of. We put our heads down and look at only our product/project and never wonder why or what is the rest of the company doing. But one has to be wise about this.

I’ve seen people want their hands on every pie that there is and implode at it. I too plead guilty to this. There are several instances when you feel that this particular project is your calling and you go all out to be on that. And some time later, you realize that this doesn’t really suit you and you’re left with a white elephant.

That’s where your understanding on the organisation’s priorities and your own capabilities come into play. If you can work within your strengths and also ensure those strengths match the organisation’s priorities, it helps a lot. Too much effort on low priority tasks wind up dangerous.

I think very few people know how to measure the impact of good or bad writing, mainly because they don’t have the skills to recognize it. Also, the costs are hidden – for instance, no one (that I’m aware of) measures the impact to business when someone makes a mistake because a user manual was written poorly or is out of date.

The cost analysis rarely includes support costs that could have been prevented through documentation, or any understanding of what support costs would be without documentation. When the topic of metrics comes up, I often joke that if we really want to see the value of docs, we just need to take them offline for a week, but the only time we actually do this is when a server goes down. —via Part II: Personal layoff stories and reasons

I had been advocating this - Pull the docs offline and see if anyone notices. If no one does, well you have an answer. I remember a few months back when we had to do a server change at the back-end. Most of us had to spend days just replying to customers who could not find their trusty old manual where it was supposed to be. I think I spent most of a week identifying what they were looking for and mailing them the files while the server was replaced.

But the truth is most people do not know how to measure the worth of documentation to a business. It is hard to quantify that and say ‘Well, our docs makes up 5% of our yearly profits."

We end up being perceived as documentation writers only, not as a more valuable role that would influence product design and improve the developer experience. This happens regularly — some teams ask for my feedback, but since I’ve only engaged cursorily with the product and users, I don’t have any deep value to add, and so I feel like it’s assumed that I am not capable of adding value in the first place. —via Part IV: Engaging deep enough to blur the lines between content and product design

In most cases the above fact is true. The sooner you understand it, the sooner you get to move on to other things like engaging with the product and team more. As John G. Miller suggests in The Question Behind the Question,

  • What can I (as a writer) do about it?
  • How can I improve this perception?

writing documentation leads to developing product knowledge at a deep level, with unique insights from users. That knowledge has many applications beyond simply writing documentation. It can influence product design. To write really good docs, you have to accrue specialist knowledge. And when you have specialist-level knowledge about a product, you can play many more roles beyond documentation. In fact, it’s a waste of your expertise if you don’t leave the documentation page and engage in other dimensions of product development. —via Part IV: Engaging deep enough to blur the lines between content and product design | I’d Rather Be Writing

There are areas at work where you can be the specialist and there are those where you have to be a generalist. Understanding what and why you are doing would require a generalist thinking whereas how to do it could be your specialist role. The balance between the roles is key to ensuring that you obtain knowledge.

You stay in the shadows. You don’t ever communicate with anybody. You come to work, you go stay in your cubbyhole, you do your work, and nobody knows you. Nobody knows you. If nobody knows you, you’re not going to be very successful. To get to the mountaintop, and to know that you’ll always be working at a job, somebody’s got to know you. Don’t ever let anybody say that “Hey, I don’t even know what Darnell Xavier does.” Don’t ever do that. You have to let yourself be known. Get out of the shadows and into the sun. Get into the light, and let people see what you are doing each and every time. When you are in a meeting, don’t sit in the corner or the back. Get to the front of the table, get to the table. And when you have a question, you let it be known that you ask questions. via Part V: On being strategic, interpersonal, and sponsored

This hold true for most technical writing professionals. Heads-down and get the job done. This entire section is very insightful especially the points why you are liable to be laid-off. If people know who you are and your name in your organisation even if you do know their name, I think you are partly there.

Writing is not so much about heads-down writing. A huge component of writing is gathering information from various people, identifying the people who have the information, tracking them down, pulling this information from them through meetings and other interactions. And then pushing them through the review process, and so on. Technical writers are more like investigative journalists. —via Part V: On being strategic, interpersonal, and sponsored

This particular quote is what I really love about my job. The constant quest for information and synthesizing them into something useful is an alchemical process and something that stimulates me.

I don’t have all the answers, and these posts are almost notes for myself more than any formalized knowledge. But here are a few key takeaways:

  1. Prioritize those projects that are strategic.
  2. Engage deeply on 1-2 projects only.
  3. Cultivate internal awareness and C-level sponsors.

—via Part VI: Conclusion, analysis, and feedback

These three points are super-valid. I’m looking forward to trying to see how I can find ways to apply this key points right away.

As I read this essay, I thought about things I can do better now at my job and I also know now what to say when people ask for advice.