One of the most over-used management mantra is ‘productivity improvements’. Managers learn in MBA schools, that this is the Holy Grail – one of their keys to being effective at resource management. Without productivity goals and plans – how can managers assess their resource needs, OR, commit to meeting completion goals by a specific time?

Productivity by itself is a well-defined word. At the same time, it means different things to everyone. For example – more with less, faster delivery of results, process/operational efficiency, etc. In the area of Operations Management, where tasks are well defined and processes/methodology can be optimized – continuous productivity improvements, is standard practice for management. Bottom-line, when the set and sequence of tasks to be executed are well defined and repetitive, the next process challenge is executing them, faster, better while continuing to meet quality goals. In this case, Automation has provided the magic tools to improve productivity. Multiple fields of manufacturing, robot-based distribution/shipping centers, etc. has demonstrated this over the years.

I want to shift attention to the subject of “SW Developer Productivity”. This is one area, where we apply our best and brightest (and the most expensive) resources to create ‘something from nothing’. Clearly, this is a very significant component of the Operating Expense (OPEX) of a department budget. It is under microscopic review by senior management regularly, for productivity metrics, and improvements. However, there is a big gap between the cup and the lip here. Attempting to measure and manage developer productivity, is like trying to move a large pile of soft beach sand, with your bare hands. It has eluded those who have come in the past, and will continue to elude those who come by in the future – if they start with the premise that developer productivity is measurable and hence manageable. In my lifetime, I have seen all kinds of tools, processes and methodologies, as the panacea to productivity improvements – only to be replaced by the next shiny tool, which comes along. Hours worked, SLOC, defect Rate, bugs closed, executed Story points will provide measures/pieces of the puzzle, while the full picture will continue to be incomplete.

Think of this a bit differently…. Consider anyone who is regarded as an artist, or someone who is a creator. Could be a writer, sculptor, artist/painter, problem solver, etc. A timeline or productivity metric, cannot be applied here. WHY? For the same reason why a SW developer productivity is difficult to nail down.

If we recognize that SW Developers are ‘knowledge workers’ – and productivity is not an individual measure but a team measure…. you will start understanding how productivity applies to this class set. Let me elaborate on some of the concepts I have introduced. Knowledge workers start with an ‘inexact request’ and deliver something ‘exact’. They churn the requirements in their minds, 24×7 and not just during their daytime job – until concepts evolve/grow in their heads and they start creating hi-level architecture/design documents. Once they see the statue emerging from the block of ivory stone in from of them, progress becomes visible. Often times, this phase is not predictable, though experience should guide managers to make an educated assessment. Clearly any attempt at even measuring productivity during this phase, is a total waste of time.

The other realization I have come to is that SW developers operate as a pack or team, although they have individual deliverable responsibilities. If you have a good operational team, which performs well, and delivers – you as a manager need to set priorities and then get out of their way. SW teams are no different from other sports teams. They have their star players. Just as the best quarterback, cannot operate without their runners and catchers – various SW team members contribute in their own way, to meet team goals.

In my judgement, if managers set clear priorities for their SW teams, and let the developers execute, productivity will follow. When business priorities are changing and managers have to redirect the developers, while they are in the middle of their execution – productivity will suffer. Developer tasks may become a set of nested interrupts, leaving the impression of poor productivity, at senior management levels. After all – a rolling stone will not gather any moss!

So if you are a Manager – focus on the intangibles to improve morale and productivity. Recognize and reward frequently and often…. Where it is due. Provide goals, requirements and direction – and avoid micro/mini management. Enable your teams to sort out the next level of details, and take ownership and be accountable. Managing by metrics, may give you a feeling of control – it is just a feeling. You are in control, ONLY, when your team has been given control to execute with clear requirements and right priorities.