I mentioned in my GitLab reflection that prioritization has been quite different working in Support compared to other previous work I’ve done. In most of my previous work, I’ve had to take “desk shifts” but those are discreet where you’re focused on providing customer service during that period of time and you can focus on other things the rest of the time.
In Support, we have to constantly balance all the different work that we have, especially in helping to ensure that tickets are responded to within the Service Level Agreement (SLA).
It doesn’t always happen, but I ultimately try to reach inbox 0 (with read-only items possibly left), and GitLab to-do 0 by the end of the every week. People often ask me how I manage to do that, so hopefully this provides a bit of insight.
We have a lot of competing priorities when working in Support. Of course, the focus of our work is meeting our performance metrics, which includes SLAs and customer satisfaction (SSAT), but we also understand that in order to meet our goals, we have to do things aside from just answering tickets to iterate and improve on how we work to be more efficient while getting results.
This means that support engineers actually have a long list of responsibilities. Some things we have set deadlines for, such as evaluating take home assessments for candidates within one business day, while other times, we set our own deadlines.
Often, the difficulty is balancing all of the responsibilities, and constantly reprioritizing based on urgency and importance.
No surprise that if I’m on call and I get paged, then that’s it. I drop everything and take care of the incident.
In the Communications Manager on Call (CMOC) role, depending on the incident, we’re usually checking for tickets, Slack messages, etc. for reports related to the incident, and while doing that we might have a little bit of space to respond to other quick questions.
I check Slack pings first when I sign on, because they’re usually the most urgent.
In Support, you often get pinged for ticket escalations, which means that the customer has contacted their account manager about a ticket and it’s up to a manager to find the best person to take it on that is working during that time. This happens more or less often depending on someone’s areas of expertise, and usually more for those who are senior or staff due to the expectations of their depth of knowledge in those areas.
Other times, as with any conversation thread, I might get pinged by others for help and I try to respond as soon as I see it since it’s typically someone working on a ticket, issue, or similar.
At GitLab, I don’t get pinged too often when it’s unimportant, since we have a communication guideline on respecting people’s time by not pinging them if not needed.
If I’m scheduled for a meeting, then I’ll be there, paying attention.
If I get pinged on Slack and I’m not screensharing, then I’ll usually take quick look to see if it can wait (this differs in urgency depending on whether I’m oncall as well).
Some calls are more for listening in rather than meeting with people, so I’m sure as with everyone else, I might be doing some other small tasks that don’t require much attention.
Tickets with short SLA
While I always check the tickets I’m assigned to first, if there’s nothing with a short SLA, then I’ll take a look and help with any tickets that have a short SLA.
I recently recorded a video for the team on how I prioritize tickets and views in ZenDesk based on the assignment model we have.
On a one-day-a-week basis, this is even more of a focus, and we have a permanent zoom room that people can join and drop out of as needed with others who are in the day’s “crew”.
In recent weeks, as part of a shift in how we work as seniors, I’ve been answering less tickets myself, and focusing on helping intermediates on answering tickets. Of course, if a ticket needs responding and no one else is already working on it, I’ll take it on.
Daily non-urgent tasks
When not working on the more immediate tasks, I prioritize doing things for and with other people.
Catching up on relevant Slack channels
I have Slack channels grouped and catch up on the ones that are more relevant to me and that may have important information that I need to know in the short term, primarily company-wide messages and Support team specific messages.
If I’ve been off for even one day, these are channels, I still then to read or scroll through depending on how much gets posted and the channel. For example, our #company-fyi channel rarely gets posts and will be critical ones, so no matter how many days I’m away, I will read through what I’ve missed. Many of the support channels on the other hand (such as #support_escalations) are focused on working on tickets, so if I’m away for multiple days, I will often mark them as read.
GitLab To Dos
In order to keep my To Do list in GitLab to a low number, I check these regularly.
I’ll quickly mark off items that are group mentions but have been completed, and anything that I’m assigned to since I’ll have those issues either open or see them when I check my assigned list of issues.
For everything else, I can usually tell from the excerpt which ones are more urgent, or faster to do.
On a regular basis, I only get 5-10 To Dos added to my list, so I can typically get through them fairly quickly.
If I need to, I’ll leave certain To Do items to complete later, especially if they’re discussions that require more thought. I often still mark these as done though in GitLab itself, because I know that they’ll show up again in my email.
Ticket follow up
Often we’ll need to follow up on tickets, whether that’s with a simple response, investigating an issue, or possibly trying to reproduce a problem. If needed, we’ll let the customer know we’re looking into it and set the ticket on-hold, so that we’re not “racing” against the clock, since it can take a lot of time to attempt to reproduce issues.
Email and internal issues
Even though I’ve listed this fairly low on the list, I often take a quick look through my email for specific items.
In particular, I look for anything that’s coming from Greenhouse, which is our jobs and hiring platform. We do our best to complete take home assessments by candidates within 1 business day. The system will also send reminders for interviews you have that day.
Then, I usually work through my email by prioritizing internal requests (these are things support takes care of that are requested by other GitLab team members), and again, things that need a more immediate response.
A lot of items that are read-only, I will leave in my inbox until later when I have a spare few minutes here and there, I’ll get through them one at a time.
Read-only items and other Slack channels
We have a number of read-only items but that we’re expected to keep up with. These don’t normally take that long so often, I’ll just fit one in before taking a break or as a break from other work.
Read-only items include:
- our week in review document for Engineering and Support,
- release posts,
- group conversation slides/doc,
- meeting agenda and notes for any meetings that I might have missed,
- other Slack channels that I keep up with but aren’t urgent, and
- tickets that I’m cc’ed on (usually to learn and understand more about the topic of the ticket).
In brief, some of the other Slack channels include product/development groups where I ask and answer a lot of questions, team member resource groups, and the social ones (which are obviously at the bottom of the priority list).
Everything else: learning and “project” work
We are expected and encouraged to take time to increase our knowledge and work on that improve the team or GitLab. Improving the team or GitLab might include (and not limited to) process, documentation, codebase, or internal tooling (for Support or other teams).
It can be hard to find time for either of these, and so we’re also encouraged to block out time in our calendar for these. Personally, I need to start blocking off time on a more regular basis instead of just “finding” it wherever I can.
Still, I’ve managed to complete my training and get my “project work” done in a reasonable time, so even if things could be better, they’re working so far.
The way that I work is not going to work for everyone else. A lot of people require a lot of time to context switch, and focusing on a specific task is always going to be more productive regardless, so blocking off time to do certain types of work is probably the best way to get work done, which is an area I know I should improve on.
Nevertheless, since I was asked about how I get things, I wanted to lay it out, and hopefully provide some insight into the answer.
It took me a long time to get this post published since I started drafting it back in June, but forgot about it for a while, but thankfully, the holidays are a bit quieter and allows for more focused time like writing a blog post.
Thanks for reading to the end and hope you enjoy the holidays (as much as you can)!