Reflecting seven years later about why we were laid off (Part VI)
Reaching some conclusions
After 11,000 words, am I closer to reaching a conclusion about this topic? How can we reverse the low value of tech writers in organizations and eliminate any chances of layoffs? Was Mark Baker correct in his belief that companies value employees with deep specialist knowledge over more expendable plug-and-play type workers?
As I’ve argued, I don’t think managers assess whether their employees have deep product knowledge or more general knowledge as they consider layoffs. But I have argued that if you can limit your focus on projects and engage on a more focused, in-depth level, your value will be much more apparent and recognized. So, in the end, deep accrual of knowledge on fewer projects is actually the best approach for reversing low value estimations for technical writers.
Three key takeaways
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
This task first requires you to identify which projects are strategic. You might not be able to say no to the non-strategic projects, but that doesn’t mean you have to write all their docs. I constantly shift between playing an author, editor, or publisher role on projects. For important projects, I play an author role. For less important projects, I just play an editor or publisher role, with varying degrees of engagement. (For some projects, I just onboard them onto our toolset and let them publish in a completely autonomous way.) With this model, there’s a risk that others will read the potentially poor documentation written by these teams and assume it’s the work of the tech comm team, but that unawareness can be mitigated through bylines and notes in the email blasts I previously mentioned. I also think it’s feasible to establish developer portal standards, templates, style guides, and other requirements, and then hold teams accountable to follow them.
2. Engage deeply on 1-2 projects only.
After identifying the strategic projects where you plan to devote your main authoring time, find ways to be proactive on a deeper level. Avoid being the reactive writer who only waits for requests to be filed. Consume the product information like a hungry researcher, and as you ramp up your expertise, let yourself naturally speak out to product weak points, roadmap strategies, and higher-level product strategies. Don’t be an invisible fly on the wall, nor tie your hands around a writing pencil only. Allow for the blurring of roles the deeper you engage, and recognize that more thorough knowledge will pay dividends on the writing front as well. It’s much easier to write when you already have the needed knowledge.
3. Cultivate internal awareness and C-level sponsors.
Share your work with others in your organization so they not only know what you do, but also so they know who you are. Send out regular email blasts to internal stakeholders that list out the documentation updates. Not only the updates, but elaborate every now and then on feedback from users, trending metrics, and other insights and discussion. Sending these emails over a prolonged period of time can gradually influence others in your organization to be documentation sponsors.
Short survey to capture your feedback
As with many posts I write, I’m interested to hear your feedback and to understand whether the points I’m making resonate with your experiences. This time, I’m curious to know if there are any legitimate patterns between organizational models (centralized, decentralized, or distributed) and feelings of low/high value, or layoffs. To this end I have a short survey below (which includes branching logic). You can view the ongoing responses here.
