Monkey Developers of Micro Management

I worked in a reputed firm as part of the team of developers. We started off as small, only to grow over time in team strength and project size. We had a non-technical business owner and the project stake-holders provided us with broad objectives.

We worked on the features as we deemed so. When we felt that piece needed refactoring, we spent time to do it. When there seemed to be a rabbit-hole, we changed the architecture to hop off it. We didn’t ask permissions to do things in our domain, so long as we assured that we were in control.

You cannot monitor developers without affecting their creativity.

Then the company started to grow. Call it peer pressure or growth handling, or call it talent evaporation. As projects grew larger, the haste-full addition of features started to be pushed down to shrunk timelines — making it more delivery focused while removing the element of creativity. Things started to change and there were many of those planning meetings, road map generations, workflows and analysis — and this happened each period — altering the original plans quite dominantly. Planning is good so long as it is followed. Plans kept changing by the management, and the manager was displeased with the slow delivery due to changing plans.

We soon adapted, we started adding plenty of contingency to estimates. We shifted to focus on delivery. Any request to refactor the software was met with disapproval, and our time was too finely managed to allow us to refactor under the radar.

Then strangely, everything slowed.

There was a noticeable downward notch in the speed at which features were delivered. We became somewhat de-motivated. When people are micromanaged, it drains their will to such an extent that they no longer care. Psychologists call this state "learned helplessness." After losing arguments about how things should be done more than a few times, you start to have a pretty clear choice: zip up, don’t argue and get paid — or leave. One of the able team members did leave.

The workplace was not a happy one. Features took longer and longer to be delivered. There always seemed to be a mounting number of bugs, some gets fixed, some go unnoticed. The business spent more and more money for lesser and lesser benefits.

Why it all went so wrong?

Micro management is compelling to a business, as any organisation craves control. Businesses want to know what they are getting from those expensive payslips. They want to accurately guesstimate the time taken to deliver a system to perform effective cost-benefit analysis and give an accurate delivery forecast. There’s also a hope that by building an accurate mechanism of estimates verses efforts, they can enhance the software development process.

The problem with this approach is that it is based on a fundamental lack of understanding: Software development is a creative and experimental process. It is an organic process of trial and error, false starts, monumental cock-ups and architectural mods — it is a complex system of multiple feedback loops and interactions.

Numerous researches have shown that creative work is best done by autonomous experts who are self-driven and motivated. Developers need to be free to try things out, evolve from their actions, repell from bad decisions, try out several different things sometimes, before settling on what works. They cannot justify why they want to throw away everything in the middle of the task and change the strategy — because they should be free to discover a better way that’s not included in the road map.

As soon as you ask that geeky guy with black-framed pair of vision enhancers about what he will do in the next 3 days, and to send an update by end of each day about what’s achieved — you dramatically kill much of the potential creativity, intuition, gut and serendipity. You’re teaching him to be contingent and inflate his plans. You’re asking him to say something that will be appealing to hear — not what he may actually do. Developers start to look at quick fixes, hacks to just get the job done. You’re asking them to become inconsiderate of the next poor soul who will deal with this software. Micro management makes it hard to steal time for creative enhancements and innovation.

What happens then?

Micro management has all the ingredients for talent evaporation. People who feed on code and think in binary will start leaving — and usually easily can they find alternate placements.

Management will staff the company with compliant team that merely carries out instructions, doesn’t argue about utility of features, fills time sheets correctly and meets estimates, and produces poor quality software.

So what should be done?

Autonomy is the secret-sauce, the way out. It seems like a cliff-edge, but micro management is hazardous for software development. Throw high level goals at them and allow the developers to meet them as they seem fit. Sometimes they fail — you need to build contingency for failure and extension. Don’t react to failure by putting in more process and control. Build a great team that you can trust, one that works to success not timelines. Make a business environment for developers that’s passionate and fun — rather than encouraging one with passive code monkeys.