Engineering Support Processes

Escalated support kind of just happens in an early startup, and it does not go away. We had it at Shopify too. In the early days, it is everyone answering customer emails, watching for bugs, and trying to patch holes. Eventually, you bring on an extra layer between your engineering team and the customer: Customer Success, Support, or Product Managers. You want to be intentional with the next step. Usually, there is so much easy context sharing among a small team that the customer success person can go to most engineers for anything that requires technical ability, i.e. escalated support. However, as the system scales, this breaks.

Context and Deep Work

Early on, you might try a round-robin for escalated support. It will work for a while. If your product is working and you are moving quickly, it will continue to increase as fast as, or faster than, features are released. Remember your multipliers are new customers and features released.

The first move is simplest: introduce an escalated support shift. It is typically a week in length. This engineer will handle any escalation. Other engineers can mostly ignore the support queue. It lets them return focus to building new features in depth.

The most common mistake at this phase, learned from experience, is losing context week over week and not measuring. If the same root cause pops up every week, it may not get noticed because every week it is another engineer. In fact, you could be sinking a lot of hours into a problem that should be a dedicated project.

At Convictional and Integral, we would start tagging every support request into buckets. It began to highlight weak areas of the product. You could also estimate time spent on any particular issue.

This problem does not go away. At Shopify's scale, your team still owns an area of the codebase. Customer complaints, bugs, alerts, or technical regressions will appear. We copied the same pattern.

AI

The modern question: does AI solve this? Not really. It is great to feed an AI with a bunch of context to hunt down the root cause of a problem. However, you still need an engineer in the loop.

You may consider giving your first-layer / CS team access to vibe code a solution. Technically, it works, but you will still require a code review. You do not want to throw slop at your engineering team because it ends up wasting more time. If you believe code reviews are not required, you need an engineer in the loop at some point to avoid drift from a desired style and architecture.

Early in the days of GPT-3, we fixed most escalated support issues with a migration against the production database. We built a tool to go from English into a Mongo update query, then it would post a pull request to the codebase. It worked because there was still a review step by an engineer, and it fit into a simple standard operating procedure (SOP). Generally, we tried to make everything fixable in the app, and if it was not, it was because we had not built it or did not need to.

Today, I would do something similar. Give a coding agent a clearly documented SOP for resolving the issue and how to fix it in the production database. It would create the migration script that gets reviewed by an engineer.

The Answer

You are here for the answer, if I was doing this in 2026.

I would have a single escalated support queue / resiliency backlog where everything has a correct priority. Each item in the queue is tagged into a bucket.

Next, a dedicated engineer works through the queue ahead of project work. The engineer should document time spent on each issue. If it hits the escalated support queue, the outcome of every issue should be an SOP, better alerting, or a code change. It is the only way to slow down the exponential growth.

Set an upper limit on the queue which triggers a "Code Red". If the queue grows too large, you do need a moment to stop new feature work. At Shopify, we had this called "Pit Stop". It stops you from deploying new features.

Every Monday, I would run a handover meeting where the inbound eng, outbound eng, and eng lead go over escalations from the previous week.

Finally, when picking up new project work, I would ask your Layer 1 where you should focus to reduce supportability. At Convictional, we would work on about five features at a time across all of Engineering. We would make one of them something related to support or technical debt.