Support engineering
Enterprise Application Support & Technical Troubleshooting
There is a category of problem that ordinary support tiers cannot close: intermittent, environment-specific, spanning more than one system, and reproducible only under conditions nobody has characterised. These tickets tend to sit open for weeks while each team establishes that it is not their fault.
Escalation-level troubleshooting has been my job for most of my career — at Workday for Adaptive Planning, at LinkedIn as SME and technical customer contact working with Tier 3 and Product Operations, and at eClinicalWorks handling escalated calls alongside cloud database operations for US medical practices.
Where I can help
- Root-cause investigation on issues that have already defeated first and second-line support
- HAR file and browser DevTools analysis for anything failing in the request path
- Log analysis across application, integration and infrastructure layers, including ELK Stack and Kusto
- Database-level investigation, including MSSQL performance troubleshooting, upgrades and migrations
- Establishing reliable reproduction steps for issues currently described only as intermittent
- Post-mortem analysis and the written technical evidence needed to escalate credibly to a vendor
Finding the pattern rather than closing the ticket
Individually resolved escalations are worth much less than knowing which failures keep recurring and why. At Workday I worked ELK dashboards to spot patterns across open Adaptive Planning cases, which shortened detection time on recurring faults and lowered mean time to resolution.
At LinkedIn I built escalation trend reporting that gave Product a ranked, evidence-backed view of what was actually breaking, which fed directly into fix prioritisation — and turned repeat cases into Tier 1 enablement material so the same issue stopped reaching senior support.
If your support queue keeps surfacing the same class of problem, the useful engagement is usually characterising the pattern, not resolving the next instance of it.
Why written evidence matters
A large share of stalled escalations stall because the evidence is not good enough to act on. 'It is slow sometimes' is not actionable. A timeline correlating a specific slowdown with a specific query plan, log sequence and payload is.
Much of the value I add is producing that artefact — which is useful whether the fix ends up being yours or the vendor's.
Background
Beyond platform support, I hold a Master of Computer Applications from Christ University and have published peer-reviewed research on Android background services and unauthorised access detection in a Scopus-indexed journal, which is a reasonable proxy for how I approach an unexplained system behaviour.
Common questions
Can you help when the vendor says the problem is on our side?
That is a common starting point. The first task is establishing, with evidence, which side the problem is actually on. Both answers are useful — one tells you what to fix, the other gives you the material to push the vendor.
Do you provide ongoing support cover?
My engagements are project-based rather than retained on-call rotations. For a specific hard problem, or a period of instability you need diagnosed, that model works well.
Have a problem that fits this?
Tell me what is failing and what you have already ruled out. I will tell you honestly whether I am the right person for it.
Start a conversation →