# How I measure engineering effectiveness Source: https://manaienko.com/how-i-work/measuring-engineering-effectiveness/ Author: Artem Manaienko I look for the real cost and bottleneck across the delivery workflow, including work outside the ticket. Then I need a baseline and a comparison that keeps speed, quality and cost together. ## My principles 05 operating rules 1. [01 Find where the time goes](#practice-measuring-engineering-effectiveness-principle-1) 2. [02 Find the constraint in the whole workflow](#practice-measuring-engineering-effectiveness-principle-2) 3. [03 Measure before making the change](#practice-measuring-engineering-effectiveness-principle-3) 4. [04 Check quality and cost alongside speed](#practice-measuring-engineering-effectiveness-principle-4) 5. [05 Use these numbers to improve the workflow](#practice-measuring-engineering-effectiveness-principle-5) ### Find where the time goes I look at the work with the team before choosing a metric. Where are people waiting, repeating an investigation or redoing a change? At Teladoc, a costly meeting happened before the integration ticket, so ticket counts missed much of the problem. ### Find the constraint in the whole workflow I look for waiting, quality problems and repeated coordination costs from intent through production. A decision boundary or unclear ownership may matter more than implementation speed. ### Measure before making the change I have skipped this when I felt sure about the problem. It left me reconstructing the result afterwards. Next time I want the baseline, measurement period and definition written down before changing the workflow. ### Check quality and cost alongside speed I want to see review time, rework and defects alongside delivery time. I include review, rework and the ongoing cost of operating the result. For AI, I also need model and tool costs. More code or more pull requests do not tell me whether the change helped. ### Use these numbers to improve the workflow These measures are for finding constraints in the delivery system. I keep them out of individual performance reviews. Tokens, prompts, accepted suggestions and pull-request counts alone do not show whether delivery improved. ## What I could measure, and what I missed 02 cases ### The meeting before the ticket Teladoc Health · 2025-2026 **Situation:** Before integrating a component, several engineers spent two hours or more comparing the specification with four existing implementations. A count of components per engineer would not show how much time went into that shared investigation. **What I did:** - Put the initial comparison and contract proposal into an AI workflow, so engineers could review a prepared proposal in the meeting. - Tracked the change I could observe directly: the length of that meeting. - Reconstructed the wider time saving separately and kept it labelled as an estimate. **Outcome:** The meeting fell from two hours or more to about thirty minutes. The broader estimate was roughly 3x faster component integration and around 120 developer-hours saved per month. Those two figures are reconstructions, not dashboard measurements. I observed the shorter meetings, but did not instrument the full workflow before changing it. That limits how precisely I can describe the benefit. ### Changing releases without a baseline ASKfm · 2016-2021 **Situation:** A roughly two-month MVP took about six months as requirements changed and engineers rebuilt parts of the solution. I changed the release model, but did not measure release predictability or scope changes before doing it. **What I did:** - Moved towards one main feature per release and clearer rules for changes to its scope. - Reported the result qualitatively: clearer ownership and a better way for product and engineering to discuss scope and dates. **Outcome:** I believe the change helped. I cannot give a reliable before-and-after figure for delivery time or predictability. The six-month delivery explains why I acted; it does not measure whether the new process worked.