Webinar: Cask Vulnerability Reporting: Closing the Mac Fleet Security Gap
Register now
Cover illustration for blog post A Day in the Life: Support Engineering at Workbrew

A Day in the Life: Support Engineering at Workbrew

Kitty Shephard & Petros Amoiridis

Culture

Petros has spent nearly half his career in support. He started programming at 11, went pro in 1998, and later ended up in support, almost by accident, at GitHub. Now he's crafting and driving support at Workbrew from his home in Greece. I sat down with him to see what a day in the life of support engineering looks like. 

Walk me through the first hour of your day. What's the first thing you look at, and how do you decide what to tackle first?

The first thing I do in the morning, after coffee of course, is check Slack and GitHub to see what's happened overnight. Being a fully-remote team, I need to catch up on what's been merged, or new things that could create a support load before it reaches me as a ticket. Next, I open our support helpdesk to see if there are any inbound requests. There usually are, so I read through all of them first before ranking them by urgency. If there's anything that needs to be escalated internally, that's the best time to do it. We have an internal “Engineering First Responder” process that automatically pings who is on-call, and it's a weekly rotation from a pool of most of our engineers. After that, I start working through the requests one by one.

Maintaining a 100% reply time goal is no easy task. How do you keep response times fast?

Living in Greece, my time zone is close to our customers in Europe, but not so close to the ones in America or Asia Pacific. Since the support team is still small, I shift my working hours a little to cover more of the globe. Beyond that, I enjoy being customers' first point of contact, reaching out quickly to start understanding the issue, even before I have the answer. There's nothing worse than contacting the void. We do measure ourselves against an internal SLA of 48 hours for resolution, and in June we hit 100% on both first response and resolution. 

You started your support career at GitHub, working support for an enterprise-scale product. Now you're at a startup. What's the biggest difference in how you actually get to help customers?

At a bigger, more established company, support and engineering are usually separate worlds. You don't have access to the codebase, so if something's broken, you file an issue and wait for someone else to look into it. Here at Workbrew, those walls don't really exist. I have direct access to the product code, so I can go read the code myself and see what's actually happening. Once I've dug in, it usually lands in one of three buckets: expected behavior, a product opportunity, or a bug. For those product ideas, I open an issue for Product to evaluate, scope, and prioritize. Some are easy fixes, some point at something deeper that needs real conversations with customers. For bugs that are obvious and small, I just fix it myself. Open the pull request, tag someone for review, done. The customer gets a fix fast, and there’s no ticket-and-wait cycle. More complex issues, I write up properly and hand off. This is definitely a benefit of working for a start-up, which allows us to move quickly and make sure our customers aren't left waiting.

In a fully remote, async team, there's no built-in "end of shift." How do you decide your day is done?

I like this job more than is probably healthy. Closing the laptop is genuinely hard for me. I make myself do it anyway, because if I don't, I show up wrecked the next day and that's worse for everyone. 

As a young company, you wear a lot of hats. What's one that has nothing to do with "traditional" support, and what has it taught you?

Docs, weirdly. We link every support request to an internal GitHub issue, so when that issue closes, everything linked to it pops back open. That's basically my reminder to go update something or tell a customer their fix is shipped. When my queue's empty I'll go back through recent requests and audit our docs: is that information up-to-date, or could it be clearer. The trick is doing it right after the ticket, while it's still fresh. 

But that’s what really delights customers is telling them "that thing you asked for, it's live now." People remember that, and so do I – that has stuck with me the most.

Share this post

Never miss an update

Subscribe for the latest blogs, events, and exclusive content—delivered to your inbox.

We use cookies to analyze traffic and improve your experience. You can accept all cookies or decline non-essential ones. Read our Privacy Policy for details.