Support Engineering | Lessons learned building a team during the pandemic

From 2019 to the end of 2021, I created and scaled our Support Engineering team at Finix. These were fun and trying times during the peak of the pandemic. I wrote this piece to reflect on my time leading Support Engineering.

It was a unique and privileged opportunity to hire, train, and mentor the different Support Engineers that joined Finix. I’m forever grateful for the team we built and all the hard work we accomplished.

What is Support Engineering?

Support Engineering is different in every company, but a few things are usually consistent across companies:

• Highly technical support team
• Incident Response
• Get sh*t done group for customers

A support engineer usually spends their day looking at technical problems asked by customers or pre-emptively based on alarms. Questions can range from integration related to a specific question about a scenario that may require hours of research.

What tools do Support Engineers use to solve problems?

Customer Tickets

Zendesk is usually the tool companies use to track tickets from customers coming in. Freshdesk is also a great alternative.

Internal Tasks

Internally, Support teams can use Jira to keep track of items asked by other teams that don’t come in via support tickets. Having tickets to keep track of these items at scale is essential.

Looking at logs

Scalyr or Datadog are standard tools companies can use to dig into logs or exceptions that might have occurred.

Looking at Data

Data analysis differs heavily across companies and startups. From raw SQL to complex data warehouses, the breadth of options is vast and mainly tailored to the current data stack of the startup.

How does Support Engineering differ across phases of a Startup?

Seed

In the Seed stage, Support Engineering teams mainly work on supporting a handful of accounts in Enterprise software. The team is small, and everyone is intimately aware of each other’s work.

Series A

Scale problems start to emerge in the Series A stage. You have more customers integrating and have to streamline our internal support systems. Series A is where a team becomes a department.

Series B

Scale and scope start to increase in the Series B Stage. A big part of the phase requires clearly defining roles and responsibilities between and within department groups. Everything is about getting the company ready for explosive growth or hyper-scale

I led the team from the Seed to the Series B stage. Once we started scaling, the leadership team and I decided to recruit externally and bring in our talented new Director of Support Engineering, Song Chin, to scale the team.

Highlights

1. Mentoring and growing Careers

Mentoring and growing the careers of my reports is my biggest highlight in leading Support Engineering. Some of my past reports have transitioned to Product Management, Engineering, and DevOps, which fills me with joy that I contributed positively to their career.

In addition, our team had a diverse background that inspired me daily. For example, we had someone for whom Support Engineering was their first full-time role at 19 to a seasoned teacher looking to transition into tech after a boot camp. I sought a 50/50 gender ratio and was able to accomplish that goal for most of my tenure.

2. Getting to know customers  well

Part of the fun of the early days of Finix for me was getting super close to our customers. Knowing their day-to-day life, pain points, and visions has made me better in my new product role.

3. Doing a little bit of everything

Being a support engineer is doing a little bit of everything. From helping customers solve a problem not directly caused by your software to teaching other teams about payments, you do a little bit of everything. No other role has the span of Support Engineering, especially in the Seed and Series A stage.

Lessons Learned

1. Investing more in processes

A big part of leading a team is administrating and optimizing the team’s tools. For us, that was mainly Zendesk and Jira. While I am very familiar with a great Jira workflow, Zendesk was something new to me. During the pandemic, tooling was extremely important as we went fully remote.

If I could go back in time, I would’ve found a mentor in Support Engineering at another company to help me design a thoughtful Zendesk deployment at scale. I never really saw what a good Zendesk workflow looks like, so I was flying blind.

2. First-time manager pitfalls

During my tenure, I fell into some of the classical pitfalls of a first-time manager. Defining clear roles and responsibilities, managing up, and holding everyone to performance standards were some of my earlier challenges as a manager.

Luckily, Finix took the time and investment to pair me with a fantastic Executive Coach. Steve Schreck coached me through some of my first-time manager problems and directed my attention to areas to grow and improve.

3. Not building tiered Support

To provide the best customer experience, I should’ve created a small non-technical support team that only worked on incoming tickets and triaged them to the right tier of Support. This would have provided faster ticket close times and resulted in a more efficient team.