Everyone's a player (in a mid-90s MUD)

> N

You have found a secret room in the castle! You gain 26 xp.

You enter a large interior space with stone walls and a high stone ceiling. Torches flicker in wall brackets. A large self-referential tapestry hanging on the north wall shows a guild workshop full of happy weavers busily weaving the very tapestry in which they are depicted. There are exits to the east, west, and south.

Linden, another player, is here. Gwyrian, another player, is here.

> say Hi

You say “Hi”

Gwyrian says “Hey! Do you want to explore this area together?”

Linden attacks you with a critical hit from their sword!

You are dead!

Other people: sometimes difficult to work with and often impossible to predict. In your technical or documentation project, how can you get the right people interested and involved? How can you keep those people happily engaged until the work is done? Is there anything you can do to prevent griefing… err, “interpersonal difficulties” from causing delays? And why do some people seem to thrive in an environment with poor documentation and how can you encourage them to participate in effectively documenting everything anyway?

In this talk, I’ll explore ways to accomplish these aims, using strategies drawn from “Player Type Theory”. For 20 years, this theory has been employed by game designers to encourage stable long-term play communities in online multiplayer games. These are strategies that I have used successfully in my workplace and they can work for you too.

Target audience is anyone who has a touch point with technical documentation, including project managers, developers/programmers/software engineers, support desk workers, etc.

This talk has been presented at:

Write The Docs Portland 2017
BCNet 2017
DevOpsDays Vancouver 2018
DevOpsDays Montreal 2018 (5-minute Ignite talk)
Interchange 2018
DevOpsDays Galway 2018

Long-term Documentation Maintenance: Critically Necessary, Deeply Underappreciated

40 Helens agree: making things is exciting and fun! The sometimes tedious and often thankless work of maintaining them over the long term is less fun, but just as necessary. This is especially true for documentation.

The documentation: it is written. Written, edited, reviewed, revised, re-reviewed, approved, approved again, and then published. Success! Thank everything we never have to do that again. Or do we? In a rapidly changing technological world, of course we do.

We’ve all had the experience of trying to find documentation for something we’re trying to use and discovering that it’s out-of-date, for a previous version, no longer relevant, or for features that no longer exist. Creating new things is exciting. Maintaining, monitoring, reviewing existing things in the long term is a less exciting venture, but critical to the long-term success of your projects and products.

In this talk, I will offer strategies both technical and interpersonal to better maintain and review documentation repositories over the long term.

Documentation Speeding Dating (Commonly Known as "Training")

Is your documentation languishing, alone and unloved in a wiki somewhere? Are your users spending all their time swiping right over at Stack Overflow? What if there was a way you could introduce your users to your docs in a structured yet friendly way and just… see what happens? It’s a tricky problem, but training could be the answer.

Of course, it’s possible that there is already a training program in place to support your users, but how closely are your trainers connected to your documentarians? When the people who create and deliver the training aren’t connected to the people who write the documentation, there are a number of possible problems that can result, such as the eventual existence of two sets of user support documentation, confused users, inconsistent support, and training programs that don’t keep pace with the current versions of your software, among others.

Just like your users and your docs, your docs and your training program have the potential to be an excellent partnership. Although these functions are often separated, especially in larger organizations, there are significant benefits to bringing them closer together. This talk explores the those benefits, including improvements to your documentation and training strategies, improved and user-tested docs, fewer documentation gaps, and better relationships with users.

The Universe is Infinite, But We Are Not: The Unsupportable Futility of “Trying Harder”

There’s an uncomfortable truth we need to acknowledge in our industry: IT professionals are people. And people are complex systems with multiple failure points, both bad and good. We make mistakes, don’t take care of ourselves, burn out, experience loss, or get sick. We experience triumphs and successes that distract us from our work. We try and sometimes fail to balance the demands on our time in both our personal and professional lives. Our energies, attention, and ability can vary over time for many reasons.

Why does this matter? Well, because too often, “trying harder” in at least one of its many forms is the strategy that organizations and individuals turn to in order to fill a gap in planning, resourcing, or governance. And while any of us can put in a short burst of extra energy to achieve success for a short-term project or initiative, for all the reasons listed above, “trying harder” can simply never be a sustainable long-term strategy. This talk will address the telltale signs of when “trying harder” is being used inappropriately and is likely to lead to failure. It will also offer pragmatic strategies or approaches you can use instead. It’s all about strategic pragmatism and setting ourselves up for success as finite beings in a universe (and an industry) of infinite challenge and opportunity.