So you've been reading my blog and have taken to heart my message that you need docs. Aww! Thank you! I'm flattered. But now, brass tacks, how do you do it? How does this person fit in your team? How do you make them feel welcome?
For the team
Set expectations
If your team has never worked with a technical writer before, they're probably going to be concerned. They might worry that the writer will slow down the pace of development by hogging their time and energy with endless questions. They might wonder whether their delivery schedule is changing, or if they're supposed to help train the writer in some way.
Talk over the team's concerns with them, even if it's just during brief one-on-one chats. Let them know your plans for training the writer on your system (even if that's just letting the writer explore the system and sit in on meetings). Also make sure the team knows development won't significantly change. If you expect them to participate in documentation reviews, mention that before the writer shows up. Let them know the writer will be in meetings and will have access to user stories. Make it clear you've thought out the writer's position on the team, but also solicit feedback about how the writer can mesh most effectively with them. (That said, don't compromise on the writer's access to team meetings and user stories.)
Put the writer on the Definition of Done
Strongly consider adding the writer to the DoD. That said, save this action for after the writer has been working with your team for at least 30 days, if not 60. Inclusion on the DoD is essential to the goal of having documentation that describes your system's current functionality. Despite that it shouldn’t be done from your writer’s first day (unless it’s the rest of the team’s first day as well), including documentation on the DoD is the ideal end state. Don't dance around the question. Make sure the team is aware of this impending change as part of your expectation setting.
For the writer
Set expectations
As the new person on the team, the writer needs a lot of information about what they'll do, how they'll do it, how fast it needs to be done, and so on. Don't leave them hanging! Make sure they understand that they're expected to write in time with sprints and release documentation with software releases. Make sure they understand how quickly you expect them to ramp up to this point and how to reach out if they're struggling to meet this commitment. If you know what kinds of docs the customer needs right now, provide that as a jumping off point for the writer's work. As they become more familiar with the project, they'll use their expertise to find or refine the documentation solutions.
Additionally, make sure the writer understand how they fit on and interact with the team. Since you've already set expectations with the team around this, it should make this process smoother for everyone. Let them know what assets they have access to (hopefully all available, otherwise they'll have to pester the other team members to get what they need), and how to access them. Also make sure they know how to interact with the team, who they can go to for help as they onboard, and other basic items like this.
Support them
Let the writer know you consider them an important part of the team and that you'll back them up if needed. This means fielding team issues where the writer is being intentionally or unintentionally excluded. You already know to add them to distribution lists and meeting invites but also make sure the team includes the writer when they have a meeting outside their normal routine or meet informally. This includes everything from client meetings that crop up outside the regular planning meetings, as well as regular or irregular team happy hours and other events. Do everything you can do make it explicit that the writer is part of the team and should be treated as such.
This also means providing the writer with the tools they need to do their job. This means they need access to the software they’ll document. They should also know how they're going to physically write the documents. Word is a common option because it's easily available through most companies’ Microsoft subscriptions, but it's not the best option for creating flexible, easily updateable documentation. It’s downright awful for writing online help. If your writer has previous experience with a documentation tool, it might be smart to get it. If you're not sure about their previous experience or there's some other consideration that rules out the tool the writer knows, consider getting a help authoring tool. MadCap Flare and Adobe RoboHelp are industry standards, but there are cheaper options like Help & Manual that provide most of the functionality if not the same high level of support.
Help them create a style guide
There's a lot that goes into making a style guide, most of which you probably don't need to provide feedback on: comma usage, capitalization, esoteric grammar rules and the like. The writer will have to create this style based on their own preference and experience, but that doesn't mean you can't help. If your organization has branding guidelines, these will be an invaluable resource for the writer. Even if it only addresses color and font, this will help the writer create documentation that fits your organization’s unique style. If it has guidance on brand voice, it's even more valuable. A branding guide won't provide all the information the writer needs to complete a documentation style guide (I doubt your branding guide covers the appropriate use of bulleted lists), but it can be a great jumping off point for future style guide development and will help your writer come up to speed even faster.
Want to learn more about docs in Agile? Check out my eBook, “The 12 Principles of Agile Documentation.” Learn how the original 12 Agile principles apply to documentation, how to change your thinking to accommodate documentation, and the benefits you can get from bringing the docs into the fold.
