Previous: We’ve Been Wrong for Fifty Years
Suggestions for why non-technical managers so often fail when trying to manage technical projects and technical people range from arrogance to ignorance. Most likely it’s a combination plus what some humorous technical old-timers call the impedance mismatch. This reference to electrical design describes an overload that occurs when an electrical component not intended for the build breaks the whole build. As the old timers would say, it lets the smoke out.
In the case of non-technical management governing or leading technical people and projects, the smoke is courage. Developers must possess courage and have the skills to summon oceans of it when faced with the unexpected – which describes every other hour of the developers’ day. When the smoke leaves the manager, fear takes over and fear will do irreparable damage to any software product.
Managerial fear causes failures like the following:
- agreeing to provide actionable bids for time or cost
- blaming technical people when things go pear-shaped
- setting unfounded or inappropriate priorities
- insufficient training
- insufficient staffing
- inadequate tooling
- demanding letter-of-the-ceremony and forgetting spirit-of-the-ceremony
- hiding behind charts and reports when expert observers keep yelling “ICE!”
“… fear will do irreparable damage to any software product.”
In another post, the conclusion of a simple thought experiment found that ten software developers could write an application without any input from middle managers, but no one should expect middle managers to produce software absent of software developers. This thought experiment established the hierarchy of dependency in producing software.
These software development people present a challenge to management who, for centuries, walked the overlooks above the manufacturing floor and directed the efforts of the simple brains and strong backs on the floor.
This conclusion contradicts nearly fifty years’ of managerial presumptions and claims about software development that process was more important that persons.
These software development people present a challenge to management who, for centuries, walked the overlooks above the manufacturing floor and directed the efforts of the simple brains and strong backs on the floor. These centuries of middle management depended on a social order whereby the fellow in the catwalk knew more and had more education than the strong backs on the floor.
That social order no longer exists – and the software developers on the floor may well have the greatest educations, intellects, skills, and experience of anyone in the company. Knowing some of those middle managers in my past, this may be the worst news of all the 21st century.
Better control over these challenges demands an investigation into the generalized definition of a software development effort: an attempt at defining both the software developer and the software a group of developers may produce.
Next: Something’s Wrong With Developers