Part VI: Results from the survey correlating org models and tech writer value

by Tom Johnson on Jul 26, 2020
categories: technical-writing

• Who took the survey
• Survey responses
• Favorite quotes
• Analyzing survey data
• Trending highlights
• Revisiting the Takeaways

Who took the survey

You can browse the results of the survey here. 99 people started the survey, and 49 people completed it. 50 dropped out along the way, but the survey accepted partial responses. Respondents were from all over the world: 47% US, 7% Germany, 7% Austria, 6% Canada, 4% Great Britain, 4% Sweden, and 4% India.

49 to 99 people isn’t a large number of respondents. However, I allowed for a lot of freeform answers, and if you’ve ever tried to make sense of freeform answers from 50-100 people, you know it’s a lot of work. Also, small sizes are often enough to gather a general trend, and these initial responses could always be used for a follow-up survey that is more informed and which has more precise multiple choice options.

Respondents spent an average of 14 minutes completing the survey. Also, presumably they read the post series prior to taking the survey. Given the length of the post series (approximately 11,000 words), respondents probably spent at least 20 minutes reading, which is an indicator of their interest in the topic.

I didn’t collect details about companies, sectors, age, gender, years of experience, etc. The survey was meant only to be an informal survey to see if there was any support for a correlation between org models and tech writer value.

Also, I used branching in the survey, so if someone indicated that they were never laid off, I didn’t ask them why they think they were laid off, and so on.

In the following sections, I’ll highlight the survey responses and provide some analyses. Note that with freeform responses, I identified key themes in responses and counted up their instances. Some people gave more than one reason. Because of that, the number of reasons won’t correlate with the number of responses. Also, some people were laid off multiple times at different companies, and they explained differing reasons for each scenario. Finally, I had to interpret their responses into general categories. Again, you can browse the survey results (including all the freeform answers) here.

Survey responses

Favorite quotes

Here are some of my favorite quotes from the respondents:

The centralized model is the more dangerous one for visibility of technical writers and their work. It’s great for creating standards, processes, and consistency. However, technical writers can get too enmeshed in writing styles and nitty gritty with an overemphasis on consistency that conflicts with the main product deliverable priorities. This leads to the product team losing confidence on technical writers delivering accurate documentation on time.

There should be a company-wide identity as the Tech Comm Community. Even if the writers are organized into small, product-specific groups with different reporting chains, someone needs to create a space where the writers can talk with each other, share common tools and Style Guides, etc.

I believe that when push comes to shove as it always does, the company needs to downsize and tech writers are perfect if you keep them dumb enough.

if the workload and team are structured properly, then everyone’s happy, creative, engaged, fulfilled. if not, then it’s catch as catch can, fly by the seat of your pants, hair on fire – not all the time, but at crunch time. not ideal way to work, but some people do shine in these moments. it’s killer for your health, though, and your body goes to pot. i used to be a little addicted to the crazy, but now i have the opposite problem – i take on loads of work and then pfffft don’t really care. no one notices it yet, but i’m beyond burn out.

See my long answer in a previous question. Centralized tech comm organization just excludes us from the mixed role dev team and makes us invisible/left behind. They do not deem us a team member and wouldn’t think of us unless they have a specific documentation request. Bad tech comm management makes things even worse.

Yes. I’ve worked in centralized and decentralized models, the former where the tech writers all sat together and reported to a tech comms manager, and the latter where we sat with the development teams and reported up through them. Currently I’m in a hybrid model, which seems the most effective of all my experiences. We report up to a single tech comms manager in a department that provides all types of support to engineering (in a hardware and software environment). But tech writers are assigned to a single business team that works on a single product line, and we sit part of the week with that team and part of the week with our fellow writers. Our assignments to business teams last years. This model keeps the tech comms function strong–style guides, standards, doc policies, tool support, etc.–while providing high value to the business teams we embed with.

I think you need the role to be centralized in terms of org structure but embedded in teams (about 1-3; depending on size and complexity of assignments) to gain the best of both worlds. Centralized tech writing groups enable interdisciplinary support while farming out the writer’s services to a couple teams enables maximization of value per writer, broader support throughout the org, but also not too broad so that the writer can gain some product knowledge and to some degree specialize. Any more than three projects and you’re breeding generalists.

If tech comm is embedded in a project team, the work is more likely to be viewed as an essential part of the product, rather than as a last-minute nice-to-have add-on. We need to be considered part of the product development team.

I think it is far better to embed a writer on a product team. Not only do I add more value, but I enjoy the work a lot more.

Analyzing survey data

First of all, I now understand a bit more about what academics mean by double-blind coding. Freeform answers are awesome but require a lot more interpretive work. I’m guessing that if someone else were to make sense of these same freeform answers, the results would probably vary. I didn’t agonize over this task. If someone wants to check my interpretive work there, I wouldn’t mind.

I also realized that making sense of any survey data is challenging and requires more effort. But unless I look closely and try to interpret responses, what’s really the point of creating the survey in the first place?

Trending highlights

Now for the higher-level analysis and extrapolation. Based on the responses, I don’t think there’s any clear correlation between an org model and the tech writer’s sense of value/importance. Org models are probably more nuanced than the three buckets I described (centralized, distributed, decentralized). That said, 48% of people disagreed that the org model has no impact, so the org model does have an influence, but it seems people felt other factors are more important (e.g., appropriate allocation of projects, executive sponsorship, integration with teams, alignment with strategic priorities, specialization with products, etc).

Most writers feel that a distributed model (hybrid) is best. Sit with the engineering teams, but find a larger tech writer community within the company. Centralized tech comm teams might benefit from increased consistency and more formal writing standards, but they take a hit with visibility and rapport with engineering teams. By not being co-located with engineering teams, these centralized tech writers are less known, less visible, less integrated, less kept in the loop, less understood, etc. The resulting docs often show this. The benefits you gain from co-locating with product teams outweigh the benefits you gain from co-locating with other tech writers. And users care more about content than commas.

Further, if you can embed with engineering teams, you’re less likely to be diluted across too many projects and “kept dumb,” as one commenter put it. When you support 6-10 projects, it’s inevitable that you’ll lean towards being a generalist. And as a generalist, you likely won’t provide the level of insightful input, feedback, commentary, correction, or other intelligence that might increase your value to those teams.

When you become a product SME, teams are much more likely to value you. And your docs are more likely to become high-quality docs with visible customer impact. You’ll be gathering more valuable information that results in a much influential result. Tech writers only have as much value as the documentation they provide, so the more valuable documentation you can gather and communicate, the more valuable you become. It’s as simple as that.

With higher doc quality, internal teams will see your output and esteem you with higher respect and importance. Customers will express their appreciation for the docs. Sales will use your docs in pre-sales scenarios, which will make you more valuable. But if your only contribution to the project is to fix the style, your value will be much lower (especially if others don’t even understand the style adjustments you’re making).

One trend you especially want to avoid is the downward cycle of poor documentation and under-resourcing. If the docs lack value because they are poor, this can lead to less staffing/prioritization for the documentation team, which leads to even poorer docs. In other words, docs aren’t important because they’re poor, so no effort/priority is given to docs, which makes them even poorer.

Given how crucial it is to go deep with a limited number of projects and to increase visibility with project teams, I’m a little perplexed why there isn’t a stronger correlation with tech writer value and the distributed/hybrid model. It could be that this term was fuzzy or didn’t describe the respondents’ org structures, or maybe respondents didn’t have that many experiences with differing structures to really draw a conclusion. Many felt that an organization’s culture, leadership, and other factors outweighed the specific model.

But this attitude is also encouraging, because you can’t always change your organizational model. If you’re stuck in a centralized system, it’s not as if all is lost. You can still ratchet up your value by diving deep with the products you document, attending as many product meetings as you can, and generally inserting yourself into the product team — if you have the time.

In fact, given our current pandemic times, it’s easy to co-locate with teams — co-location just means attending meetings with teams online, more or less, so you can co-locate with whomever you want now, as long you can get invited to the meetings.

Further, virtually attending meetings lets you more easily tune out those meetings where the signal-to-noise ratio is low (e.g., some engineering standups where engineers prattle on about issues that seem irrelevant). You can give the meeting your partial attention to avoid those situations where you feel like you’re wasting your time.

Attending meetings, ramping up on products, tracking down and interviewing engineers, and integrating yourself and energy into projects, etc., takes time. This is likely challenging if you have many projects. I still don’t know how to reduce project loads. It’s difficult to tell teams “no.” (Saying no can create more work than actually creating the documentation itself, I’ve found.) My current strategy is to adjust my level of effort with the team, choosing between playing a role as an author, editor, or publisher in varying degrees based on whether the project is a strategic priority. The problem is that if I just play a role as an editor/publisher, I want to avoid the assumption that I was also the author, especially if the content is sub-standard. Sometimes after making a light edit on non-strategic docs, I’ve heard PMs say that “Tom has reviewed and endorsed the docs,” when I would hardly consider that to be the case.

There are a lot of survey responses about executive sponsorship being essential. While I agree, I also think that executive sponsorship is a result of other factors. If your docs have high quality, executive sponsorship will likely follow. For example, suppose business development teams are able to secure important business deals because the documentation is so easy to follow. You’ll have earned a champion at the senior level.

I’m not sure that senior leaders harbor prejudices for or against docs regardless of the doc quality, though maybe it’s true. Maybe they’ve built up years of experiences with docs and will see them as unimportant and of little value no matter how outstanding of a job you do. I’m inclined to think that with enough good customer feedback and internal stakeholder support, a senior champion at the C-suite level can be cultivated (eventually). The problem is how to communicate upwards to influence the C-suite, since they’re usually in larger business conversations and not in the weeds of documentation.

Revisiting the Takeaways

In the previous section, Part VI: Conclusion, analysis, and feedback, I noted three takeaways:

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

How does the survey data change or influence these earlier takeaways? Previously, I was leaning towards a correlation with organization models and value. But the responses to this survey encouraged me to rethink the relevance of the org model. The distributed model seems best, but no matter how your company draws the org lines (whether centralized, distributed, de-centralized, or a combination of these), I think clever tech writers who follow these three principles will find success.

The last bullet (cultivating sponsorship) is one that I haven’t expanded much on, but it’s something I’ve been thinking about. The great irony of my career is to be influential outside of work through this blog and other activities, but to be relatively invisible inside my company, especially to business leaders and others. I can connect with other tech writers, so why can’t I connect with business leaders and cultivate an influence of executive sponsorship inside corporate walls? That is the next great stage of my career, I think.

Currently, my lack of more internal influence is because basically, I haven’t tried. I don’t write an internal blog. I don’t have an internal newsletter (other than periodic email blasts listing doc updates to stakeholders). I don’t write posts on different topics and share the results and thoughts with others. I haven’t figured out how to do that, or how to overcome the awkwardness of it (there doesn’t seem to be a clear internal pattern for this).

But I’m noodling on an idea that I intend to experiment with more — a “center of excellence,” or maybe an “internal release notes blog.” This would be an internal site that is part blog, part best practices, part announcements. I also want to build up a stakeholder mailing list, and then try to post once a week in our site and share the post on the mailing list. I’m not sure how this will go or how much time it will take. I’ve been blogging externally for more than a dozen years. Influence, either internal or external, is a slow process. And it takes time to write interesting content.

Even so, some of the survey responses give me encouragement for this direction. In response to the survey question, “Why do you think the company treated tech comm as important and highly valuable?” one of the respondents said that they “run learning sessions on API documentation for product mangers to help them understand what’s important for great doc.” Running learning sessions for PMs never actually occurred to me. Are product managers interested in learning best practices for documentation? Maybe.

I think people in many different roles within a company might be interested in similar learning sessions about documentation — understanding what makes for good docs, key qualities to incorporate, and more. I know many people are interested in basic grammar and style, though focusing on language can easily give the impression that tech writers are just language experts. I can’t imagine these doc-learning sessions being very packed or even well-attended, but maybe eventually they can reach the right stakeholders, little by little.

If you’ve engaged in creating an internal site like this, let me know so that I can learn from your experience.

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.