From the Trading Floor to Shift-Left: What Production Support Taught Me About Products

Early in my career at HSBC, I supported FIERCE, an internally built execution and routing engine that let traders in London and New York execute fixed-income trades on live Bloomberg and Reuters feeds. When something went wrong, nobody needed a dashboard to tell you. The trading floor told you.

I have since moved through delivery and product roles, but that early work shaped how I judge products. A launch is a date. Reliability, recovery and support are what customers actually live with.

Lesson one: recurring incidents are product feedback

At HSBC I provided L1 and L2 support, led root cause analysis on recurring incidents and automated process and system health checks. Automating checks was useful, but the bigger shift was in how I thought about repeat problems. An incident that returns is not bad luck. It is the system telling you the same thing twice.

Later, at Infosys, I led a 10-member offshore team managing integration and production environments for Bank of America applications. Unstable environments, deployment dependencies and inefficient branching were hurting testing readiness and releases. We introduced branching optimisations, issue trend analysis and proactive operational controls, and IT incidents fell by 60 percent.

Lesson two: structure beats heroics

At Rage Frameworks, supporting products for large banking clients, the problem was an unstructured support environment. Incidents recurred and first-call resolution was slow.

The answer was not asking people to try harder. We established an ITIL-based support framework, ran business continuity and disaster recovery exercises, made work visible with Kanban, and introduced Business Incident Reports for proactive trend analysis. First-call resolution improved by 80 percent and incidents fell by 60 percent.

Heroic support feels impressive, but it usually means the design has already failed. A good support model should make ordinary people effective on a bad day.

Lesson three: agreements between teams matter as much as tools

At Capgemini I led offshore support for around 30 Morgan Stanley entitlement and remediation applications. Alongside continuous service improvement and disaster recovery planning, one of the most valuable pieces of work was developing Operational Level Agreements. They improved operational efficiency by 60 percent because teams finally knew what they could expect from each other.

Lesson four: move ownership closer to the builders

All of this eventually led me to shift-left. At Service NSW, after the organisation changed, product teams took on ownership and support of their own products at L2.5 and L3, with requests moving through formal ServiceNow tickets into their queues.

The handover mattered as much as the model. We ran workshops to explain why it was happening, what would change, what would not, and how we would measure success. We shared Root Cause Analysis and Post Incident Review insights so teams could act on them, then followed up with emails, newsletters and updated knowledge articles. Our Q3 2024 CSAT was 100 percent, and shift-left became the operating model.

A simple support health check

• Are health checks proactive? Users should not be your monitoring system.
• Is disaster recovery tested? A plan nobody has run is only a theory.
• Are L1, L2 and L3 clearly defined? Ambiguity costs time during an incident.
• Do trends get reviewed? Closing tickets is not the same as learning from them.
• Do builders see Post Incident Reviews? If not, the people best placed to prevent a repeat will not know about it.

Customers rarely separate the product from the support behind it. If something breaks and is fixed quickly and honestly, trust can survive. If it breaks repeatedly and nobody seems to own it, even a well-designed product starts to feel poor. That is why I still think some time in production support is one of the best educations a product manager can get.