Measuring Productivity

  • Comments posted to this topic are about the item Measuring Productivity

  • There was a post on LinkedIn that argued that DORA metrics are not a measure of productivity.  The argument was that these metrics measure the speed and success of deployments and not value to the business.  They felt that productivity had to be something that measures financial value to the business.

    Making 10s of successful deployments a day does not translate directly to revenue.  Even if a deployment is for a new customer feature,  is use of that feature logged somehow?

    I worked on an enhancement to a marketing tracking system.  The original in-built system was never designed for the volume and range of marketing activities that the company grew into.  The new tracking codes were to be 3-part rather than 2-part.  This was discussed with all the people who would be affected by it.  Everyone thought it would be a good idea.   Long story short, years later, when the entire system was decommissioned in favour of a buy rather than build, we found that no one had used the middle part of the 3-part code.  ROI on a feature the customer thought was a great idea was zero.

  • DORA has nothing to do with bad product design. Those are separate things. In the past, we've had engineers act as product managers, and build things they imagine users will use (Field of Dreams).

    DORA and other metrics around engineering are different. Are engineers producing and releasing quality code. Are they productive at their jobs. I'm often focused there, especially with customers, since I can know if someone decided if the useful or profitable thing was built. That's a different job, and one I'm not sure if being done well in plenty of organizations.

     

  • Thank you, Steve, for this article. And especially the DORA software delivery performance report. I've been familiar with DORA for years, but fine that lots of people in IT have never heard of DORA. I'm one of the GitHub Admins at work. I spent time last week working on a task to clean up old GitHub self-hosted runner builds, as they are not purged automatically. I was very surprised to see that we haven't had a build using the self-hosted runner in weeks. Some people prefer an overly complicated approach to GitHub Actions that one guy insists must be followed. However, it results in people working around this complicated routine and only that guy really understanding how it works, so he has to do all the builds for the teams he's on.

    But I don't think that is what's holding everyone else back. There's something else going on, that I can't put my finger on. I'll read that DORA report so I can learn it, but I feel like I'm the only one who will care. Others will, well, do whatever the heck they've done for years and screw delivery productivity.

    Kindest Regards, Rod Connect with me on LinkedIn.

Viewing 4 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic. Login to reply