At one of the last technical writing conferences I attended, I ran into a few technical writers who looked at my nametag (which listed the organization I work for) and suddenly perked up with questions: Does the Church have a lot of software? Are there really technical writers in the Church? They looked puzzled.
These questions never cease to amaze me. For an organization of our size, it seems obvious that the Church must have some administrative software and technical writers, but exactly who or how many or where they’re located is a mystery. In this article, I’d like to unfold some of those fuzzy details about technical writing in the Church.
The Church’s ICS department has three full-time technical writers. Other departments with instructional needs (for example, Materials Management) often have their own writers, but because technology is mainly created through the Church’s ICS department, this is where the official technical writers are located.
Although we’re small, we’re a talented, efficient group. We all have either bachelors or masters degrees (in English, linguistics, nonfiction writing, and so on) as well as strong writing backgrounds. We have laptops to enable mobile workstations (ideal in an agile environment), and we use a variety of tools for help authoring, including Madcap Flare, RoboHelp, Photoshop, Camtasia Studio, Adobe Captivate, InDesign, SharePoint, and more.
We’re well-versed in the Church Style Guide, the Microsoft Manual of Style for Technical Publications, and the Chicago Manual of Style 15. With these style guides and our technical knowledge of CSS, XML, graphics, and video, we create a variety of help materials, including software manuals, online help, quick reference guides, video tutorials, interface text, release notes, web content, and product communications. The range of help content (beyond user guides) is something many departments don’t realize, so we frequently market what we can provide.
Our team actively participates in the Society for Technical Communication, presents at conferences, and engages in social media related to the profession. Each team member has a strong testimony and is temple worthy, and overall we seek to incorporate prayer for guidance in overcoming the challenges we face. Despite our immersion in a spiritual environment, we are paid competitive salaries on par with companies in the surrounding area. And we’re in the process of adding a couple of new members to our team.
None of our content is written remotely or outsourced. In many cases, the confidential nature of the applications requires in-house technical writers. Because of that, we’re all located in downtown Salt Lake City, situated in the Triad or the Church Office Building. The central location also helps us be close to our project teams, and in some cases allows us to observe first-hand how users work with applications.
Because of the agile methodology of the department, each of us is embedded within a project team. For example, we each sit next to quality assurance and development engineers, rather than next to other technical writers. This helps increase communication about the projects we’re working on. Additionally, instead of being sectioned off in offices, we sit at desks in an open room without dividing walls. On a busy day, I can look out and count more than twenty people. In general, project teams try to sit near each other, but since technical writers are usually on a handful of projects at once, this isn’t always possible.
Although we don’t author content in a content management system, the Church does have a Mark Logic database that we can use for robust single-sourcing purposes. We haven’t needed to single source at that level yet, however. Right now Madcap Flare and Adobe RoboHelp get the job done. Much of the help material is relatively small, on par with the applications we document. In other areas of the Church (especially those involved with Church handbooks and literary material), I believe database-driven single sourcing is more prominent. Our technical writing team and its processes have largely remained separate from those groups.
Since our team is so new (about three years old), we do face challenges. One of these challenges involves expansion. Many portfolio managers don’t have technical writers assigned to their projects. The only portfolios with dedicated technical writers include the Missionary and General Authority portfolios (“portfolio” is the name of a group within the ICS department). Although at times we work across portfolios, many times the technical needs of these other portfolios are handled by subject matter experts acting in an ad hoc capacity as technical writers.
Another area of interest to us is social media, specifically wikis. We recognize that no instruction manual can cover all the details inherent in a global landscape. Wikis have a strong potential for enabling Church members to contribute helpful details to the countless undocumented situations, workarounds, and unique processes that vary from location to location.
Currently content residing at http://ldsclerks.com (a community-founded wiki) is being brought in-house to a Church-sponsored wiki on tech.lds.org. However, the sensitivity of the approval process and accuracy of wiki content as well as general participation in content creation pose challenges for the use of wikis in other project areas. It makes sense to supplement the MLS help with a wiki, but not so much with other software.
Another challenge involves organizational size. One advantage to working in the Church environment is access to an immense body of resources and talent. The Church has a range of employees with exceptional skills in everything from interaction design to multimedia, XML, usability, and other key areas related to technical writing.
However, it can sometimes be challenging to cross departmental boundaries, to move beyond perceptions that these groups are “separate entities” and instead view them as all players on the same team with the same goals. It’s the old “silo effect” common to many large companies. However, I’ve found that other groups are usually more than happy to interact (after you figure out who to contact).
Overall, it’s a great time to be a technical writer in the Church. Despite the enormous number of departments and processes in the organization of the Church, the technical writing methodologies are largely still open and flexible. We’re laying the foundation with best practices and principles that will help move the work forward in the years to come.
At a recent ICS department meeting, Elder D. Todd Christofferson spoke about how we can help Church members adopt the software technology ICS creates. He said, “As the advantages [of technology] become more and more obvious, our problem may be helping people learn how to use it, more than encouraging them to do it.”
Our team, called User Education, definitely strives to do this. In return, we get the satisfaction of knowing that our help materials not only help members adopt the technology but also empower them with increased understanding and capacity to move the work forward.