Webinar -- Optimizing Content Development: Grow Your Content Faster Than You Grow Your Team
Webinar recording
You can now view a recording of the webinar here:
Webinar details
Here’s the full webinar description:
Optimizing Content Development: Grow Your Content Faster Than You Grow Your Team," with Paul Gustafson and Megan Gilhooly
Companies of all sizes need to scale their content operations at some point, often with a flat or shrinking headcount. Startups look to larger enterprises to learn how to balance the quality of their content with efficient publishing practices. But here’s a secret — even the most productive enterprises struggle to achieve this balance.
In this webinar, Scott Abel, The Content Wrangler, is joined by Tom Johnson, Senior Technical Writer at Amazon and author of the blog “I’d Rather Be Writing;” Paul Gustafson, CEO of Expert Support; and Megan Gilhooly, VP of Customer Experience at Zoomin. Together, these three content experts share the good, the bad, and the ugly realities of centralizing content operations and developing content at scale.
Attendees will learn:
- Strategies for scaling content development without growing headcount
- Pros and cons of centralizing documentation efforts vs. autonomous content silos
- Eight elements for optimizing content delivery and the customer experience
The webinar was sponsored by Zoomin software and hosted through BrightTalk with Scott Abel.
Preliminary thoughts
This should be a good webinar, especially with Paul Gustafson and Megan Gilhooly — both of whom are extremely knowledgeable people. Exactly what are we talking about in this webinar? It’s a title that could be interpreted in different ways. Growing your content faster than your team speaks the way tech writers are supporting more and more content across the enterprise, with fewer resources to engage deeply with the different teams producing the content. You might need to develop a center of excellence site to establish best practices and standards that others follow.
This discussion has some echoes of previous posts on my site, such as Unifying Technical Content Sets into a Broader Ecosystem and more recently with Reflecting seven years later about why we were laid off.
In that later series, I explored whether organization models (centralized, distributed, or decentralized) have any correlation with the tech writer’s value and importance. (Hang on, here I’ll explain how this relates to the topic.) If you read that series, you saw that I created a short survey to gather some feedback (ongoing results are here). So far, the results seem mixed, and the only pattern I currently see is that people feel valued and important when senior management is supportive of tech comm. But this leads me to wonder, how does senior management rise to that level of support if all they see are tech writers adding little value? As one commenter, Joe Ambrogne, put it,
When you consider that many writers report being outnumbered by developers in an IT company, it’s no wonder if managers have trouble recognizing what a high-performing technical writer looks like. They are probably used to seeing us in a watered-down, clerical state.
This conundrum prompts the question: To rise beyond a watered-down, clerical state, should we care about any docs beyond our immediate team? Should we be focusing on implementing more centralized processes and standards across an enterprise, even if no one owns this scope? Or should we let the enterprise consist of pockets of independently operating technical writers?
Most CCMS implementations, by their sheer complexity, cost, and scope, mandate that the system be used by a broader organization (or large parts of it). So questions about enterprise taxonomy, federated search, inter-relationships of content, etc., become more pressing when a CCMS is in place, rather than when documentation teams use lightweight markup and open-source static site generators.
The model question (centralized, distributed, or decentralized) always throws me into different directions. I was chatting with another colleague at a big tech company a while ago, and he described an upcoming role they have. This senior technical writer would be like an itinerant writing coach, moving from one engineering team to another in a constantly rotating way, imparting best practices and standards, improving the team’s writing, fixing existing issues, etc, and then moving on. This company has more than 6,000 engineers and a small team of technical writers (< 6). You can imagine how this plays out — the tech docs group probably has a constant inflow of requests from many engineers they’ve never met before.
In chatting with Paul Gustafson about this itinerant role, he told me he sees similar patterns almost everywhere in the industry. You have a few tech writers who are serving the needs of a large number of engineering groups. This is the norm, not some anomaly.
Sometimes I think I am daydreaming about being dedicated to fewer projects in a more immersive way. Maybe this is just the tech comm model: you’re a consulting itinerant. You don’t have a home. You pull a wagon from village to village, and when you pull up, people bring you their broken, barely readable documentation, and you fix it, teach them standards, impart writing wisdom, and then pull off to another engineering village.
In some ways, perhaps I’ve over-romanticized the more immersive, “resident” model. In the layoff series posts, I drool over org models where tech writers can engage in fewer projects in a more immersive way, devoting their full time and energy such that they can provide deep influence, blurring the roles between content design and product design. With this deep immersion and influence, their sense of value and importance rises in the org, which then makes them feel more fulfilled and respected.
However, I might have a distorted view of that role. Being a resident rather than itinerant tech writer might not be all it’s cracked up to be. Someone made a comment on Linkedin (though I can’t find it) depicting how she’s dedicated to a single product team but finds that documentation needs come and go. She has periodic stretches of waiting and downtime while features are being developed before she can start on the documentation. And there’s a constant uneasiness that there might not be enough need for a full-time technical writer.
I get that point of view. In my current position, I’m actually loaned out to another division (outside my home division) in a fully allocated way. Only instead of putting my previous projects on hold, I’m doing double duty between the two divisions. Anyway, the division where I’m loaned out to has fluctuating needs for docs. Sometimes they’re eager for me to document some new feature, and then they go quiet for a little while as developers build out additional features and infrastructure. Engineering work moves slowly. Releases are weekly, and most of the times the release is 90% applicable to the backend, and only 10% visible on the frontend. For example, a new check box might have been added that gives some new option to a widget (causing a backend API to send values to a variable). Often I’m writing docs for a few pre-release partners to evaluate, and then a lot it changes on the next iteration.
The idea of blurring lines between content and product design isn’t as meaningful if developers are building out a user interface little by little, developing backend APIs to support different function calls, figuring out methods of testing, and such. A lot of times, experts are dialoging with other experts about best approaches for infrastructure, databases, account setup, or other technical topics. Or field engineers are working closely with partners and product managers on functionality to develop and support and such. There really isn’t a need for a technical writer to jump into these early discussions and start documenting features which haven’t been designed yet. And there’s the added problem of documenting too early, only to find that you have to rewrite the documentation again each month as the product team figures out which direction to go.
Having too much work is better than not having enough work. I’ve also learned that I thrive in chaos (which might explain why I like Amazon so much). Perhaps I should give up on the resident model and fully embrace the itinerant model. Or maybe there’s another model for me to discover and embrace.
At any rate, you can see that my thoughts are running in various directions here. Hopefully as Paul and Megan and I dig into this topic, we can steer it in a useful direction that will let users walk away with solid, actionable tasks to optimize their documentation across the enterprise, whether you’re in a centralized, decentralized, or distributed team.
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.