Part III: Correlating organization models with low value estimations
- Org models as determining factors in the value equation
- Centralized, decentralized, and distributed models
Org models as determining factors in the value equation
Gathering these perspectives from my former colleagues was insightful and informative, not only because it allowed me to reconnect with them and see the turns they had made, but also because it made me realize more about the reasons for my own career shifts toward API documentation. This layoff sent shockwaves into our careers, causing us to change directions in fundamental ways — transitioning to business analysis, becoming engagement managers, embracing API documentation, starting companies, aligning more with support, and more. But now I want to distill the reasons for the layoff and take a stab at the initial question: why are technical writers often undervalued and let go during budget crunches?
After learning about the different perspectives and stories from this layoff, here’s what I think. It doesn’t matter whether you have deep or shallow product knowledge, as no one is really looking at this and it’s assumed you have adequate knowledge to write documentation. Documentation itself is essential and important to those groups that have documentation needs. For groups that need documentation, tech writers play key roles, and few people would esteem tech writers with low value when they need documentation. Whether you hack this documentation from scratch through your own knowledge accrual, or whether you gather, curate, organize, and synthesize it from engineering interviews and other sources, I don’t think it really matters. The end result is the body of information you publish.
Where tech writers go wrong is through the centralized model. In large companies, tech writers are often grouped as a centralized resource and loaned out to different product teams as needed. For example, let’s say the company has 10 different divisions. Tech writers might be organizationally grouped in Division 1 (that is, their management chain is through Division 1), but suppose there’s not enough documentation work in Division 1 alone to justify full allocation to Division 1. As a result, Divisions 2 through 10 get to borrow tech writers for different projects as needed. Some divisions might only need tech writer services for a couple of weeks out of the year, whereas others might rely on them more heavily. This is a common model for tech comm – being allocated in a distributed way to multiple groups on an as-needed basis. (Even if the details differ, most technical writers support a handful of different groups.)
Now let’s suppose budget reduction times come along, and each division has to let go 5% of their workers. The leader for Division 1 looks at his or her resources, the high-priority projects, and cuts the tech writers because their services aren’t directly needed for Division 1’s high-priority projects. Engineers who are fully allocated to the projects need to be prioritized here, not just because engineering roles are high priority, but because cutting them would remove a resource that is fully dedicated to the project (resulting in greater impact). Divisions 2 through 10 might not even realize they’re losing their tech writers, since tech writers are loaned to them as a centralized resource outside of their budget.
If you want to increase your value and avoid being laid off, you need to align yourself with the high-priority projects within the group that funds your budget. In this case, if Division 1 doesn’t actually have enough documentation needs, you’re setting yourself up for a tenuous future. You won’t be able to justify that you are essential to this division. Further, and perhaps more visibly felt outside of budget crunch times, your sense of value to Division 1 will also be low. This is because your importance and value are diluted across all divisions. Cumulatively, your value might be high (10% valuable x 10 different divisions = 100% valuable), but in any one division that only uses your services only 10% of the year, they won’t see you as essential and important. You get a little value from a lot of different groups, but not deep value from any single group. (As an analogy, compare the scenario to the social paradox where one has many acquaintances but no close friends.)
Based on this argument, the best model for tech comm might not be as a centralized service but rather as integrated with the divisions that need documentation. When you’re integrated with teams that need documentation, you’re seen as much more valuable, and your importance to the division can be immediately felt.
Centralized, decentralized, and distributed models
Introducing the organization model into the equation is a new angle to the tech comm value discussion, and one that doesn’t have any research that I could find. However, there are many broader discussions (outside of tech comm) about different organization models and the tradeoffs of each. Three models are common:
- Centralized: Tech writers are grouped together in one central team and serve a variety of groups.
- Decentralized: Tech writers are individually embedded within different product teams and report up through those product teams.
- Distributed: A mix of the above two – tech writers are grouped softly by discipline but are embedded with different product teams in a more distributed way.
There are probably more models (e.g., a lone writer at a startup doesn’t really fit into any of these groups), but these three groupings are how most research identifies the different models. I’ll return to these groupings later in the closing survey.
The decentralized and distributed models are fine for scenarios where one division has enough doc work to occupy the full attention of a technical writer. But what about scenarios where this isn’t possible, where the only way to scrape up enough work for the technical writer is for him or her to bounce around from project to project across multiple divisions throughout the whole company (the centralized model)? This is the great crux of the tech writer value problem: in scenarios where your work is diluted across divisions, it’s nearly impossible to accrue the kind of value the role merits.
Overall, this research answered a few questions in my mind on a personal level. I think I over-indexed on API documentation out of a drive toward career stability, when in reality many groups probably value all forms of documentation — whether that documentation is deeply technical or not — based on their needs. I don’t necessarily have to accrue deep technical API knowledge to have a valuable, stable career in tech comm. I just need to align myself with the priorities of the groups that fund my salary, whatever those priorities happen to be. Understanding and aligning with executive priorities of the funding group seems like a better move than simply trying to ramp up on the latest technical knowledge, irrespective of those priorities.
About Tom Johnson
I'm an API technical writer based in the Seattle area. On this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, AI, information architecture, content strategy, writing processes, plain language, tech comm careers, and more. Check out my API documentation course if you're looking for more info about documenting APIs. Or see my posts on AI and AI course section for more on the latest in AI and tech comm.
If you're a technical writer and want to keep on top of the latest trends in the tech comm, be sure to subscribe to email updates below. You can also learn more about me or contact me. Finally, note that the opinions I express on my blog are my own points of view, not that of my employer.