Measuring engineering productivity is a Gordian knot.
How does a manager measure the performance of an engineer? Lines of code, like lines of a blog post aren’t a good metric. Most of the time, short, direct prose is better than verbose or lengthy sentences that carry on forever because they haven’t been edited & really ought to be, but someone was rushing or forgetful, & they lose the reader along the way.
Great code is succinct & clear.
So is LinkedIn’s Developer Productivity and Happiness Framework, which explains how their developer teams are measured.
LinkedIn selected three metrics for most engineers & they all revolve around speed.
- Developer Build Time : the time between when a developer writes code to when he or she can test it on their computer.
- Post-Merge Duration : the time between committing code to seeing it live on the website.
- Code Review Response Time : how long code awaits a peer-review
Each of these metrics optimizes throughput or work-velocity by preventing bottlenecks in the development process.
They aren’t about individual production metrics but overall process latency metrics.
In graduate school, I attended an operations course that assigned the book The Goal, a fictional story about a manager tasked with optimizing a declining business.
The key lesson : optimize for the entire system end-to-end, not each step.
Lines of code or number of commits focus on components of the engineering process. Latency encompasses the entire chain.
Alexander the Great cut through the Gordian knot with his sword. Perhaps, latency optimization is the analogue in managing software engineering teams.