Chief Technology Officer / India
When the attractive promise needed another decision
- Institutional clients
- 28
- 24 in India; four across Nepal and Sri Lanka
- Engineers led
- 86
- Five functional heads; March 2026
- Engineering budget
- ₹36 Cr
- Annual company allocation, not customer funds
Decisions & consequences
01Choosing a lower automation rate after examining the wrong pairings
A proposed reconciliation release used amount, date and reference similarity to suggest pairings that could proceed through a client's configured automatic-closure process. The demonstration showed a 91% simulated automatic-closure rate. That was commercially attractive, but the review needed to establish what the proposed pairings meant. We tested against 8,200 historical pairs previously adjudicated by the participating client's authorised team. Fifty-four suggestions looked plausible under the new rules but did not represent the relationship established in those reviewed records.
The difficult cases included groups with the same value and nearby dates where more than one counterpart was possible. I asked the engineers to preserve that ambiguity rather than choose the highest score and present it as settled. Domain specialists and delivery colleagues reviewed the exclusions with the client. Removing ambiguous groups from the automatic path reduced the simulated closure rate from 91% to 76%. The remaining work became an explicit review task with the source records and reason for referral visible.
Sales colleagues argued that the lower number weakened the release's central proposition. I agreed that it reduced the headline benefit, but the original figure was not a responsible basis for a promise about financial conclusions. The client retained authority over its closure rules and accounting treatment. We did not retrospectively change live entries through the test, and we did not call the fifty-four suggestions realised losses. The evidence supported a release-design decision, not a claim that the supplier had prevented a particular amount of loss.
The result was a narrower automatic path and more review work than the initial demonstration implied. We retained the test population and the adjudication basis so the choice could be examined later. I wanted the product's value to rest on a defensible division between automation and judgement. A matching system should reduce unnecessary work where the relationship is established, while helping the institution investigate the records for which a plausible resemblance is still insufficient.
Giving nine clients a fair share of the morning processing window
An unusually large overnight import from one institution consumed 62% of a shared worker pool during the observed processing window. The service remained available, and total throughput looked healthy. Nine other clients nevertheless saw their median completion time rise from 21 to 56 minutes. A single aggregate measure concealed the distribution of the delay. The large customer's account team wanted us to add capacity immediately so its import could continue without a change in behaviour.
I asked the engineering team to examine workload allocation before treating more infrastructure as the whole answer. We introduced bounded per-client allocations and divided large imports into units that could yield capacity between scheduled portions. Operations could see which work was queued and why. The policy was reviewed with service delivery and the commercial owners, because a priority rule affects what the company is promising each customer. Engineers did not grant permanent priority in response to an urgent support escalation.
The largest import took longer than it had when it occupied the pool without the new bounds. Its account manager objected that a technically successful change would be experienced as a slower service by an important client. We discussed the completion window explicitly and agreed the supported schedule. The other nine clients returned to the agreed completion windows in the subsequent observed runs. We did not use that observation to claim every future workload would fit without additional capacity; demand and the service commitments still needed review.
The decision improved the fairness and explainability of the shared service while giving up the fastest possible completion for the largest job. It also changed the report presented to management: client-level completion and queued work accompanied aggregate throughput. I wanted a capacity proposal to show who would benefit, who would wait and whether the problem arose from total demand or its allocation. Buying more compute can be necessary, but it should follow an understanding of the service rather than hide a policy that nobody has agreed.
Repairing an exit package that counted records but lost their evidence
A customer preparing to leave our product rehearsed an export of 36,000 exception cases. The first check confirmed the expected row count and produced a readable file. A receiving analyst then tried to investigate a selection of closed cases and found attachment references that did not lead to files in the supplied package. The review identified 2,400 such references. The export had preserved the appearance of a complete case list without all the evidence needed to understand the work outside our application.
I brought product engineering, delivery and the contract owner into a review of the authorised export scope. We needed to include the relevant attachments, preserve their relationship to cases and describe the access mapping in a usable form. We also had to avoid carrying material outside the customer's permitted scope. A broad database copy would have been an easier technical response and an inadequate answer to the actual obligation. The receiving team repeated its review task against the revised package rather than accepting a larger file as proof of completeness.
The additional engineering work cost Orevathi ₹18 lakh. Finance questioned why a departing account should consume work not included in the original delivery estimate. I supported funding the repair because the gap concerned the usability of the agreed export, not a request for an entirely new product. The contract owner confirmed the scope with the customer. We did not require the customer to retain our application simply to follow the evidence behind its own exported cases.
The revised package supported the authorised case-review task in the rehearsal, with the attachment relationships and mapping documented. The customer still had responsibilities for its receiving environment, retention and access decisions. Our work did not certify those choices. The consequence for Orevathi was an expense and a more demanding export test for future releases. I considered both preferable to discovering at contract end that a technically successful download had left a customer dependent on the supplier for the meaning of its records.
Declining a quick product branch and funding a supported extension
A prospective institutional client wanted a distinctive approval sequence before it would begin a paid pilot. The sales proposal assumed that a customer-specific branch of the application could meet the requested start date in six weeks. Engineers could implement the immediate sequence that way, but the branch would need separate testing and continuing updates. The proposal did not include that maintenance commitment. It treated the initial code change as though it were the whole service the company would have to provide.
I asked the product and delivery teams to examine whether the requirement could be represented as a supported extension to the approval configuration. The answer was yes, but it required three months of work and ₹38 lakh of engineering expenditure. We also identified a simpler pilot scope the customer could consider while the extension was developed. The CEO reviewed those alternatives with sales. I declined to approve the separate branch as a hidden shortcut whose future cost would sit outside the commercial decision.
Sales objected that the later date might cost us the opportunity. That possibility remained real; I could not promise the customer would accept our preferred architecture. The company chose to fund the extension and explained the revised schedule. The customer accepted a later pilot start under the agreed scope. We recorded the pilot as a pilot, not a secured multi-year revenue stream, and retained its evaluation conditions. Commercial colleagues owned the contract discussion, while my team owned the engineering estimate and the support assumptions behind it.
The decision cost more time and explicit development spend than the proposed six-week branch. It also left the approval sequence within a maintained configuration model that subsequent upgrades could test. I would not claim that every bespoke request deserves this investment. Some should be declined outright. In this case, the requirement was sufficiently reusable and the approved cost sufficiently clear to justify the extension. The useful result was a commitment the company understood before accepting it, rather than an attractive start date followed by an unpriced second product.