Why even answer that question? Because technical writers are obsessed with the idea of getting value out of social, often in advance of the rest of their organizations, and documentation is an important piece of the information exchange puzzle. Because we get regular requests on Jive Community about how we use Jive. And because we're uniquely positioned to see how Jive is a fantastic asset to any technical documentation team, even if they don't yet have the kind of full-company adoption that we enjoy here at Jive.

 

Subject-Matter Expert Access

Technical experts are more expensive than technical writers. How do you get information from the former to the latter without "wasting" the time of your expensive subject matter experts (known in the biz as "SMEs")? Because of this concern, access to technical expertise in many organizations is explicitly limited. Some tech writers have firm limits on time, and many others aren't collocated with their subject matter experts. The writers that sit in an engineering group and sometimes attend their meetings are a privileged few: many writing teams operate outside engineering with controlled access, and only see products after they are completed, if ever. In the worst case, documents are written by engineers and "polished" by English majors who don't have access to the products they are documenting.

 

Even without explicit contact limits and long distances, how technical information gets into the docs can depend on organizational structure as much as on the initiative and preferences of tech writers. Most writers would agree that direct in-person access to SMEs during the development process is ideal. However, this doesn't always scale, especially since a few writers typically support many developers. In many organizations, particularly where waterfall is the methodology, information is created almost entirely by developers and designers in the form of specs, internal whitepapers, and other reference docs created before release. The tech writer has to find them, interpret them, and then turn the information into something a customer could use. If that content is stored somewhere like SharePoint or a version control system, it might be protected by a complicated permissions scheme. In Agile software shops, on the other hand, product information could be primarily in developers' heads or disseminated during scrum meetings until it is crystallized into a working prototype: the tech writer might have to rely entirely on interviewing stakeholders to get information, and is unlikely to be able to get near-final product information until the product has already been developed. While writers can learn a ton when they're able to use the products they are documenting, this only provides part of the picture. And sometimes it's impossible: one assumes tech writers are not allowed to drive aircraft carriers to verify the steering documentation. Inevitably, to write useful documentation, we need to communicate with the people who are making the technology.

 

In the discovery and writing phases, information discovery often involves a laborious process of access-granting and consecutive review that becomes increasingly frustrating when direct technical expert access is in short supply. The tech writer might need to:

 

  1. Ask the SME how to find the information
  2. Ask the SME for permissions to see/edit the documents containing the information
  3. Ask the SME for help assembling and interpreting the information
  4. Ask for review on drafts of the repurposed information.
  5. Ask a PM or Marketing person for the "messaging" appropriate for the document.
  6. Get a final technical review on post-messaged content.

 

Most of these steps will vary, and most will probably take place in email with the usual requirements for back-and-forth and course correction, with the highest probability of face-to-face communication happening during stage 3. As you can see, though, the expectation of persistent walls between developer information and other stakeholders, as well as the rationing of developer time, can create a slower, extremely consecutive chain of information development that can waste a good deal of expensive time at various stages.

 

In Jive, the base expectation is for most documents and discussions to be public and social, not proprietary and private. Socializing design documents and specs removes much of the need for consecutive document transfer and review--many documents will be easily findable through search. This lessens the need for technical experts to share "their" information and also tends to make product information less static and authoritative, since it should already be public and reviewable at all but the earliest stages.

 

In fact, by the time technical writers begin using them as a source, technical documents in Jive often have already been discussed by other stakeholders. Public stakeholder review improves the chances that some of the basic questions about the product have already been noted in comments and incorporated in the document. In turn, at the draft documentation stage, asynchronous public commenting can allow short bursts of interactive feedback from a developer whose time is rationed, without rigidly scheduling review times. Public commenting and discussion also allow less expensive subject matter experts to provide input when available, instead of limiting the possibility of answering to SMEs who are directly contacted. Instead of an expensive, time-consuming consecutive chain of individual reviews, social collaboration is more like a web, allowing smaller, simultaneous interactive contributions from multiple players over a shorter timeline. Information and expertise gaps can be identified quickly instead of becoming blockers that eat up time.

 

For example, if the writer asks a question in a product group and @mentions the chief developer, she may not have to wait for an initial response--she might get answers from other developers in the group or be quickly directed to documents in the community that can answer her question. Often the need for one specific person to answer the question can be either eliminated or closely narrowed down to a specific decision or piece of knowledge. The writer can then approach the hard-to-access SME in person or in the community with a very specific, very time-limited request.

 

Getting signoff from key parties on the document can be simultaneous--just @mention the final reviewers and provide a drop dead date. No worries about whether reviewers are copying everyone on replies.

 

Collaboration with Multiple Stakeholders

When multiple stakeholders are reviewing and commenting on content simultaneously, they have a higher likelihood of surfacing the complexities involved in presenting information to customers and thus preemptively solving cross-organizational information problems.

 

For example, take system requirements, a notoriously thankless collaborative writing task that often results in various stakeholders flatly contradicting each other repeatedly, and sometimes in irate customers who find them unrealistically rigorous or lax. When offering up a draft of software installation requirements, a writer could avoid multiple, successive, and conflicting revisions from developers (who may know what limits the code enforces), Support (who know what machines specific customers are running the software on today and how well that's working) and Product Management (who may have made promises to customers about the road map) by publishing an early draft of the document in public. These three parties can all comment on the document asynchronously without occupying the same meeting room or time zone, without participating in a long email chain, and without the mess of overwriting and reinstating each other's document edits in a wiki. The decision process is also captured as commentary on a community document, so there is historical public knowledge of the factors that went into the final draft. When someone from Sales asks months later what the reasoning was behind the requirements, you can send him a link to the discussion.

 

Social Rewards for Expertise

Working on documentation is typically not a highly rewarded behavior for SMEs. Most technical writers who are any good have learned to foster good relationships with technical experts, thank them for their time, and remind them that their input results in better customer outcomes, but this only goes so far given the "real job" of engineers is to get product built. Even if management identifies documentation as a priority, documentation work tends to be invisible, given it doesn't typically result in code checkins or reduced bug counts. (Well, you can bug track your documentation, but this has other pitfalls.) By socializing some or all of your documentation work, then reinforcing useful technical input using the Jive capability for shares, likes, and badging, you can ensure technical contributors get public credit for their efforts. And because their comments and edits are public, subject matter experts also increase their technical credibility on the public record. (This also increases writer credibility: good tech writers know that it's ordinary to discover gaps in product knowledge and functionality while trying to document a product coherently.)

 

Furthermore, some reclusive personalities who find face-to-face interaction burdensome blossom in online communication. Jive is a great place to make friends with valuable information sources who fear extroverts but flourish in cyberspace where they can take all the time they want to craft a helpful reply.

 

Customer Access

Customer perspective is a key differentiator in effective documentation that reduces Support burden and increases customer satisfaction. In many organizations, a tech writer has little to zero access to customer perspectives. Tech writers who work in an organization with a customer-facing Jive community have a built-in information source for understanding and responding to customer needs. They can harvest customer responses directly from the community and, if they're allowed to interact with customers, ask them directly for feedback. If they're not allowed to contact customers directly, they still have improved visibility into interactions customers have with Support, Sales, and other parts of the organization that solve customer problems and who use documentation in customer contact situations. Reading customer queries directly can be extremely powerful in terms of understanding the kinds of problems that documentation can solve, the terminology customers use when conceptualizing a problem, and the kinds of solutions customers are themselves creating to solve information gaps about your product.

 

Furthermore, participating in conversations with customers can increase technical documentation's credibility among the customer base. In cases where customers have had historical difficulty finding the documentation, technical writers (or other stakeholders) who actively point customers to documentation resources during customer interactions can increase awareness and usage by helping them directly. In cases where customers identify errors or gaps in the documentation, proactively volunteering ideas about how to fix those problems can contribute to an improved image of documentation as a service, with the by-product of making customers aware that documentation is written by actual people with a credible agenda.

 

When customers stop thinking of documentation as being produced by a vaguely obstructive and faceless group and begin seeing it as a strategic product in its own right that is managed by a group of responsive and product-knowledgeable individuals, they often organically develop an interest in prioritizing information problems that can be helpful to the team as well as reducing their own frustration level. Through social work relationships, customers who enjoy pointing out errors can often become allies in improving documentation quality.

 

In organizations without a customer community, an internal community can still provide improved access to customer concerns when customer-facing groups like Sales and Customer Support socialize their own customer interactions. Tech writers who read about customer problems raised by these groups have an opportunity to:

 

  • Find out what questions customers are asking and add that information to the formal documentation
  • Discover what information formats are useful during Sales and Support cycles (is Web or print useful? How about quick setup guides rather than full-scale manuals?)
  • Learn what customer-facing information is being created around the organization to avoid redundant effort.

 

Answering these questions can make even developer-driven documentation richer, and build better collaborative relationships organization-wide.

 

Enhanced Group Identity

Most organizations don't know what their documentation group is doing: in many cases internal users don't even know where the documentation is located. By creating a dedicated space or social group in Jive, a documentation group can centralize and socialize its operations. Sharing documents, frequently linking back to the documentation base, and volunteering information in discussions where information gaps are surfaced are all great ways to show how the documentation group is adding value, and help other parts of the organizations both contribute to and benefit from documentation.

 

If you encourage community members to log requests through the documentation space, they'll also become aware of the kinds of requests other stakeholders make from documentation and how they are resolved. Making the process more transparent helps documentation users and contributors understand more clearly where the information is coming from, what kinds of solutions are possible, the decisions required for information planning, and how to work with technical communicators to get better information to consumers.

 

Conclusion

Not every company's culture will be friendly to using Jive's potential to the fullest. Some communities won't allow full customer access; others won't let specs be public until they're set in stone. Technical writers may not be allowed to have their own playgrounds. But the general direction of social communication is to make information public, and a social information community, even a read-only one, is a huge win for information professionals. Having Jive makes writers almost instantly more effective, and has the potential to engage them in powerful, profitable, company-wide shifts in information-building.