Six months ago, I wrote a naïve definition for customer engineering. I (largely) stand by it today. A thousand support tickets and dozens of incidents and code fixes later, this is my How it started vs How it’s going.

How it’s going

In March, Opus 4.6 had just launched and I had just turned superhuman, prompting AI with questions and code. Tokens were expensive. I bemoaned my quotas, but looking back, token scarcity was a blessing. Now, there are too many customers and too much code. Tickets and commits have become a firehose. I rarely directly read tickets or code: I work through agents to write my replies and commits. Intelligence is almost too cheap to meter, so token scarcity has been replaced with attention scarcity.

On the other hand, support load is escalating because everyone is shipping faster: our team, customers, vendors, and even target websites. Constant change means constant breakage: nearly half of support tickets are bug reports or incident escalations. Last week, we had 8 incidents. Often, customer engineering learns about new features when customers ask us to debug them. The sheer amount of product context needed to resolve or even triage issues has grown with the codebase, and context swapping exhausts humans. i-have-adhd isn’t enough when your entire workday is an 8-hour agentic ELI5.

We are hiring as fast as we dare, but the only thing more expensive than human context swapping is human coordination & communication. We are limited. I am limited. Faced with this ceaseless, careening forward momentum, how do we keep pace?

Where we’re headed

Knowledge work is dead. “Eric is a developer because he knows how to code” is dead, because now, anyone can code. Knowledge work is now done through agents: coding, contract review, even incident debugging. Instead, it’s “Eric is a developer because he can translate business needs into systems and will own that system.”

Humans are responsible for translating needs. Individually, translating needs means having empathy for customers and teammates. But at scale, it means having effective communication. Clear communication matters even more because agents have made prose a token commodity. Because process can just be cheaply codified, humans should focus on defining good protocols: conventions between ourselves so that the overloaded human recipient can easily understand and act on your requests.

Second, you are responsible for owning outcomes. At scale, this means context. However, product and company context is changing too fast for individuals to keep up. Instead, we must split out the context to human-size chunks and entrust the human to make the best decisions. Ownership arises from our human limits: it becomes who needs to be in the room, not who gets to be. It’s who will live with the decision and its consequences.

Concretely, what does this mean for customer engineering? Let’s map these responsibilities across customer engineering’s two core interfaces: customers and product.

Customer

Comms & protocols

I still believe in customer obsession, but support volume and complexity are forcing us to change.

Support is basically half Q&A, half issues. Q&A is easy: 50% of our volume, but <10% of our time. The real load is product issues: incidents, bugs, or features. Communication around issues is more complex than the product itself. To paraphrase Tolstoy, All happy customers are alike; each unhappy customer is unhappy in its own way.

Customers do not want to debug those issues over human-gated text packets. I’ve had many conversations with customers where we are meat-proxies for our agents. We need to do better; we need a product-embedded support agent and a customer-facing issue tracker.

The support agent should be the first responder, the one customers can work with directly (over web, MCP, email, or Slack). Many, many customer issues require privileged access to customer data (credentials, BYO proxies) in order to fully debug them. Especially when the issue repros require credentials or session cookies, being able to programmatically request access from customers would not only allow agents to create better reproductions of issues, it would allow us to verify fixes.

Finally, customers want to track the throughput and velocity of all issues they’ve logged with us: threading replies in Slack is no longer sufficient. Just like product teams use Linear (or similar) to track progress, we need to (and customers want us to) work on customer issues, not customer tickets. Customers will prefer agents over humans for timely, accurate updates, so long as they know they can always escalate to the most qualified human when needed.

Moving from prose to protocols will allow us to move from email and Slack to OAuth token grants, verified repros, and code fixes, lowering the barrier between company and client while maintaining trust and security.

Ownership & context

Customer ownership is being responsible for deepening customer integration by earning trust. You’re not just waiting for them to write in with bugs; you’re using customer tickets as an early signal that something is wrong. When a report comes in, how can we:

1. Use telemetry to scope impact
2. Work on the fix with product
3. Broadcast the fix to all affected customers (not just the ones that wrote in)
4. (Optionally) update docs/onboarding

Sidenote: Ownership most clearly manifests in incidents, which get their own section below.

Critically, customer ownership is not about driving revenue. Customers will buy because the product is good. Nor is it about stopping churn. You cannot stop churn any more than you can stop incidents. Bugs and incidents are harbingers, but they are imperfect in an industry like browser infrastructure, which is inherently more complex and less stable than API companies like Sentry. Use churn to diagnose our problems and apply the learnings.

Our competition is that customer’s own engineering team, and our job is to be more trustworthy than their in-house engineers at running their browser workloads. Kernel is cheap enough ($30/month) that any serious customer can pay; how much they pay is a function of their business, not ours. Earn their trust, and their spend grows with their success as they migrate more workloads to us.

Product

You can’t change people, but you can change products. Customer engineering’s promise to product is to communicate context to product over clean protocols. Customer engineering does not design the product. Product is about intention and market positioning. Customer engineering is about the shape and flow: how customers actually integrate the product, and how issues move between them and product engineering.

Comms & protocols

This is the hardest interface in any organization, where standards and protocols must be upheld, because it’s this relationship that almost always degrades as organizations scale.

Issues should not mandate and obligate the reader but invite and excite them. At so many companies, GTM gets frustrated that engineers don’t prioritize their issues. And yet every great product engineer yearns for impact, to work on something that matters to the business. It is our job to communicate why it matters.

The protocol: every issue needs a max 280-character tl;dr, followed by a max 1,000-character body. It ideally has a visual to illustrate the problem: a diagram of the user journey or a chart showing the problem. Information meant to be consumed by agents (repro steps, logs, agent transcripts) should be included in the attached documents.

With all issues, we should attach priority, which I define as urgency × impact:

Urgency

• Urgent: Incident
• High: Blocking
• Medium: Necessary, but customer has workaround (for now)
• Low: Nice to have

Impact is measured by revenue. We tag all our issues with customer requests and customers with their revenue. Revenue helps us prioritize operational impact; earning customer trust remains the goal.

Agents will draft issues, but you are held accountable for them. Product engineering can and should turn away issues if they do not meet this standard.

Ownership & context

Customer engineering is moving to product specialization, orienting itself around the product itself. This means product meetings should be attended not by customer engineering leadership, but by the customer engineering specialist for that product. Their job is to run customer operations: owning customer feedback, escalating and prioritizing issues, and communicating changes to customers.

Especially important here is feature launch, the twin to “customer deployment.” When larger customers integrate Kernel, we dedicate solution engineering resources to ensuring deployment goes smoothly. In the same vein, new feature launches need a customer engineer partner: every launch brings with it a new category of support load. Customer engineering needs to set up the systems (code or skills) to automate debugging. Browser Telemetry is a clear example of this: the product itself must be engineered to be debuggable.

Incidents

tl;dr: failures the system detects page product engineering. Customer escalations page customer engineering when they clear the revenue thresholds below and no incident is already open. Product engineering can also page customer engineering when it needs help working with customers.

Two questions decide an incident: what detected it (input), and what comms need to go out (output).

Input: who gets paged

Detected by the system (a database is down, an API server flaky): product engineering is paged and handles it, including status page updates. Customer engineering is pageable if the issue has business implications, but is not automatically paged whenever a server metric looks problematic.

Detected by customers (failures specific to certain domains and workflows that the system can’t see): reports trigger an agent investigation. Logs or telemetry should establish that a failure actually happened; a repro isn’t required. If there’s no outstanding incident, page customer engineering when either holds:

1. Customers representing more than 1% of our revenue are likely to escalate the same incident.
2. Customers representing more than 5% of our revenue are escalating failures in general, even if we haven’t established a common cause.

The first threshold looks ahead to likely escalations; the second catches a surge in escalations already happening. Anything that doesn’t clear the bar goes to the next-business-day queue, investigation already attached. Traditionally, escalation has only been granted to our highest support contract, but over time this should include all customers, including self-serve.

Output: who talks to customers

• One-way (status page): the customer is notified but can’t reply. Product engineering’s on-call posts the update and keeps working the core problem. Customer-facing follow-up can wait for the next business day.
• Two-way (Slack, email): product engineering decides whether it needs customer engineering to work with customers. If it does, it pages customer engineering and brings them online.

Canaries

The self-serve base is our canary in the coal mine. A handful of self-serve customers all saying that proxies are broken is an early signal, hours before the rest of the customer base hits it. Their reports are a sample, not the total. They kick off an agent investigation to assess whether either paging threshold is met:

1. Aggregate. Cluster the reports into one issue. Random feature or billing questions never page anyone.
2. Scope. Query telemetry: which other customers share that proxy type, region, or workflow and might escalate the same incident? Also track the total revenue represented by customers escalating failures, even before we know whether they’re related.
3. Verify. Establish the failure through logs or telemetry. The support agent can ask customers for access to customer account resources to investigate and, when useful, reproduce it.

If either threshold is met and no incident is already open, page customer engineering. A stitch in time saves nine. And if the same failure pages us twice, it should become product engineering’s monitoring, not our recurring incident.