Scaling Technical Support: what we heard, and what we think it means

Enrique Gonzalez runs support engineering at Sourcegraph. Aleksandr Veryayskiy is a product engineer at PostHog; support is part of the job, not the job. We brought them together for a fireside conversation at Plain's San Francisco event in March to talk about scaling technical support. They agreed on more than you'd expect.

Support only sees the users who failed

Aleksandr framed the core problem early: support sees 10% of users. The ones with broken environments, confused questions, error logs with no context. The other 90% found what they needed and moved on without a word.

The result is a biased dataset most teams don't account for. Support optimizes for the loudest problems. Product teams receive feedback filtered through that same lens. The majority getting value become invisible.

PostHog's answer is structural: support engineers join customer calls and conferences, not to do support work but to correct the signal. Seeing customers who are succeeding is the only way to balance a job spent entirely in the failure queue.

Product teams don't want your summaries

The standard support-to-product feedback loop: support identifies a pattern, consolidates it, delivers a clean summary. "Three customers this week struggled with the onboarding flow."

Enrique described Sourcegraph's leadership pushing back on exactly this. "We want to see the mess," they told him. Raw tickets, direct quotes, the actual error log pasted without cleanup. Harder to read. Harder to ignore. The signal is in the mess, and filtering it before product sees it means the thing that gets fixed is the cleaned-up version of the problem, not the actual one.

Engineers say they want closer customer connection. The answer, at Sourcegraph at least, is not a better summary. It's less mediation.

Fast release cycles break support

Sourcegraph moved to weekly releases. Enrique was direct about the consequence: the product support learned last Monday is different this Monday. More guessing on tickets, more escalations, more back-and-forth with engineering to understand what changed.

They haven't fully solved it. The partial answers involve tighter internal documentation loops, changelogs written for support rather than customers, and AI-assisted synthesis using embeddings and clustering to surface what's changed and what's causing new tickets. None of them fully close the gap. The faster you ship, the more deliberately you have to invest in keeping support current.

AI agents and the transactional layer

Enrique and Aleksandr came at this from opposite ends, and it was the most interesting part of the conversation.

Enrique's frame is about what sits above the ticket. A specialized agent can now handle known error patterns, feature flag questions, anything with a reliable answer. The support engineer's job shifts to deciding which agent handles what, when a human takes over, and what to build when no existing agent fits. He called this "human agent orchestrators."

Both agreed that human-to-human interaction stays essential for complex issues. Where AI makes sense is the transactional layer: simple requests, feature flags, anything with a known reliable answer. AI makes humans faster, not fewer.

Support autonomy: closing the loop

Aleksandr's frame, which he called "support autonomy," is about what sits below the ticket. The goal is 10x support engineers: fewer people handling more, by closing the loop fully. A customer submits a ticket, the engineer resolves the problem at the source, the customer never sees the back-and-forth. Less escalation, more direct problem solving.

That version of the role requires ownership and direct access that most support teams don't have yet. It also means the job is no longer about handling each conversation manually. It's about building and running the systems that talk to customers.

Different framing from Enrique's orchestrator model, but the same destination.

Developer customers want the explanation, not just the answer

Both of them came back to this point. For most users, "run this command" closes the ticket. For developer customers, the answer without the reasoning is a missed opportunity.

They want to understand why the problem happened, what the fix actually does, and how to recognize it next time. A bot can deliver the command. A support engineer who understands the system can explain why it was needed.

In practice, this looks like walking a customer through the chain of events that led to a failure, showing them where it surfaced in their logs, and explaining the reasoning behind the fix rather than just applying it. That kind of interaction is what prevents the next ticket, and it's what technical users actually value.

Why support teams keep losing institutional knowledge

The two companies run very different models. At PostHog, everyone does a support rotation: HR, legal, all departments. Support engineers are the first line; complex issues escalate to "support heroes," engineers across the company who rotate into support duty. Support engineers also get zero-ticket weeks, dedicated time to focus on process improvements instead of the queue.

At Sourcegraph, Enrique has spent three years building a dedicated support engineering team for a product that runs in environments the team doesn't fully control. Self-hosted instances, no two tickets the same.

The structural difference is significant, but they landed in the same place on what matters: support engineering should be a distinct career path, not a stepping stone. Support engineers who stay get deep enough to build internal tooling, write documentation that prevents tickets, and give product teams real information instead of filtered summaries.

Most organizations don't structure it that way. People pass through on their way to product or engineering, taking institutional knowledge with them. Support sees annual turnover between 30 and 45 percent, roughly three times the US average.

That's not a role you staff with people waiting for something better to open up. The question isn't whether support should be a career. It's whether your organization is structured in a way that makes staying worth it.

What we took away

Enrique and Aleksandr work in different setups with different constraints, but they kept arriving at the same conclusions. Support is sitting on signal that most organizations don't know how to use. The teams that get it right are the ones that treat support as a system, not a queue, and invest in keeping the people who make that system work.

If any of this resonated, we'd love to continue the conversation. Stay tuned for more events!