Chief Technology Officer / India
A narrower commitment can be the more credible result
- Software supplied to the insurance sector
- 22 insurer clients
- 260 employees and ₹148 crore FY26 supplier revenue; no premium
- Engineering organisation
- 57 engineers
- Six leads and eight contractors counted separately
- Industrial software to insurance platforms
- 26 years
- Five contiguous appointments from July 2000; no statutory seat
Decisions & consequences
01One hundredth exposed a missing business rule
During a 2022 consolidation of calculation components, 37 of 500 synthetic fixtures disagreed with the client-approved result map. The component used precise decimal arithmetic, so the initial response was to look for a data problem. Reema Navqeri's team demonstrated that the disagreement concerned when rounding occurred. Three line amounts of 12.345 became 37.05 when each was rounded half-up to two decimal places before addition, but 37.04 when they were added first and the total was rounded by the same convention. Numerical precision did not settle which sequence was authorised.
The delivery lead wanted to accept the small difference and preserve the rollout date. I had approved the shared component without requiring that distinction to be made explicit. We paused its wider adoption and asked the relevant client owners to confirm the required calculation stages. Engineering then represented the approved sequence in configuration and test examples, including how intermediate values were retained. Our team did not choose insurance pricing, coverage or accounting policy. Its responsibility was to implement the rule approved by the appropriate client specialists and make disagreement visible before acceptance.
The programme cost ₹54 lakh and added ₹12 lakh annual support expense. All 500 synthetic fixtures subsequently matched the specified result map. That was evidence about those constructed examples and the implemented rules; it was not evidence that actual customers had been overcharged, that refunds were due or that every calculation in every client system had been examined. We retained the original 37 disagreements in the review record so that the change was not presented simply as a successful library upgrade.
The price of the correction was a more explicit component contract and a larger set of supported variations. A single convenient calculation path would have been cheaper to explain and maintain. It would also have concealed a decision we were not entitled to make. I now ask an engineering proposal to show the points at which it converts a business instruction into a mathematical operation. The lesson is not that every client needs different code. It is that a shared implementation must preserve the differences the authorised rule requires, even when the visible discrepancy seems small.
A missing client setting could not borrow a neighbour's default
A 2023 configuration review used 180 synthetic scenarios to examine how the platform selected settings for different insurer clients. Twenty-three scenarios inherited an unintended default from a configuration context that did not belong to the client being tested. The problem was in the resolution path, not in a finding that an actual customer's policy had been changed. The fixtures deliberately combined missing values and overlapping labels to examine a boundary ordinary demonstrations had not exercised.
The platform lead proposed keeping the broad inheritance chain and adding exceptions for the 23 known combinations. I rejected that approach because it would leave the ownership of a setting dependent on the order in which the service searched for a usable value. We instead required explicit client-scoped references and an approved set of inheritance relationships. When an expected configuration was missing, the service had to return a controlled unresolved state rather than silently obtaining a convenient value from another client. Client owners still approved the business settings themselves.
We spent ₹88 lakh over eight weeks on the change, supporting migration and acceptance work. The same 180 synthetic scenarios later passed the stated client-isolation expectations. In the defined benchmark, the 95th-percentile configuration-read latency increased by eight milliseconds. We retained that measurement in the decision record rather than describing the new arrangement as free of performance cost. It did not establish the latency of every customer journey or the behaviour of every future configuration combination.
The difficult part was explaining why a visible missing-setting response could be preferable to an apparently successful answer. An answer from the wrong context is not improved by arriving quickly. At the same time, we had to make the unresolved state usable for support teams, with a clear route to obtain the authorised value. The result was a narrower and more defensible service promise: configuration belonged to the client named in the request, and any permitted inheritance was explicit. We did not claim that a synthetic defect established a real cross-client incident, or that this one programme settled every aspect of client separation.
Useful traces did not require complete policy payloads
Engineers investigating a problem had become accustomed to finding the whole request payload in a diagnostic trace. I had supported that convenience because it shortened the time needed to reproduce a fault. In a 2024 review of 960 synthetic trace events, 146 included specified test-policy fields that were unnecessary for the diagnostic purpose. These were constructed test records, not a discovery about a named policyholder or a public incident. The finding still required us to explain why the logging design collected those fields at all.
The support lead objected that removing complete payloads would slow investigations. We allocated ₹39 lakh to a structured trace format using stable references and selected operational fields. Details needed for an authorised investigation remained in their appropriate source, with access and handling determined through the relevant process. Reema's acceptance work checked the specified fields and whether engineers could still locate the event and request further evidence appropriately. We avoided treating removal of a few field names as proof that every possible trace would now be suitable.
In a later test population of 1,440 synthetic events, none contained the specified unnecessary fields. Twelve defined troubleshooting rehearsals also showed a cost: median investigation time increased from eighteen to 27 minutes. The scenarios were limited rehearsals, so we did not project that difference onto every production incident. Nevertheless, it showed that the new approach asked engineers to do additional work. That cost belonged in the account alongside the narrower diagnostic record.
The change required me to revise a convenience I had previously approved. Support teams needed guidance for obtaining relevant evidence without recreating a complete payload in another informal channel. We retained review of trace content and access rather than calling the programme a complete privacy certification. My conclusion was that diagnostic usefulness should be designed around a defined purpose, not around the possibility that any field might someday be helpful. The result reduced unnecessary content in the tested record while preserving an explicit route for appropriate investigation, with the slower rehearsal times visible to management.
Reversing the application did not reverse the records it had written
In 2025, a release proposal described rollback largely as restoring the earlier application version. We tested forty synthetic sequences that included records written by the newer version before the reversal. Only 29 preserved compatibility with the older reader. The remaining eleven showed that a successful code reversal could leave the service unable to interpret part of the intervening record. No actual customer data was used to infer a production loss; the exercise examined the promised recovery path before the features were released.
The commercial director asked us to keep the launch date and accept the low expected frequency of those cases. I asked instead for an explicit account of the record formats each version could read and write. We funded ₹1.1 crore of phased changes and rehearsal work. Some transitions allowed both versions to understand the relevant records; others required a sequence in which a feature remained unavailable until the supported path was established. Client acceptance included the business effect of that sequencing rather than only the technical deployment steps.
The revised programme passed 38 of the forty defined scenarios. Two features were deferred, and the programme moved four weeks later than the original plan. We did not relabel the two remaining scenarios as successful because their features were withheld. The result was a supported release boundary with a smaller initial scope, not a universal claim that any future version could be reversed safely. Finance retained responsibility for the accounting treatment of the programme within the approved investment arrangements.
The decision cost time and postponed capability that commercial colleagues wanted to offer. Joseph Belzethi accepted the revised sequence after we showed what restoring code would and would not restore. I learned to ask for the rollback story in terms of the service and its records, not simply the deployment tool. A board or client should be able to see which changes are reversible, which require another authorised recovery route and which have been deferred. The two unfinished features remain part of the outcome because they explain the boundary of the commitment we were willing to make.