What is a hero?

"Hero" is a common term across New Relic for a dedicated, interruptible person who acts as an interface for a team. When you're a docs hero, you're the face of the team.

We have two heroes at any given time: the GitHub hero (for issues and pull requests) and the Slack hero (for questions through Slack). We also have a second-shift hero to support EMEA Relics. Every hero's job is to keep things moving for Relics and users. We change GitHub and heroes once a day (we used to do weekly shifts, but we've found daily shifts reduce hero burnout).

Goals for heroing

A Relic once described the New Relic culture this way:

In the end, everyone here is working toward the same purpose [...] That person pinging you with some random request that seems unrelated to your world has the same goals as you. Help them, be kind, be patient.

Your mission as hero is to personify that attitude in Docs-land. Here's what that looks like in practice:

• Create a consistent interface for the team. Having a dedicated hero means the answer to how to get help is always the same: "Ping the hero!" Because we've made this our mantra for 7 years, we don't have to re-educate the org on how to get help or who to go to with docs questions. Even as new people join the team, our processes evolve, and our entire publication toolchain has changed, our interaction model remains consistent. Directing questions to the hero avoids having a single point of failure: Even if a liaison is on leave, on the beach, or has moved onto another project, the hero is there to help.
• Provide a great (internal and external) customer experience. The heroes respond quickly to questions, give timely draft reviews, and perform great customer service and problem solving.
• Build and share knowledge about the site and our products. The heroes end up touching all kinds of obscure areas of our site and interacting with teams they may never have worked with directly. It's a great opportunity to learn more about New Relic and to build relationships across the org.
• Edit new content to our standards. We depend on self-service to cover lots of products with relatively few writers. The GitHub hero gives us a single accountable person who can review new content against Tech Docs team standards and turn it around quickly.
• Buffer the team from interrupts. Since the heroes are our "designated interruptibles" for their shifts, the rest of the team is freed up for deeper focus time. When it is appropriate to bring in another team member, heroes can help in streamlining the handoff and providing helpful context so that their teammate can get started quickly with the lowest possible context-switching burden.

Heroing is a full-time job

As the hero, you're often pulled in a lot of directions in a given shift. Because of this, the expectation is that you do not take on sprint work during your hero shift, unless you really have nothing else to do after completing your hero duties.

You're also not expected to know everything as a hero! If something comes up for which you have no easy answer, let the requestor know you're on it and then ping your fellow writers or other SMEs and helpers from across New Relic for help.

GitHub hero responsibilities

The GitHub hero monitors the GitHub board and the flow of work through GitHub.

Triage issues and PRs

The GitHub hero triages every incoming pull request and issue. You'll tag the issue and pull request, route it to the correct column or team, and also help review incoming edits. For details on handling all of this, see Managing the GitHub boards.

Review PRs

The bulk of your time is generally spent reviewing and approving PRs from non-writers. To review an incoming PR:

1. Label the pull request appropriately (see Managing the GitHub boards for details).
2. Assign yourself to the pull request, so it's clear that you're on point to review and merge.
3. Review the pull request, depending on what type of edit it is:
   • If it's a simple "cosmetic" edit, review the pull request to ensure it's formatted correctly, technically accurate, and fits New Relic style guidelines.
   • If it's a deeper edit, or a completely new doc, give it an in-depth review. The Docs site edit checklist is a great resource here. If it's a really complex or large edit, consider creating a Jira ticket for an upcoming sprint to give it the review time it needs.
   • If it's a What's new post, pay special attention to frontmatter, links, and image formatting. This content follows marketing style, so it doesn't need to fully match our style guidelines for things like capitalization.
   • If it's a release note, focus your review on formatting and basic style, and ensuring the release note itself is helpful. Release notes don't need to follow all docs style guidelines religiously.
4. Preview your change in Gatsby Cloud or locally.
5. Merge the pull request into develop.

Merge develop into main

We merge the develop branch into the main branch a few times a day. This kicks off a build, and ultimately is how draft docs become published docs. Currently we do this three times a day: Around 9 am PST, noon PST, and 3 pm PST.

To merge, just click this magic link and follow the prompts.

Provide peer reviews if time allows

During super busy shifts, you likely won't have time for many of these, but if you're having a slow shift please take some time to periodically check the Writer Needs Peer Edit swim lane for fresh peer edit asks from your teammates before you switch over to doing sprint work.

Slack hero responsibilities

The Slack hero monitors Slack and helps answer questions about docs and route people to the right resource on the team.

Update the Slack alias

Update the alias to ping your name at the start of your hero shift.

To update the alias, type the following into the chat box: !hero set @YOUR_SLACK_HANDLE. For example, if it's Austin's hero shift, the thing to type would be !hero set @austin.

Field questions in the #help-documentation channel

Common questions and requests include:

• Questions about docs content. Answer the question if you know it, or reach out to other writers if it's an area you're not familiar with. Encourage the requestor to edit the docs or submit an issue wherever possible.
• Triage requests for docs support. If it's a project that already has a liaison attached, connect the requestor to the appropriate writer. If it's a project without a liaison or point person, connect them to a tech docs team manager to have a scoping conversation.
• Questions about status of a pull request or issue. Check in and see if you can figure out, or pull in the assignee for that pull request if the status isn't clear.
• Questions about things we don't own (blog, API Explorer, newrelic.com, etc). Help them out by directing them to the appropriate Slack channel. (For a list of properties and their owner, see Who owns the other wesbites? in Google Docs.) If you can't figure out who owns it, try asking the writing team in Slack.

Second-shift hero support

Our Europe writers cover the 2nd shift heroing during their regular working hours. Unlike the US-based heroes, our Barcelona writers hero for an entire two-week sprint. Second-shift heroes cover both GitHub and Slack, but we don't expect that second-shift heroes will field every single request that comes in during their working hours since they're also carrying standard sprint duties during their hero shift.

Route and triage user feedback

The hero is responsible for routing user feedback to liasions. This sections covers the entire lifecycle of a user feedback ticket:

1. The hero is responsible for routing incoming tickets to the proper liaison each day
   • The Hero leaves a comment saying the ticket is being triaged
2. Each writer should spend 10-15 minutes/day triaging their assigned tickets
   • Writer either rewrites or closes the ticket
     • If the writer closes the ticket, they must leave a comment explaining why.
   • Writer needs to add:
     • Acceptance criteria
     • User story
     • Action items
     • Resources
   • While rewriting, focus on making the ticket as swarmable as possible
   • Assign a priority [See priority info in our team's DOC Jira and Github fields - Project 401 - 2022 doc]
   • Add the following label: doc_groomed
3. Triaged tickets enter sprints in one of two ways:
   • Scrum leaders: Bring in tickets based on marked priority
   • Liaisons: Bring in high value issues
   • Squads: During backlog grooming the team can chat about bringing in tickets to fill out a sprint