# How I report results, including the misses Source: https://manaienko.com/how-i-work/reporting-results/ Author: Artem Manaienko A number carries its scope and its status. A missed forecast gets reported as a miss. A claim I can no longer source gets retired, not rounded. ## My principles 07 operating rules 1. [01 A number never travels alone](#practice-reporting-results-principle-1) 2. [02 Name the minimum acceptable outcome before rollout](#practice-reporting-results-principle-2) 3. [03 Report the forecast and the result](#practice-reporting-results-principle-3) 4. [04 Keep a project that missed, if the value is real](#practice-reporting-results-principle-4) 5. [05 Retire a claim you can no longer source](#practice-reporting-results-principle-5) 6. [06 Separate what you decided from what you built](#practice-reporting-results-principle-6) 7. [07 Label a model as a model](#practice-reporting-results-principle-7) ### A number never travels alone Role, system, scope, and constraint stay attached to the outcome, or the outcome does not get published. A percentage without its denominator is decoration. ### Name the minimum acceptable outcome before rollout A target on its own gives a result nowhere to land, so the smallest outcome that would still justify the work goes down next to it, before anything ships. That is what made a migration delivering roughly half its forecast a decision I could keep and defend rather than an argument about whether half counts. A range beats a single number for the same reason. ### Report the forecast and the result Both of them, not whichever one is more flattering. If I asked for an investment on a projection, the projection is part of the result and belongs in the same sentence as the outcome. ### Keep a project that missed, if the value is real Missing a target and being wrong to try are different things. Reverting useful work so you never have to explain the miss is the more expensive mistake. ### Retire a claim you can no longer source When the dashboard is gone and the measurement period cannot be reconstructed, the claim goes. Even a good one. Even one that was true. ### Separate what you decided from what you built Final authority, leading through specialists, and writing the thing yourself are three different claims. Collapsing all three into "I did" is the most common way technical leaders overstate themselves. ### Label a model as a model A reconstructed figure is honest and useful as long as it shows its assumptions. It stops being either one the moment it is presented as a measurement. ## What that looked like 03 cases ### I asked the Board for 40% and delivered 20% ASKfm · 2016-2021 **Situation:** A large read-intensive sharded workload on InnoDB was eating substantial memory on owned hardware, and memory was what drove server and rack requirements. A broader archival programme had already been rejected: several months of work, competing directly with product investment. Adding RAM was not financially viable. So the constraint stayed. **What I did:** - Reframed the problem into something narrower and more fundable: a bounded engine migration instead of a multi-month archival programme. - Evaluated RocksDB against the actual read/write profile rather than generic benchmarks, and accepted a slower write path the workload did not care about. - Built the executive case on memory growth, hardware limits, and a bounded engineering investment, and won approval. - Reported the result against the forecast when the measured reduction came in at roughly half of it. **Outcome:** Approximately 20% RAM reduction against a forecast of approximately 40%. We kept the migration, because the realised reduction still supported infrastructure consolidation and production behaviour stayed acceptable. The estimate was wrong. The decision was still right. What I took from it: define the minimum acceptable outcome next to the target before rollout, and present a confidence interval instead of a single number. ### Being told no by the Board, and why they were right ASKfm · 2016-2021 **Situation:** I proposed moving inactive-account media and text into cold archival storage. It would have cut storage cost, active index size, and RAM, and eventually reduced physical data-centre capacity. The long-term economics were good. **What I did:** - Presented the full case: a modest monthly storage saving, several months of implementation, and a payback period around a year or longer. - Accepted the rejection without relitigating it. During a cash-constrained period the Board preferred near-term product investment. - Came back with the narrower proposal that addressed the immediate constraint instead. **Outcome:** The programme was not funded. I disagreed with the allocation and still understood it: positive technical ROI is not automatically the best survival decision for a business under cash pressure. The narrower engine migration got approved precisely because it was tied to the immediate constraint instead of the better long-run economics. ### Retiring my own best number ASKfm · 2016-2021 **Situation:** For years I described ASKfm's availability as five nines. Strong claim on a CV, and the kind of thing nobody checks. Then I went back to reconstruct the evidence. The historical SLI turned out to be coarse: the core journey counted as available when more than half of users could enter the product and perform core actions, so individual feature failures never registered as downtime. The original dashboards, the period, and the calculation method are all gone. **What I did:** - Retired the figure instead of restating it with a softer adverb in front of it. - Replaced it with what I can actually defend: availability preserved through simultaneous transformation, with the SLI definition stated openly. - Kept the harder claim underneath it: sequencing eight concurrent structural changes on a live high-load product without a reliability collapse. **Outcome:** The headline got weaker and the position got stronger. What I say now survives the question 'how did you measure that?'. The old claim did not. This page is the demonstration Every figure on this site carries the qualifier it earned. Approximate recollections say so. Reconstructed models say they are models and show their assumptions. Retired claims are absent even where they would have helped. Call it discipline rather than modesty. It is what I would expect from an engineer reporting a benchmark, applied to my own record.