Skip to content

Commit

Permalink
Add doc on liaisonships | Agile handbook
Browse files Browse the repository at this point in the history
  • Loading branch information
@austin-schaefer
austin-schaefer committed Aug 19, 2021
1 parent 43fc023 commit 188a091
Show file tree
Hide file tree
Showing 2 changed files with 251 additions and 0 deletions.
249 changes: 249 additions & 0 deletions src/content/docs/agile-handbook/sprint-mechanics/liaisonships.mdx
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,249 @@
---
title: "Liaisonships"
template: basicDoc
topics:
- Docs agile handbook
---
For large projects, the team manager will often assign a particular tech writer to that project as a "liaison." The liaison’s job is to ensure that we get complete, consistent, and timely docs.

Not every project gets a liaisonship! For smaller projects, we'll encourage teams to rely on the [hero self-service process](3379_INSERT_LINK_HERE) to make their changes. And a smallish project may not need a full liaison—a single ticket might be enough to manage the work.

To figure out which type of support is best for a given project, one of the managers on the team will have a [scoping conversation](3379_INSERT_LINK_HERE) with a subject matter expert. Common themes where a full liaisonship is helpful include:

* Project is complex and would benefit from intimate familiarity with the feature.
* Project requires significant information architecture work.
* Project will produce enough docs that consistency across those docs will be hard to achieve without a centralized editor.
* Project SMEs would benefit from a consistent "face" of the tech writing team.

However, a liaison is not the only author on a project. Liaisons should structure their work to maximize swarming and knowledge sharing.

## Liaison responsibilities: Manage project flow [#project-flow]

<table>
<thead>
<tr>
<th style={{ width: "200px" }}>
Activity
</th>
<th>
Who?
</th>
<th>
Notes
</th>
</tr>
</thead>
<tbody>
<tr>
<td>
Learn new thing exists
</td>
<td>
Team
</td>
<td>
Ideally the Hero or a Tech Docs manager gets notified directly bya a PM about a new project. But sometimes we'll find out about something unexpectedly. If you're not sure whether we have a writer working on something, ask a manager on the team and they'll reach out to the subject matter expert to scope it.
</td>
</tr>
<tr>
<td>
Have a scoping meeting
</td>
<td>
Tech Docs manager
</td>
<td>
The manager is responsible for tracking the general state of major projects across the company, and is generally the first point of contact for new projects. When a large new project comes up, the manager will do a pre-scope meeting with the requestor. ([Appendix: Project scoping runbook](3379_INSERT_LINK_HERE) has a list of common questions for this pre-scope meeting.) That conversation helps figure out timeline, complexity, key docs considerations, and which writer will be a good fit as liaison.
</td>
</tr>
<tr>
<td>
Assign a liaison
</td>
<td>
Tech Docs manager
</td>
<td>
After (or sometimes before) the pre-scope, the Docs Managers will put their heads together and figure out who should liaison for this request.
</td>
</tr>
<tr>
<td>
Keep track of project dates
</td>
<td>
Liaison
</td>
<td>
The managers on the team keep track of upcoming projects that don't have a liaison assigned. Once a project moves into the execution phase and a writer gets involved, that liaison keeps track of the specifics of dates: Betas, limited releases, GAs, fast-follows, and so on.

Your manager's always here to help out if you're getting blocked or dates are shifting too rapidly to plan properly.
</td>
</tr>
<tr>
<td>
Validate the docs plan with the project team
</td>
<td>
Liaison
</td>
<td>
The liaison works with their stakeholders to define the information architecture and deliverables. If needed, your manager can assist the liaison in communicating our expectations to the project team.
</td>
</tr>
<tr>
<td>
Create tickets
</td>
<td>
Liaison
</td>
<td>
Since the liaison defines the information architecture, the liaison will know what kinds of deliverables we need. The liaison also acts as an advocate for their Jiras in the backlog grooming and sprint planning processes, and ensures their stories meet the [story quality requirements](3379_INSERT_LINK_HERE). The liaison should also ensure that our partner teams have appropriate Jiras in their backlogs for their work.
</td>
</tr>
<tr>
<td>
Remove blockers (such as reviewer delay)
</td>
<td>
Liaison + Manager
</td>
<td>
While the liaison is primarily responsible for handling SME relationships and removing day-to-day blockers, your manager is here to help unstick things anytime you need help.
</td>
</tr>
<tr>
<td>
Wrap up the liaisonship
</td>
<td>
Liaison
</td>
<td>
Liaisonships are not forever assignments! When the bulk of your work on a project is complete, it might be time to consider ending the liaisonship. Reach out to your manager to talk about it. When you end it, let stakeholders know and update the liaison roster. Point the team to @hero in future so they know they can still get help.
</td>
</tr>
</tbody>
</table>

## Liaison responsibilities: Build expertise [#build-expertise]

<table>
<thead>
<tr>
<th style={{ width: "200px" }}>
Activity
</th>
<th>
Who?
</th>
<th>
Notes
</th>
</tr>
</thead>
<tbody>
<tr>
<td>
Develop a deep expertise on feature (and esp the audience)
</td>
<td>
Liaison
</td>
<td>
Become the Docs Team's local expert on the feature. Understand what it does, what problems it solves, and the implications for our content.
</td>
</tr>
<tr>
<td>
Educate the team on the feature
</td>
<td>
Liaison
</td>
<td>
Part of your responsibility as liaison is to share expertise around the team. That helps with swarming, but it also makes for better hero review and a smarter team that can write more intelligently about the entire New Relic One platform.
</td>
</tr>
<tr>
<td>
Coordinate with design and/or research and test your docs
</td>
<td>
Liaison
</td>
<td>
Reach out to the designer and/or researcher for the project, and periodically sync on any shared concerns, user needs, etc. And you should advocate for user testing and validation of your content.
</td>
</tr>
</tbody>
</table>

## Liaison responsibilities: Define content strategy (oh, and do the writing) [#content-strategy-writing]

<table>
<thead>
<tr>
<th style={{ width: "200px" }}>
Activity
</th>
<th>
Who?
</th>
<th>
Notes
</th>
</tr>
</thead>
<tbody>
<tr>
<td>
Define the information architecture
</td>
<td>
Liaison
</td>
<td>
As liaison, you're the expert on both the feature the product team is building, and the docs content (new and existing) that will support that feature. Build an IA that will meet all project needs and scale to the future.
</td>
</tr>
<tr>
<td>
Write content
</td>
<td>
Team
</td>
<td>
The liaison writes much of the content for their project, especially the conceptual content like intro docs. But the whole team is expected to swarm and contribute to large projects, with the liaison coordinating that work.
</td>
</tr>
<tr>
<td>
Peer edit drafts
</td>
<td>
Liaison
</td>
<td>
By being the only person to read every doc draft related to the project, liaison can ensure consistency. (The liaison doesn't peer edit their own GA drafts, but does do a final consistency pass across all the docs.)
</td>
</tr>
<tr>
<td>
Coordinate publication
</td>
<td>
Liaison
</td>
<td>
When the time comes to release (whether that's beta, GA, limited release, or EoL), it's the liaison's job to coordinate with PM, Eng, and Product Marketing to ensure docs go out on time with other deliverables.
</td>
</tr>
</tbody>
</table>

## For more help

We welcome thoughts or questions on our handbook! The easiest way to get in touch is to [file a GitHub issue](https://github.com/newrelic/docs-website/issues/new/choose).
2 changes: 2 additions & 0 deletions src/nav/docs-agile-handbook.yml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -25,3 +25,5 @@ pages:
path: /docs/agile-handbook/sprint-mechanics/planning-poker
- title: "Sprint workflow"
path: /docs/agile-handbook/sprint-mechanics/sprint-workflow
- title: "Liaisonships"
path: /docs/agile-handbook/sprint-mechanics/liaisonships

0 comments on commit 188a091

Please sign in to comment.