How Fastly Builds Support, Part 1: Our Standards

This blog post was originally posted on my personal blog. Check out Part 2, Part 3, and Part 4.

One of Fastly's greatest product advantages is our support infrastructure. We get compliments and positive feedback nearly every day through tickets, tweets, and old fashioned conversation. When we run case study interviews with customers, support is a common factor in why people choose Fastly over other providers. This is something we take pride in, and something we love to brag about.

This culture of support and service isn't an accident. Our support processes span the entire company, and are baked into every aspect of the way we do business. We worked hard to build our support infrastructure (our processes are so broadly encompassing and involved that calling our support an "infrastructure" is the only term that feels right) to scale without sacrificing quality, timeliness, or the soul that got Fastly where it is today.

In the time I've been at Fastly, we've had enough customers and friends ask us about how we do support and what's going on under the hood that it seems appropriate to give a high level overview of how we build, what we've learned, and how other teams can borrow from our setup.

The context

When you look at Fastly's support, you have to start by looking at the context surrounding the company.

Infrastructure vendors historically have bad support experiences, unless you're spending something huge — think budgets in the tens of millions. Even then, support is viewed as a cost center — the vendor's goal with support is for the customer to go away. If a customer going away is the result of them solving a problem, that's a plus. But the goal is to make the customer go away, solution or not. If you don't believe me, talk to your head of ops.

Because Fastly is a company founded by operations engineers, for operations engineers, having par-for-the-course (i.e. bad) support isn't acceptable. Fastly's founding team set out to create the support experience they always wanted from a vendor.

The catch is that every startup begins with this goal. I've never met a business owner who feels like their company should have bad, or even mediocre, support. They all claim they want the best. That said, we've all seen cases where companies grow and become successful, and their support inevitably goes down the tube. That pursuit of "the best" has been sacrificed, either intentionally or as an unfortunate side effect of other decisions.

I can't comment on other companies and their circumstances, but I can go into detail about the culture and processes that Fastly has in place to prevent this.

The early days of yore

In the earliest days of Fastly, we made some very crucial decisions about how we would approach support as a company.

From the outset, support was considered a profit center, rather than a cost of doing business. Fastly theorized that great support would generate more business than any sales force could in the earliest days, and approached setting up support with that in mind. It turns out that theory was right, and customers flocked.

In the operations world, reputation is everything. Fastly already had respect in the community through the early team's technical reputation, but their support reputation became world-renowned in quick fashion.

So, what actual decisions were made to set the foundation?

In the early days of Fastly, everyone joined in on support. Engineering, ops, network engineers — they all took tickets they could answer, helped as quickly as possible, and communicated as honestly as they could.

Everyone shouldered the support burden, and took pride in delivering a great experience. The experience was so valued that people even "competed" to take tickets first. Great support was baked into the culture. Fastly's early employees had all run into horrible vendor support in their previous jobs, and were determined to do the opposite in their time at Fastly.

The people who shipped product answered the tickets about their features, wrote documentation as needed, and made sure customers got the full benefit of Fastly. When new customers came in, everyone pulled together to make sure the migration went smoothly. It wasn't farmed out to a specific individual, and the customer wasn't just left to their own devices. Infrastructure migration often needs extra help to make the process go well, so everyone chipped in. The customer's success was viewed as Fastly's success.

A buzz phrase in the startup community these days is "do things that don't scale." Fastly did this with support. It's not scalable to have your entire team onboard single customers. It's not scalable to have your CEO assist in real time over IRC. It's not scalable for everyone to give their full effort to make sure the customer has a great experience.

But during those early days, we did start scaling, and we did so very successfully. We started building the tools, resources, and everything else necessary to make sure this quality could be extended indefinitely as Fastly grew.

I said it earlier: Fastly is a company built by operations engineers, for operations engineers. Ops scales applications. Ops plans capacity. Fastly scaled and planned for capacity with support in this same way.

As an aside, many support teams are avoiding the concept of "scaling support" outright, as "scaling support" often implies cutting corners and removing the human touch that makes so many organizations successful. This should more accurately be considered "scaling support poorly." When Fastly scales support, we make the conscious effort to preserve the most essential aspects. If those aren't preserved, we view the scaling efforts as a failed (but valuable) test and roll back.

Up next

Part 2 of this series goes into the decisions we made early on as an organization, the lessons we learned in the process, and what we've done to expand our quality of support and customer service.