From admirer to teammate

Chris Sperandio applied to join Segment in July 2014, a few months before their $15M Series A.

The early Segment team was active in the open source community, and Chris had first learned about them while browsing Segment’s open source projects for his freelance work. Over time, he became such a big fan of the team and their contributions that he decided it was time to apply for a job.

“One day, Segment posted on Hacker News that they were looking for a “success engineer.” At the time, it seemed like a preposterous title to me, but I read the description and felt like it might be a really exciting role—a chance to grow my skillset while helping customers adopt a product I already loved,” says Chris.

So he applied. And after completing a 3-page cover letter and a speedy onsite, Chris started work the very next day.

In this interview, Chris reflects on the challenges of being the company’s first success engineer, how the early team used tools in unconventional ways to move faster, and how data access across every team was critical for their early growth.

Doing things that don’t scale

When Chris joined Segment, he reported to Jake Peterson, who ran Support and Success at the time. The team was just starting to specialize, and Chris joined alongside the company’s first dedicated customer success manager.

One of his first responsibilities was to take over technical support escalations from two of the co-founders, Calvin French-Owen and Peter Reinhardt, who had—up to that point—been the main escalation path. “In my first few days, I was learning a lot about technical specs and, at the same time, getting brought up to speed on relevant domain knowledge for our top customers,” he says.

After a quick onboarding, he jumped into a blended role of fielding support escalations and shipping updates to help resolve them. “At this point in time, we were a small team with a lot to prove. We emphasized white glove service for every customer. So much so that we told ourselves, let’s never respond to a ticket without at least providing a link to something,’” says Chris.

“We used every customer escalation as an opportunity to build new doc pages that could help improve the experience for the next customer. It meant we were making daily additions to the Segment docs,” he says.

“But all of this white glove service was not easy for a small team. I was juggling data problems for Fortune 500s and pre-launch startups. It was a lot. I often struggled with context switching and carving out time to do all of my work.”

At this time, Segment was a team of less than 20 managing 100 partner integrations, 4,000 paying customers, and a few million in ARR. According to Chris, their meteoric growth was in no small part due to their insistence to do right by customers. But it also came with growing pains, as his calendar was packed with ticket response time, deep-dives, and frequent onsite customer visits.

This flow chart shows how Sperandio handled the average technical escalation:

While the process was cumbersome, he ultimately thought it was worth the effort. “I actually think that our relentless responsiveness to do what it takes to win business was one of Segment’s greatest strengths as a company,” he says.

“There’s also a very happy ending to this workflow,” he adds. “We changed it a lot as we scaled: splitting roles so the people responding to a much higher volume of tickets weren’t also the ones instituting fixes.”

Using tools in unconventional ways

Chris notes that the team was “obsessed with automation and building whatever tooling they needed to eliminate redundant tasks.”

One example: managing partner integrations. “Partners are core to Segment. As a business, we built an API for data collection that brings a clean user record to every tool that needs it,” says Chris. “At the time I joined, we had roughly 100 integration partners ranging from data warehouses like Redshift to every tool that requires customer and product data: analytics tools, marketing platforms, ad tools, CRMs, and more.”

But their maniacal focus on user experience meant less time to work on integration landing pages, docs, and other necessary but time-consuming assets. So they automated the work.

Many of their automations centered around a homegrown, all-purpose chat bot. “We called the bot Hermes. Hermes could kick off the build for an integration page, fetch GIFs from the internet, and manage a lot of the integration tasks,” says Chris.

A truly horizontal product, Hermes “partnered” with other homegrown tools to solve problems, big and small. “One tiny problem we dealt with was getting SVG logo files for our partner and docs pages. Some of our partners were small and didn’t have SVGs to share,” he says. “So we built a browser automation tool that, when combined with Hermes, could navigate to 99designs, pay a $5 bounty to convert the logo to SVG, and deliver the final product to the team via GitHub and Slack once it was ready.”

The team built many of these modular, reusable automations across the business. Rather than use a traditional CMS, they built a custom static site generator because the automated steps helped them simultaneously launch more docs, Analytics Academy, a blog, and help section pages with minimal coding.

Chris comments, “We invested a lot of time in systems that would automate anything repetitive or annoying. It was a point of pride for the company at the time. It made a meaningful difference in our ability to move quickly on the things that mattered.”

This affinity to reusability even impacted how they used GitHub. “Almost everything went through GitHub,” says Chris. “We used GitHub as a database in a lot of ways. The partner logos that Hermes made? They were stored in a GitHub repo with directories and all of the integration metadata they’d use to render the logo on the site, docs, etc.”

“Our entire site, blog, and web presence was hosted in GitHub—everyone could make changes in one place. We had this de facto change control system because everything flowed through GitHub,” he says.

Operating on the same data

“One of our most critical advantages as a company was dogfooding our own product,” says Chris. “We wanted every Segment employee to make data informed decisions. People and process were important, but making sure that the right data was available everywhere was also critical.”

The early Segment team spent a lot of energy exposing data everywhere via their automations and plugins. “This ethos created a virtuous cycle for us. We treated data as a service and built plugins to expose it in various parts throughout the org. Dozens of small apps could read from and write to our data sources, and over time this meant we were incredibly fast in building any experience internal employees needed from an operational perspective.”

One instance where hyper-growth required new tooling was when Segment’s integration count tripled to 300 in less than two years. More integrations meant more potential bugs, more surface area for every support rep to cover, and more complicated customer setups to triage.

Even so, thanks to their penchant for efficient internal tooling, Segment’s team was able to customize Zendesk (their support hub at the time) incredibly quickly to help support reps handle escalations better. “We built an app inside Zendesk that pulled in data from a bunch of operational data stores. We aggregated data around integration health and data volumes directly into Zendesk so that reps didn’t need to use another tool or waste additional time searching for information.”

Reflections

In his time at Segment, Chris transitioned from Success Engineering to Product Management, ultimately leading the company’s platform efforts and building the product architecture function.

When asked about his decision to join Segment, he says, “I think when you’re young in your career, like I was, you should be indexing for the quality of the company, the quality of the people that work there, and the learning opportunity. For me, Segment fit this perfectly.”

He also shares how lucky he was to have had the chance to try his hand at Success Engineering. He adds, “I just think there is no better place to be exposed to learning opportunities than the customer success department. I’m a huge advocate for success engineering and support engineering as under-appreciated vectors from which to launch your career.”

Chris' lessons learned

• Prioritize the customer, especially when it’s hard: Customer trust is built across many touch points. Treat these touch points as a chance to delight, educate, and help customers. 

• Take the time to automate away small tasks: Choose your priorities and then invest in tools and processes that minimize manual effort on less important tasks.

• Make data access the default for all teams: Keep your data clean and make it possible for every team to tap in reliably without requiring other teams’ help. 

Are you an early-stage startup? Check out Retool for Startups, a program where you can get a year of free Retool, over $160,000 in discounts from AWS, Segment, and more, and join a community of other startups. Get your free credits today →