Our isolated controller demonstration had shown an eight-millisecond response. It was an encouraging engineering observation, but the teaching room asked a different question. In a 2024 review with thirty-six stations under a shared workload, the median response was eighteen milliseconds and the 95th percentile was 110 milliseconds. The typical result and the slower tail described different parts of that room's experience. I wanted both in the discussion, with the test conditions attached, before we described the product as responding like the isolated demonstration.
Educator feedback concerned the uneven episodes. The controller team initially emphasised the median because it made the shared result appear relatively close to the bench observation. That was not a false number, but it was not a complete answer to the concern. A person encountering one of the slower responses does not experience the median on behalf of everyone else. The engineering question was how the system behaved under the reviewed room workload and what contribution the slower tail made to the reported difficulty, rather than which single statistic could preserve the most reassuring product description.
Do not make unlike tests answer the same question
The isolated eight-millisecond observation came from different conditions than the thirty-six-station review. I did not treat them as an identical test conducted before and after a change. The bench result was useful within its setup. The room result added interactions and workload that the first demonstration had not represented. A comparison can help identify where another question begins, but it should not erase those differences. Otherwise, the programme may argue about which number is correct when each describes a different setting and the real problem is the claim being made across them.
I asked the team to retain the configuration, workload and measurement scope in the performance account. That made the result less convenient to express as one headline, but more useful for engineering. We could then discuss whether the shared conditions required a different controller approach and how a further review should be conducted. The purpose was not to reproduce the fastest observed number under every circumstance by assertion. It was to understand the response pattern the room had actually produced and define the conditions under which a change could be evaluated meaningfully.
The teaching context also needed its own boundary. Response measurements can describe an engineering property relevant to use. They do not, by themselves, establish a learning outcome, a clinical skill or an improvement in later patient care. Educators may use their experience and appropriate assessment to judge how equipment fits a course, but a CTO should not make those decisions on the strength of a latency chart. I wanted the technical team to be precise about the property it measured while working constructively with the people whose teaching decisions made that property relevant.
The median does not describe every interaction
The eighteen-millisecond median was a useful part of the shared-room result. It did not make the 110-millisecond 95th percentile irrelevant. The tail showed that slower responses were part of the measured distribution, and educator feedback suggested those episodes deserved attention. I did not claim that every interaction took 110 milliseconds or that the percentile was a maximum. The point was to avoid letting a measure of the centre become a statement about the whole experience. A distribution can reveal a practical limitation that one representative value makes difficult to see.
This required a different conversation from asking the team to improve the average. We needed to examine the conditions associated with the slower responses and consider an engineering intervention that could be reviewed under the shared workload. A smaller central value would not necessarily address the reported unevenness. The resource proposal therefore had to explain which part of the behaviour it sought to change. That helped connect the expenditure with a specific operating question rather than a general ambition to make the technology faster, which would be easy to support and difficult to assess.
We funded a ₹96 lakh local-controller programme. The choice involved engineering work on the reviewed shared response problem, with its own cost and implementation conditions. It was not a declaration that local control is the right answer for every teaching system or that other architectures cannot serve a classroom. Our case concerned this configuration, workload and evidence. I wanted the programme sponsor to understand why the scope was proposed and how the next review would relate to the original room result, without converting a particular design decision into a universal technical rule.
Attach the improvement to the conditions that produced it
In the repeated thirty-six-station review, the 95th-percentile response was thirty-two milliseconds under the stated conditions. That was a meaningful change from the earlier 110-millisecond percentile in the reviewed shared setting. We retained the configuration and workload in the account. The result did not mean that every response was thirty-two milliseconds, that no slower response existed or that every future room would behave identically. Nor did it make the isolated eight-millisecond observation the new standard against which all uses had been proven. Each number needed to remain attached to the question it answered.
I also kept the ₹96 lakh expenditure visible. A performance case should not present the better percentile as though it arrived without a resource decision. The company chose to fund a particular engineering response to the evidence and then examined its behaviour. A reader can assess that judgement only if the cost, purpose and observed result remain connected. I have not attached an invented return on investment or clinical benefit to the change. The technical improvement can be valuable without pretending that the record contains every downstream consequence someone might hope it would create.
For a board, the relevant oversight questions concern the fit between the performance claim and the evidence. What setting produced the result? Which part of the distribution matters to the reported difficulty? Does the proposed investment address that part, and will the follow-up preserve comparable conditions? Directors do not need to choose controller components or define every measurement detail. They should be able to understand whether a product account is relying on a favourable central statistic, an isolated demonstration or a review that actually represents the commitment management wants to make.
The lesson I would carry into another equipment programme is to let the slower experience remain part of the result. The median was not wrong, but it was insufficient for the question educators raised. The shared-room review justified a resource decision, and the repeated test showed a better 95th percentile within its scope. That is the claim I can support. A leadership profile should make that sequence clear: listen to the use condition, preserve the distribution, fund a defined intervention and report the result with its boundaries. The confidence should come from the specificity of the account rather than from making the largest possible promise.