How I measure engineering effectiveness

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

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.