Leadership called it a people problem. What discovery revealed was a process that had been set up to fail, and a team paying the price for it.
Sector and size
A global software technology company, with a product support operation serving thousands of clients. A team of five specialists handled more than 150 core applications, fielding several hundred tickets a month and, on average, two serious escalations every day of the week.
My role
I came in as Support Lead, inheriting a team that had been running for two years. My handover amounted to three meetings, some documentation, and no transition plan to speak of.
Within days I had a strong suspicion: this team would burn out within weeks, and I would lose half of them.
The presenting problem
The official read from leadership was straightforward: competence gaps and not enough engagement. The team was not performing to expectations, and the implied remedy was to fix the people.
What I actually observed
The team was based in the Philippines, working night shifts, and the frustration was everywhere: in how people talked about the work, in the arguments between teams, and in the overtime that had become the default rather than the exception. None of that was the problem, though. It was the symptom.
So I started mapping the actual flow of work, and what I found was a team that had been architected into an impossible position from the start. They were expected to be Tier 1 and Tier 2 at the same time, client-facing and expert-level across 150 applications, with no tiering of clients by criticality, no clear escalation mechanism, no incident management process flowing into change management, and no regular connection to the Tier 3 product teams who actually held the deep application knowledge.
Every ticket that arrived was theirs to own, regardless of complexity or ownership. Every frustrated client came directly to them. Every escalation landed on a team with no structural path to resolution.
Leadership was reading this as a people problem when it was a process architecture problem. The model was consuming people faster than it was solving anything.
Where the system actually broke
Flow was broken at every handover. Tickets queued, escalations mounted, and the team spent more energy managing the friction of a badly designed system than solving client problems. Experience followed directly: clients had no clear escalation path, resolution times were long, and the relationship between “something broke” and “someone fixed it” was opaque and unreliable.
What I did
I did not start with process redesign. I started with discovery.
I spent time with the team, with product development, with programme management, with business line leaders, and with clients. I mapped the real flow of work and coupled that with data on ticket volumes, escalation patterns, and resolution times. I needed to see the system as it actually operated, not as it had been designed to operate on paper.
What emerged was clear: this team should have been a true Tier 2, sitting between client-facing Tier 1 support and the Tier 3 product development teams. Instead, they were absorbing everything from both directions with no structural support from either.
The redesign happened in phases. We started by educating the team on what incident management should actually look like, including what warranted escalation, what did not, and why. We then established a regular meeting cadence with the highest-volume product and development teams, worked with the product side to build out more self-service options in the marketplace, and created proper tracking and handover processes for new products and new client partners. Most importantly, we moved towards problem management, shifting from fixing the same incidents repeatedly to surfacing the patterns that product teams could address at root cause.
The most important shift was as much cultural as structural. The team needed permission to be assertive, to push back and to escalate deliberately rather than absorb endlessly.
The team needed permission to be assertive: to push back, and to escalate deliberately rather than absorb endlessly.
Where we hit limits
The organisation was large, and API support was not yet a significant revenue generator, so leadership attention was episodic. An enterprise client would escalate, energy would spike, the incident would be resolved, and interest would drift.
Sustaining the momentum of the redesign meant working more closely with the product teams and business line management directly, making the structural changes visible at a level where they could not be deprioritised the moment the immediate fire was out.
Outcomes
We kept the team, escalation counts dropped, and overtime reduced. The relationship between support and product development became a working one rather than an adversarial one.
What I cannot easily quantify, but knew was real, is that the team stopped feeling as though they were absorbing a system designed to overwhelm them. That shift in energy matters more than most metrics.
What I carry into INCEPTI now
Discovery is not optional, because you cannot redesign what you have not properly understood. That means interviews, data, and mapping the real flow of work rather than the intended one.
The equivalent of the Mom Test applies here too. Ask clients and teams what they are actually experiencing, not what the process says they should be experiencing, because the real need and the documented one are rarely the same.
Leadership attention also has to stay anchored. Change in a large organisation needs the work to be defined as an objective, tracked as an OKR, and made visible enough that it does not disappear the moment the next escalation lands.
The process existed. It had simply never been tested against the people living inside it.