Micromanagement in the Software Engineering Industry

In software engineering, as in many disciplines, neither micromanagement nor macromanagement are productive ways to run an enterprise. But for software engineering in particular, micromanagement is especially pathological, and can be devastating to the enterprise.

First, micromanagement kills the souls of software engineers. Good programmers are smart people who want to solve problems, and they prefer having the control they need to solve those problems. If they don't get it, and instead are instructed to just churn out code from spec, or constantly have a manager asking them to push pixels this way and that - they're soon going to look elsewhere for work. Of course, if an enterprise's programmers are not talented, then it has other systemic organizational problems that it must solve first.

Second, micromanagement is impossible for projects of any real substance. Software is complex, and it's a full time job for one person to get a complete enough understanding of a problem to tackle it. Furthermore, software problems are moving targets. It is extremely common for requirements to change, often due to a new, better understanding of the problem. Managers don't have time to internalize the amount of knowledge needed to execute on the engineering side in such a complex, changing environment. If they do manage to find the time, it's likely they're shirking their management responsibilities, which is not good.

Despite this, a culture of micromanagement often pervades software firms. Managers in large firms, in particular, frequently fall victim to a micromanagement mindset, as the company code base becomes larger and the risk to the company grows. The traditional strategy companies have chosen to fight this risk is to try to fully define all functional requirements and use cases for a piece of software up front. This is both ineffective and wasteful.

There are other, more effective ways of reducing a software firm's risk without micromanaging its developers. Automated builds and software tests, for example, are an extremely effective way for managers to easily gauge the health of their company's software portfolio. If a culture of constant software refactoring is also applied, an environment is fostered in which software quality is not only measured, but also constantly improving. Finally, Agile software development practices like Scrum are effective ways for managers to iteratively evaluate features in development, to prioritize the next batches of work, and to manage the feature backlog. Agile software practices, in short, help managers and developers stay on the same page. The culture of the enterprise must be right for these ideas to take hold, but fortunately there is a huge constellation of literature on the subject, like Agile Software Development with Scrum by Schwaber and Beedle, that can get a firm on the right track.

Of course, a tendency towards macromanagement can also be unhealthy for software firms. If a manager chooses to macromanage, it can lead to a lack of developer direction, which may result in a really cool product or service - that ultimately you just can't sell. Instead, a more balanced approach is warranted, an approach in which software development is iterative; in which communication is frequent, respectful, and clear; and in which software managers can get back to what they do best: managing.