For the past 20 months (more or less), I have been working with the support team at heroku.
Because I am moving to something new (still at heroku), I want to share how I got there and a few things that I learned.

How I ended up in support

All the companies I worked with before joining Heroku were startups. The biggest one I had worked with was around 25 people, 5 of which being engineers.
So when 2 years ago I wanted to change and do something new, I sent resumes. But applying for a senior engineering position in a big platform can be a bit overwhelming.
Support is a section which, from the outside, appears to be easier to join. So applying there gave me the impression I would increase my chances of being hired.

While support ended up being fairly different from what I expected it to be, I regret nothing.
I had never done support before, and I’ve discovered a ton of things by communicating with customers and analyzing performance problems.
If I had to do it again, I wouldn’t hesitate a second. And, as you’ll see further in this article, I highly recommend anyone to do it too.

Gosh, I need to talk to customers

Oh, and I have to talk to them in English (of course, that didn’t come as a surprise).
While my english is relatively good, it’s not my mother tongue and all the companies I had worked with before were French companies where all the communication I had to do was in French.

English is not to be the biggest thing though. It happens a non-negligible part of support is investigating a ticket to tell the customer with the nicest words possible the issue is with them and we won’t fix bugs in their own code.
It took me a bit of time to find the right words to tell customers a problem is their fault without making them angry.

Typically, in a rails app precompiling the assets create a manifest.yml file which we use when your app is deployed to avoid recompiling them if that is not necessary.
We fairly frequently see customers inadvertently precompile their assets locally, push the change and later in the future think we aren’t updating their code anymore when in fact, they are just always using the same precompiled assets.

On another note, an app with a few long-running requests (one can sometimes be enough) will get timeouts. Such issues are not platform issues, but problems in the customer’s apps. Specifically, they should fix the slow requests and add timeouts.

Once I understood the right language to use to explain things to customers, support is an awesomely interesting position to work at.
In order to support people who don’t necessarily understand your platform, you need to understand it yourself, which very often includes having to dig into internal components’ code (sometimes in languages you’ve never practiced).

Being able to work with a distributed multi-teams engineering organization has taught me more in around 2 years at heroku than in 8 years working at startups before.

A support ticket is a bug

We have this interesting approach at Heroku where onsider the best support experience is the one you don’t need.
With that in mind, we’re trying to build a lot of internal tools to help you even before you open a ticket.

For example, we’ve noticed we’re getting a lot more tickets when an incident is occuring, which does make sense. When the tool you’re using is down, the first thing anybody does is notify the team behind to have them crawl under support tickets so they’re unable to fix the actual issue.

If you tried opening a support ticket during an Heroku incident, you would see a big red banner showing a link to the current incident with the last comment posted. We’re seeing a high decrease in the number of tickets submitted related to an incident as soon as this banner is displayed.
People know we know and they move away, following the incident and waiting for resolution, allowing us to actually focusing on communication on that same incident page and not just to answer hundreds of tickets asking the very same question.

Similarly, we’re seeing a fair number of people open tickets after improperly configuring their DNS.
Based on that, if you start opening a support ticket and mention words like “DNS” today, you will see a link going to a tool which will analyze your DNS configuration and let you know what problem there could be.

Everyone I’ve talked with about this approach was impressed, which makes me think it’s a fairly new one. And it’s one which makes a lot of sense. Support isn’t only answering tickets anymore. It’s actually about improving the platform, based on actual data (customer tickets).

Support is not only about tickets

When joining Heroku, I thought all of what support would do would be about answering support tickets.
Of course, this was not all. We have a fairly evolved incident response framework where public communication is handled by our support team.

It’s actually quite logic when you think about it. Support is writing messages to customers all day long. Who better to do the same thing during an incident?

Working incidents from the public communication side has been one of the most eyes opening thing for me.
I understood what doing incidents retrospectives means, and how to better improve myself by reflecting on what happened and how it could have been done better. Notably with the A3 method.

Engineering

The support team at heroku is a bit specific in its kind, as all our customers are developers, and most of the tickets we’re dealing with are about investigating performance issues in an app, understanding what happens and pointing the customer in the right direction so they can fix it.

Because of that, everyone in our support is a developer.

This is why we try to empower everyone in the support team to spend some time on engineering work.
We have several internal projects helping us answer support tickets which are built on this engineering time, including our entire support platform (see my ember to rails article).

In those two years in the support team, we went from using a very well known SaaS tool to building, using and maintaining our own platform.
Even though we aren’t building the heroku platform per-se, we are building an indispensable tool, with its own contraints, like being extra available even when there is a platform incident, as that’s when customers try to communicate with us the most.

Do it too

As I said before in this article, working with the support team at heroku has been an awesome experience, probably the best one I’ve had in a job so far.
I’ve seen some small companies where everyone does support on a rotation. Some bigger send new engineers to support as part of their onboarding.
Other companies (like Heroku), have every engineer do support for tickets escalated to the parts of the platform they are responsible for.

No matter how it works better for you, I highly recommend you to spend some time doing support. That will give you a very different view on how your customers are seeing your product and how you can improve it.

What’s next

Starting next monday, I am joining the “Build and Languages” team, where I will be working on everything that happens between the moment a new build is pushed (either using git or our platform api) to the moment the slug is released and the new version is ready to be started in dynos.

It is a whole new challenge where I will still be doing tickets, even though they will be escalated and more specific to the area I’ll be focusing on.

En conclusion

In-fine, I can say working in a support team has been a lot of fun and unexpected things learned. I’m happy to go back to building complex systems, with this gained experience in my bag to help customers have an even better experience of those tools I’ll be building.