What is a hero? What is a sidekick?

"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 rotating roles at any given time:

• The Hero handles Slack questions, reviews pull requests, and triages GitHub issues
• The CSAT Sidekick handles customer feedback coming in through Jira.

Both roles are here to keep docs requests moving for Relics and users, and to give the team a buffer from interruptions. We change hero and a sidekick once a week (we used to do daily shifts, but we've found the daily cadence to be too disruptive and lead to work that bleeds over to the next day).

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.

Hero GitHub 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 Netlify 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.

Hero Slack responsibilities

We use Slack to help 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.

Customer feedback sidekick

Feedback is a gift. Every piece of meaningful feedback represents someone taking time out of their day to express something to us. It's important that we honor that gift. Our team created the sidekick role so that we regularly have a human being reading through and thinking about and responding to every piece of feedback that people write to us.

As valuable as this feedback is, though, our primary goal is to keep our Jira backlog down to a manageable and reasonable size.

Customer feedback from our docs site creates tickets in Jira. It's the sidekick's responsibility to look at every ticket that comes in (usually about 5–10 per day) and make decisions about each one.

There are three options for these tickets:

1. Close it.
2. Fix it.
3. Backlog it.

Close customer feedback

Many pieces of customer feedback simply aren't actionable. That's ok! Even if we can't act on a specific piece of feedback, we can use this collective feedback to get an overall sense of how our docs site or a specific category of our docs site is landing with our readers.

Here are some fictional examples of feedback we might not be able to act on specifically:

These docs are bad.

or

Help!

There's also feedback that falls into the category of nonsense or mistakes. You'll know it when you see it. Comments like this can be closed immediately.

Follow this process to close tickets that aren't actionable or don't make sense:

1. Add a category label based on the URL, such as doc_apm or doc_errors-inbox.
2. Set the Workflow status to Closed
3. Set the Resolution to Cannot Reproduce, Filed by Mistake, or Won't Do depending on what feels most appropriate.
4. Add a brief note about why you closed it. Usually, "Not actionable" is plenty.

Fix customer feedback

Sometimes, though rarely, a customer feedback ticket comes in that's highly actionable and is a quick fix, such as a broken link or an outdated image. If you need to reach out to a subject matter expert, the ticket is probably not a quick fix.

Follow this process to close these:

1. Create a PR to address the issue.
2. Add a category label based on the URL, such as doc_apm or doc_errors-inbox (These labels are based off of the first part of the URL after /docs/. For example, https://docs.newrelic.com/docs/errors-inbox` would have the label docs_errors-inbox.).
3. Add a link to the PR.
4. Work the PR to its merge at your leisure.
5. Set the Jira ticket Workflow status to Closed
6. Set the Jira ticket Resolution to Done.

Backlog customer feedback

Too many ticket backlogs have a larger quantity of tickets than can ever be addressed. Our team's goal is to get our customer feedback backlog down to a small enough number that we can meaningfully and reasonably address them in a few sprints based on our current headcount and capacity. Because of this, we need to set a pretty high bar for adding a ticket to our backlog.

Sometimes a piece of customer feedback is quite valid, but the scope of the work required to address it isn't something our team can't commit to right now. Sometimes a comment requires technological knowledge that we don't have. Sometimes a doc simply doesn't get enough traffic to warrant fixing a problem right away.

If you're not sure whether a ticket belongs in our backlog, ask your manager or put it into the On Deck sprint to ensure it doesn't fall through the cracks.

Use this process to put a ticket in the backlog:

1. Write a user story.
2. Write acceptance criteria.
3. Write loose action items.
4. Add any other detail about what you've learned.
5. Move the ticket from the Customer Feedback to Story ticket type.
6. Add the ticket to our Docs On Deck sprint.

Customer email

There's no expectation that you email customers back regarding their feedback. However, when you respond to customers in a timely way, you can:

• Build goodwill
• Learn more about what works and doesn't work in our docs
• Clarify what's going on with the feedback
• Give more useful product feedback to our PMs

When you write an email to a customer, don't send them a boilerplate message. Be sure to write a genuine, thoughtful response to their feedback that either answers their question or asks meaningful questions. You may not get a response and that's OK. In most cases, people are delighted to hear back from a real human being and there's a good chance that you'll learn a little something about our docs and our platform, too!

Customer feedback in aggregate

Even if a single piece of customer feedback is closed and we haven't acted on it, that doesn't mean it stop being useful. When you begin to consider improving a doc or a category of docs on our site, use Jira filters to find customer feedback related to those. For example, if 20 people are expressing confusion at the doc you're looking at, you should consider how to make it less so.

Make reviewing customer feedback for specific docs categories a part of your editing process.