How we built our support team from scratch

For the first few years of Pylon, our support motion was entirely founder-led. Advith, Robert, and I personally handled every ticket and almost all customer conversations alongside designing, building, and selling the product.

Eventually our customer base and volume grew enough that it wasn’t feasible for us as founders to keep running support ourselves.

Today, we’re sharing how we scaled from founder-led support to a full team of 9 (and counting). We’ll talk about when we decided to recruit our first support team member, why we specifically chose the title “product support engineer,” and the timeline that brought the team to where it is now.

This is the first part in a series where we’ll share how we built our support team, from scaling headcount to creating processes for support to collaborate with other functions at Pylon.

Starting with founder-led support

We’ve seen a lot of B2B companies quickly hire a chief of staff, CSM, or customer-oriented engineer as their customer base starts to grow. That person is the first to handle product questions, until volume reaches a certain point where it makes sense to have a full-time support role.

At Pylon, we intentionally kept customer support as a founder responsibility for a while. There are a few reasons for this:

• With 3 founders, we had enough bandwidth to split all the support work between us.
• Because Advith and Robert led engineering and product, they had deep technical knowledge and could fix bugs or build feature requests themselves.
• Given the above, we never needed to look for engineers who could also take on support work. Instead we focused on hiring very good engineers and continued to do support ourselves.

But of course, we eventually hit a point where founder-led support became unsustainable.

By mid to late 2024, we were consistently averaging 950+ issues a month across 250+ customers. And it wasn't just volume: support started to become more complex as our customers further customized their Pylon instances.

We needed a full-time support person.

Note (1) How do you know it’s time to hire your first support person? There isn’t a perfectly objective threshold here. But if you start to feel like you’re answering questions that someone else on the team (non-founders) can answer, it’s probably time to find your first support hire.

Note (2) Why not hire a CSM? We’ve seen many companies hire a CSM first who can own support, implementation, and onboarding all at once. But as founders, we wanted to stay close to customers and continue doing implementation and onboarding ourselves. If you have fewer founders, you might want to have a CSM before a support engineer.

Hiring our first product support engineer

Like most roles at the time, we looked for our first support team member in-network. Advith reached out to previous coworkers from Samsara, and we got connected with Jon Clark.

Jon officially joined in October 2024 as our founding support engineer. Within his first few weeks, he was handling 200+ issues and responding so quickly that customers kept assuming he was a bot. In Q1 of 2025, he handled 1,115 support issues himself.

You’ll notice at this point that we call our team members product support engineers or support engineers, instead of customer support specialists. We’ve thought a lot about this role title, and there are a few main reasons we chose product support engineer:

1. Structurally, we wanted the support team to sit very close to product and engineering. Our support engineers today have deep product knowledge, work directly with engineers to fix outages, and are heavily involved in improving our product.
2. We typically think of support specialists as handling more transactional support (this title is common in a lot of B2C orgs). But as a B2B company, our team is supporting long-term accounts across tons of complex setups and use cases. They have to quickly dive into different customer environments, understand account context, and debug technical issues.
3. We wanted team members who had an engineer’s mindset. Besides being good at interfacing with customers and handling support volume, we wanted our support team to actively build the systems that would help them scale. This could mean configuring AI to deflect tickets or thinking about how AI tools can accelerate their work.

From there, we kept scaling the support team as our customer base and volume exploded.

Note (1) Where do you find your first support engineer? We were lucky to meet Jon through a mutual connection, and we still think looking in-network is one of the best ways to find founding team members in any role. But there are other places you can find people specifically in support, like the Support Driven community or Customer Success Collective.

Note (2) What should you look for in your first support engineer? We think it makes sense to hire someone a little more technical. Someone who can quickly ramp on your product, work closely with engineering, and start building out the systems (like automations or AI workflows) to scale support operations.

Growing to a team of 9

In February 2025, we brought on Matt Nagy as our second product support engineer. By then the team was handling 1,500+ issues a month and supporting over 400 customers. We steadily grew the team as we needed the extra support:

• By April, we had 4 team members supporting 500+ customers. On the product side, we had expanded Pylon with AI assistants, AI agents, and an advanced analytics platform.
• By September, the team was 5 people supporting 800+ accounts across 4 product SKUs (+ Account Intelligence). We needed someone to lead hiring, enable cross-team collaboration, and build sustainable support models as we scaled to support enterprise. Jon became our Head of Support.

Today, Jon is leading a team of 8 support engineers (with more joining in the coming months!). The team is supporting thousands of customers and handling well over 5,000 issues each quarter.

Next in this series, we’ll talk about how Jon has created structure and processes to help the team scale: How we interview support engineers, building out on-call and follow-the-sun models, and using AI to accelerate everything.

‍