Technical writers often have to support multiple development teams. When you are in a supporting role for multiple development teams, you often have to find ways to juggle competing demands and work overloads. Sometimes too many demands are made for your services and you need to be able to gently push back against demanding stakeholders. You also sometimes need to demonstrate your true value to your team and help your business leaders see when your team is underwater.

At my company, the site reliability engineers (SREs) are similar to me in that they support multiple teams and often get asked to do too much. One of my favorite SREs took some time from his very busy schedule to talk about how he uses Jira to solve this problem. In this blog entry, I’ll capture and share his insights about Jira. This blog entry will be written from his perspective.

About Jira and ticket management systems

Since many development teams use Jira or other ticket management systems to track their tasks, you can use Jira to track, visualize, and communicate your workload to competing stakeholders. Jira can help you demonstrate your value and your true workload.

Best practices for creating Jira tickets

All of our team’s Jira tickets appear in a Kanban board in Jira. Whenever I’m doing any work that seems to take longer than 5-10 minutes, I make a ticket for it:

• I create tickets in the same space in Jira that the engineering teams use. I only ever create them as Tasks when it comes to issue type because of how Jira does lots of hidden automations if they are a different type.
• If I need to create an Epic, I create a master task that has a Requires relationship to all of the smaller tasks associated with it.
• When creating tickets:
  • Every ticket has a basic summary and description.
  • If it is related to or required by a different ticket, I connect them.
  • Every time I create a ticket, I immediately assign it to myself and add all stakeholders as Watchers upon ticket creation. (It’s easy to lose tickets if they are unassigned).

Tracking requests from stakeholders

I create most of my tickets, but if someone sends me an email or instant message about something, I send them the following template:

Asking them to open a ticket sometimes introduces enough friction that they reconsider whether the task is high enough of a priority to justify making a ticket. Sometimes they work to resolve an issue on their own.

Dealing with demanding stakeholders

Erring on the side of making too many tickets rather than too few has helped me deal with overly pushy or demanding stakeholders. When someone makes a request and I try to push back, I often start by showing them the link to our Kanban board, which is usually quite full.

Another thing that has also reduced my interactions with pushy or demanding stakeholders over time is to add the stakeholder as a Watcher by default to all SRE tickets related to their team in any way. That means they have likely been spammed with a lot of Jira ticket updates over the past 6 months, which helps the stakeholder better appreciate the level of work we are doing on their team’s behalf.

Using Jira tickets in development standups

If I invited to participate in a standup, I only speak about work if it has a ticket. If it needs to have a ticket, so I won’t add anything to my standup update unless a ticket exists for it.

Using tickets for meeting minutes

If I have a ticket that a meeting is related to, I now copy/paste the meeting minutes as a comment into the ticket itself as a way of sending my meeting minutes to everyone, while ensuring they are a Watcher on that ticket.

Areas where the system could improve

I’m still working on how to use it to properly communicate overwhelm when the team is underwater. I’ve been trying to figure out best way to cap “in flight” ticket counts, meaning what’s in progress, blocked, or in review state. A lot of times I’m waiting on a review, or waiting for CI/CD, or handing off to another person to finish some bits before I can revisit, or waiting on internal ticket / security reviews / etc. so stuff gets stuck a lot.

I need to improve at when to bring something back into the backlog, probably, because for many stand-ups, I’ve given no update on several tasks that keep getting overridden by other priorities. Such is SRE life.