Inheriting the Fire: Stabilising an HRMS in Production
Shyam Steel / Shyam Future Tech · Product Owner — SFT Evolve
Feb 2026 – Present
An HRMS had reached enterprise tenants before it was stable, and escalations arrived wherever a client could find someone to tell. The fix was root causes, an escalation matrix, and a team that stopped dreading the product.
Read the full story
Situation
SFT Evolve, the group's multi-tenant HRMS, had reached external enterprise tenants before it was stable. The product I inherited carried functional defects in its attendance and payroll calculation logic — the two areas a workforce notices immediately — so tenants were openly frustrated, and escalations arrived unstructured, reaching whoever a client could get hold of rather than anyone accountable for resolving them.
Action
Appointed Product Owner in February 2026, I took personal ownership of every escalated account and put a stabilisation plan in front of each one, holding confidence through visible progress rather than promises. With the cross-platform teams I separated true defect classes from configuration and data issues so that fixes stopped recurring — the calculation logic behind attendance and payroll was diagnosed and corrected rather than patched per complaint — then built the machinery the product had never had: an escalation matrix, and customer support channelled through a Freshdesk ticketing system with owned queues and SLA reporting in place of scattershot escalation paths. I raised the resourcing and structural gaps with leadership rather than absorbing them quietly, and worked on the team's own relationship with a product they had come to associate with firefighting.
Result
The attendance and payroll calculation defects were remediated, the product stabilised, the escalated tenants were retained, and the escalation matrix and ticketing channel remain the operating model. The work is ongoing.