4.2 - Data-driven engineering: Tracking lead time, velocity, and DORA metrics
Many managers fall into the trap of measuring the wrong things. Tracking "lines of code written" or "hours worked" does not improve software quality; it only encourages bad behavior.
To lead effectively, you need to rely on operational sensors that measure the health of your delivery pipeline without micromanaging your engineers. Data-driven engineering focuses on systemic flow and quality.
Sensor 1: Lead time vs. cycle time
If your team is moving slowly, you need to know exactly where the bottleneck is.
- Cycle Time: The time it takes from when an engineer starts coding until the code is merged. If this is high, your codebase might be too complex, or PR reviews are taking too long.
- Lead Time: The total time from when a business request is made until it is running in production. If Cycle Time is fast but Lead Time is slow, your deployment pipeline or QA process is the bottleneck, not your engineers.
Sensor 2: Sprint velocity stability
Velocity is not a tool to squeeze more work out of developers. It is a metric used for predictable planning.
If your velocity wildly fluctuates sprint-to-sprint, your team is likely drowning in unplanned bugs or technical debt. To stabilize velocity, establish a firm rule: Allocate 20% of every sprint's capacity exclusively to paying down technical debt and refactoring. Protect this 20% from product managers relentlessly.
Sensor 3: DORA metrics (CFR & MTTR)
DORA (DevOps Research and Assessment) metrics measure system quality without playing the blame game.
- Change Failure Rate (CFR): What percentage of your deployments cause a failure in production? High CFR means your DoD is weak or your automated testing is inadequate.
- Mean Time to Restore (MTTR): When the system breaks, how fast can the team fix it? This measures the robustness of your observability tools and rollback procedures.
As a Tech-Led Coach, you don't use these metrics to punish individuals. You use them to justify investing in better infrastructure.
🎯 Self-Reflection for You
- Can you pinpoint exactly where a feature gets stuck between the product backlog and production deployment?
- Are you using metrics to evaluate your engineers, or are you using them to evaluate the system they work within?
If you want to move away from gut-feeling management and implement a dashboard of healthy engineering metrics, let's discuss it in a virtual coffee chat.