Some days I produce an incredible amount of productive coding work. Some days are not even close. I would guess that the eighty-twenty rule applies pretty well to my own productivity and that of the developers and organizations I have observed. Despite this, our business models expect some notion of uniform input that fights against the nature of creative work like software development. We artificially enforce an average work day which has its roots in assembly-line work. We assign homogenous sprint cycles which do not seem to take into account the radical inconsistencies that arise naturally in one's flow, that do not allow wiggle room for personal issues or dashes of motivation.
When we are expected to produce uniform output, it can be demotivating on both ends of the spectrum. Workers are forced to put their butts in seats when things are not working and, out of the expectation of uniformity, are less likely to put in an inspired late-night run, for worry of establishing a new norm.
While these procedures have some historical purposes, they strike me as inefficient and irrational. We are still in a pre-Moneyball era of work and even the "innovative" technology sector seems uninterested in "disrupting" accepted best practices.
I have little structured management experience so I am inherently naive, but I am sure that changing industries are not modeling their work procedures to the problems at hand, which is to their detriment. Changes tend to be evolutionary when they could stand to be revolutionary. There are, of course, tradeoffs that make these revolutionaries impractical. Doing anything differently involves ridicule you would not otherwise suffer. An organization takes on risk in doing things differently. So while the current situation is inefficient, anything outside of the norm could land anywhere on that spectrum. There are also issues with getting any new hire up to speed on new practices that do not exist if you just do what everybody else does. This is why all 32 teams use the same punt formation.
In an environment where the practitioners of a growing craft, like software development, demand a high salary if they are experienced, it is worth differentiating an organization's procedures in ways that attract a certain type of skilled practitioner. I believe this is both better for business outcomes and developer happiness. These will go hand-in-hand in the long run. Despite the potential tradeoffs, it is worth thinking way harder than we do about "the way we have always done it."
Top comments (0)