There’s a lot of buzz right now around engineering productivity metrics like DORA and the SPACE framework. Tech leads and VPs of Engineering are rightfully focused on optimizing cycle time, deployment frequency, and developer satisfaction. These are fantastic for measuring the efficiency of the delivery engine. But are we creating a blind spot?
A relentless focus on shipping speed can inadvertently punish the messy, non-linear work of product discovery. True innovation requires us to slow down, run user interviews, build prototypes, and sometimes, throw work away after an experiment fails. These activities don’t look ‘productive’ on a velocity chart and can increase cycle times. This tension can subtly push teams toward becoming a ‘feature factory’—shipping code at an impressive rate, but without validating if it’s creating real customer value.
The goal isn’t to ditch engineering metrics, but to balance them. We need to pair ‘output’ metrics (like deployment frequency) with ‘outcome’ metrics (like user adoption, retention, or satisfaction). When we celebrate both a smooth release and a validated hypothesis, we create a culture that values building the right thing, not just building things right.
How are you balancing the push for developer productivity with the need for deep product discovery in your organization?