In the fast-paced world of software development, the goal of measuring developer productivity has gained traction recently, yet it remains a touchy subject. Tools like story points and DORA metrics have become more popular, though teams often expend effort tracking these values without knowing why or what action to take from the data. Without a clear strategy in mind for implementing these measurements, companies can very easily lose time, money, and the trust of their teams. This talk is for any leaders or team members who have concerns such as:
-What metrics should we be measuring and why are we measuring them?
-Am I going to be disciplined if I perform worse than other teams?
-Should we measure developer productivity at all? Can we take any actions from the data?
Drawing from firsthand experience from being on both sides of leadership and development, I’ll begin this talk will begin with the end in mind – covering what the goals ultimately are when measuring developer productivity. Crucially, attendees will also gain clarity on which metrics are truly meaningful for their organization. After covering potential motivations and benefits, I’ll talk about what metrics can be worth leveraging for your organization, as well as how to measure them.
Being a developer myself, I’ll particularly talk about these metrics from that perspective. Additionally, this talk will cover organizational patterns for teams that I have seen succeed and foster a culture of continuous improvement, as well as those common pitfalls that ultimately undermine your efforts and alienate teams from leadership.
When implemented carefully, I’ve found that teams will lean into measuring their productivity for their own sake so that they can improve themselves. The organization reaps the benefits in the form of less defects, faster feature development, and a happier workforce.

-What is productivity?
-Goals
-Measuring productivity
-Measuring value
-Getting value as early as possible
-Iteration, feedback, and team empowerment
-Continuous improvement
-Tech practices
-Recap, closing thoughts, and questions

This talk is intended both for developers who may be curious or anxious about these things happening in their organization, as well as leadership who are interested in measuring these things themselves (or currently doing so).

Many organizations implement this by tracking the amount of tickets completed, rather than the amount of value added. This talk will attempt to explain why tracking purely the amount of work done misses the mark and (rightly) makes developers more anxious. It will also go into some specific metrics and how to use them correctly as a guideline, such as DORA metrics.

Moreover, it will go over some tech practices and organization patterns that facilitate faster iteration for faster value add, which I find is what organization usually really want. This includes things such as teams owning their work without outside approvals, pushing straight to prod, and automated testing