Wednesday, December 9, 2015

The Productivity Formula

Productivity is clearly some kind of ratio; it is some kind of N:M relationship, but it's hard to know quite what the N and M are.

Of all the poor ways one may define Productivity for software developers, there are some really horrible formulae including "lines of code per developer" and "story points per iteration", measures which really measure all the wrong things and which might send Charles Goodhart into a tizzy.


Rather than rant more on those, let's cut to the chase and give the definition that most people really use:


(what you did)

----------------------------

(what I wanted)


You see, management is really not a data science. It is generally practiced as a semi-educated gut feel, because most managers in software organizations are really programmers risen through the ranks. Maybe 1/3 of them have studied computer science (judging by the popularly quoted folk-statistic that 30% of people work in the area of their college major).  Most of them have learned to manage in a sink-or-swim way, or possibly mentored in a "tribal knowledge" kind of way.

As a result, most decisions are based on trust and gut feel. 

This measure is a gut-feel relation. As a gut-feel relation, we really should adjust it to say "what I think you did" on top, but I'm leaving it as-is. 

The thing that might confuse some readers is that this is not a snarky rant. I believe that this relation is not only "true" but possibly "correct" for all of the subjectivity that is inherent.

Whether it is right or not, it seems to be true, and gives us some leverage and predictive power. In other words, however imperfect and undesirable you may think it, this is a workable definition.

I have long talked about the "trust transaction" where we give transparency and delivery, and in return are given trust (generally in the form of lessened governance and increased autonomy).  Notice how this addresses the relationship.

I am not the first, nor even the brightest, to have talked about "expectations management" and "business and development working together" which improves the relation by "truing up" both entities.

Nor am I the first nor brightest to discuss the idea of delivering earlier and oftener. Notice that this helps to calibrate not only expectations but also observations.

And finally, note how not having anything to show for your past N days worth of effort affects the relation.

I offer it here for your comment, acceptance, absolute rejection, or ridicule -- as you wish.