I was in an interesting round-table discussion with managers of different disciplines: accounting, marketing, etc. The topic was micro-managment — centered around a hypothetical CEO who was copy-editing his top marketing director’s work before it was completed. There’s lesson behind the story; was he micro-managing? If so, how? Was it appropriate? What would you do? Is it appropriate for marketing or accounting?
A CEO who micro-manages a marketing flyer gets exactly what he or she wants. It’s not productive nor a display of trust, but it “gets the job done” in the short-term.
A manager, at any level, can never successfully micro-manage software development. I’m not diminishing the value of marketing, accounting or any other difficult objectives or skilled people. Those who don’t have a software development background often do not understand, don’t want to understand or have misconceptions about software development.
Software development is not copy-writing. It’s not ditch digging. Software has the ability to be: changed, shaped, scrapped, rebooted, combined, separated, at any time, in any place. Hardware is mostly unchangeable once its delivered. Software gets it’s name because it is “soft” and relatively amorphous. Software development is not brain surgery, either — but is much more difficult in many ways and easier in others.
A marketing flyer in the mail is finished — it’s time to move on to the next task. Software is never finished. Its malleability is its primary advantage — the expectation from stakeholders: more, faster, cheaper, better. Comparatively, marketing is hardware.
Software cannot be micromanaged because software developers are already micromanaging it: they are dealing with tiny details, changing requirements, buggy libraries, limited memory, slow disk drives, conflicting logic, short timelines, bad abstractions, broken tools. You will never see a non-technical CEO rolling up white shirt sleeves and bang out a few lines of Haskell in an emergency.
A good software development team will micromanage the heck out of everything for you: finalize requirements, write code, plan for capacity, test features, deploy, monitor, support, fix bugs, add features and eventually pull the software product out of production when it is no longer useful.
A software developer naturally over-estimates how long code will be useful. Others often under-estimate how long code will be valuable — its real lifetime is somewhere in between. A good software developer is trying to predict a future and a place — for requirements and code that do not exist yet. The more experienced they are, the bigger and clearer their crystal ball — hence the developer’s adage: “the customer doesn’t know what they want (in the future).”
The worst mistake a manager can make is thinking a software product is finished when it is first deployed to production. The second worst thing is to move developers off to a new project soon after. If a development team is delivering key enterprise systems or core-business capabilities, the absolute worst decision is to *not* keep that team working on their creations.
Software developers are creative technical problem solvers who will turn vague requirements into multiplicative value — sculpting formless zeros, ones and a few billion NAND gates without touching anything but a keyboard. A good developer has pride in their work and will fix things before they are a problem, if they are given the resources to do so. A good developer hates bad code, even if it is their own and will make it better, without being asked — for the customer, themselves, each other and the future. A good developer will also tolerate a mess for a reasonable trade-off, but no skilled developer wants to work in the code equivalent of a dirty frat house.
Thank your developers for micromanaging all this stuff by keeping them close to the code they built with their mind and carry into their sleep — and near the knowledge that leaves when they walk out the door.