I Optimized CI Build Speed by 5 Seconds. My Manager Didn't Care.
How I learned to measure impact, not just effort
I Couldn’t Tell Between Output and Outcome
When I was an engineer, I always took actions without measuring their benefits.
I abstracted a code layer and felt proud of it. It turned out that the last time someone used that code was three years ago. Refactoring added very little value.
Or, I spent 3 days optimizing the CI build speed by 5 seconds. But people cared more about tests randomly failing due to a bug. That slowed down the team way more than the build speed.
So during the performance review, my manager had a hard time seeing my value. He could only see a list of completed tasks, but none of which did anything meaningful. I barely got a “meet expectation”, knowing it could have gone worse.
I only realized this mistake once I became a manager myself. Managers care more about outcomes. There are so many actions that can create outputs, but not all of them create outcomes.
Engineering Metrics are Your Companion for Outcomes
As managers get busier, engineers compete for attention during reviews. Outcomes stand out. Outputs don’t.
This is why we always need to measure the outcome before taking actions.
And the most useful way to measure it is to use engineering metrics. They are aligned with the team goals and have high visibility.
If your team is already measuring engineering metrics, perfect. Use them.
If your team does not track them yet, here’s where to start:
Key Metrics That Actually Help Me
Things that your manager cares about the most.
Incident rate: Incident count / number of releases. Tracking only incident count works as well if you want it simple.
Project delivery rate & delay: Many things can happen in a project, but it can be tracked on the engineering side.
Other common system metrics:
Security: Security hotspots or security rating (e.g. SonarQube or Synk).
Stability: 500 error count, system uptime (e.g. New Relic, or DataDog).
Quality: active defect rate, first pass rate, test coverage.
Performance: API latency, load testing result, Web Vitals (e.g. Sentry).
I wrote a post about engineering metrics. Check it if you want the full picture.
Don’t Wait for Your Manager to Set This Up
One common issue is that you don’t have access to the metrics.
No worries. You should be able to start on your own.
💡 Use existing tools your org already has. If your team uses DataDog, New Relic,, the data is likely already there. You don’t need special permissions to create a personal dashboard view.
💡 Build your own tracking tool if nothing exists. With AI-assisted coding, you can build a small utility script in an hour. For example, you can use your GitHub token to pull PR data and calculate lead time, which is the time from opening a PR to merging it. No need to convince your manager to purchase a commercial tool like LinearB. You get the data and insight, and you bring it to your next 1-on-1.
The bar for doing this is lower than you think. You don’t need an leader or manager to start this.
Friendly Reminder: Metrics Are Evidence, not Targets
One caveat is that engineering metrics are tools that help you communicate your achievements, not how you choose your work.
I’ve seen engineers game these numbers before. Incident rate drops, but only because the team started underreporting. The metrics look great, but the product doesn’t improve.
Focus on real impact. The team. The customers. They matter more.
Also, if you’re not sure how to connect your work to outcomes your manager actually cares about, that’s exactly what we work through together. Click the button below to understand more!
See you in the next post.
Adler from Tokyo Tech Lead