Chief Technology Officer / India
The unsupported answer stayed outside the release
- Research and engineering employees
- 52
- Five heads; company employment totals 164
- Annual technology operating expense
- ₹9.8 crore
- Distinct ₹1.7 crore equipment and laboratory capital
- Career since June 1999
- 27 years
- Simulation development through energy-software CTO
Decisions & consequences
012019: the forecast demonstration knew more than the forecaster could have known
As head of research I approved a demonstration built around 120 historical forecast windows. The result looked persuasive, and the product team wanted to carry its performance claim into customer discussions. Quality review then traced when the weather inputs had actually become available. Eighty-six windows had used later observations that could not have been known at the supposed issue time. Only thirty-four respected that input-availability boundary.
The observations were not necessarily inaccurate. They simply belonged to a later view of the world than the forecast was meant to represent. I withdrew the performance claim rather than preserve it with a vague qualification. We did not compare the original and corrected headline as though the first had been a valid forecasting benchmark. The problem definition had been wrong, and the product needed an evaluation that recreated what the user could have known.
Management approved ₹72 lakh and twelve weeks to reconstruct the historical input boundary and rerun the bounded exercise. All 120 windows then used the reviewed issue-time inputs. Ninety-two met the declared planning tolerance and twenty-eight did not. The remaining failures stayed in the account, and the broader release claim remained withheld. We did not infer future accuracy from the same historical set or hide the unresolved windows behind an average that made the product look ready.
The decision cost time and a preferred demonstration story. It also changed my own approval standard: the technical team had to explain not only how a model performed, but which information it had been allowed to use. I wanted quality review to challenge the apparent success before the commercial commitment made that challenge harder. The outcome was a defensible evaluation boundary and an honestly limited result, not a claim that the revised model had solved forecasting uncertainty. Customer professionals would still need to assess suitability for their own planning decisions.
2024: a ranked recommendation still violated the stated limit
A planning-feature review examined forty constructed customer scenarios. The software produced ranked recommendations for all forty, which made the demonstration appear complete. Independent validation found that thirty-six satisfied the declared constraints while four exceeded a stated limit. A supposed hard constraint had been treated in the product formulation as a penalised preference that could be traded against the objective score. The system had optimised a different problem from the one the user believed it was solving.
I withheld those recommendations from the proposed release and asked product and quality owners to reconcile the formulation with the agreed meaning of the limit. A favourable score could not authorise the software to relax the customer’s constraint. Nor could a warning label turn an infeasible answer into a feasible one. The product supplied planning support only; no autonomous equipment dispatch or actual customer operating incident is represented in this case.
The company funded ₹65 lakh and ten weeks of correction and validation. In the revised bounded exercise, thirty-nine scenarios produced recommendations satisfying the declared constraints. One remained unresolved and was held outside release. That distinction mattered: not finding a supported recommendation for one scenario was more honest than displaying a complete-looking plan whose status was wrong. Customers and qualified reviewers retained responsibility for defining the constraints and deciding whether a supported proposal was suitable in practice.
The result changed both the formulation review and the way the product described an output. The recommendation needed a clear feasibility account before its objective score could be meaningful. I asked the team to retain the unresolved scenario and the validation conditions in the release decision rather than report only the improved completion count. The CTO contribution was to ensure that the product answered the agreed question, including when its legitimate answer was that it could not yet provide a supported plan under the stated conditions.
2025: equal hourly energy hid a different short demand peak
A planning presentation used hourly energy values to compare alternative demand profiles. The aggregation made the charts easier to read, but it could remove a shorter peak relevant to the customer’s stated planning constraint. We built a controlled illustration: four quarter-hour quantities of 25 kWh each total 100 kWh and correspond to 100 kW in every interval. A second profile of 50, 20, 15 and 15 kWh also totals 100 kWh, but its first quarter-hour corresponds to 200 kW. Under a hypothetical 150 kW interval limit, the profiles are not equivalent.
The example prompted a review of twenty-four constructed profiles. Sixteen were represented adequately for the declared comparison, while eight lost a relevant peak in the hourly view. I withheld the claim that the existing summary supported that constraint decision. The limitation was not an argument against all aggregation. It showed that the time resolution had to match the particular question and that the product should not silently exchange a shorter-interval limit for an hourly average.
Management approved ₹96 lakh and eighteen weeks for revised representation and validation. The later bounded exercise supported twenty-three profiles, with one still held outside the proposed release. We preserved the unresolved case and did not treat the test as proof of correct performance for every customer pattern. The quantities remained illustrative planning data, with no instruction to operate equipment at those levels. Customers and qualified professionals retained the definition of their constraints and any practical operating approval.
The decision changed the evidence required for the product claim. A smooth hourly chart and a correct total were insufficient when the relevant peak had disappeared. I wanted the team to show what aggregation removed and whether that removal was acceptable for the intended use. The supported release scope became narrower than the original demonstration, but it was better aligned with the decision the product was supposed to help a customer make.