A few years back I worked in some big software company. The place was huge, diverse and all about innovation. One of the most innovative things I learned there was micromanagement.
I was involved in quite an interesting development. We were building something like a pilot project or a prototype to see how the concept was going to be accepted by its intended users. We had a promising idea and we had an interesting and motivated team.
We decided to follow an agile development process. Naturally any other kind of organization was not going to suit here. We opted for SCRUM and tried to follow it. It didn't really work for us. We were constantly missing features, deadlines and overall orientation. Something was wrong.
Looking back in retrospective, I understand what was wrong. We were micromanaged.
We had two managers. The department manager and his aid. They were both managing us seemingly with no strategy or coordination whatsoever.
The bigger manager felt somehow compelled to review what we were doing at the implementation level. We were working on a database model. He was reviewing it either approving or not the choice of table fields and relationships and giving us instructions on how to redesign it according to his viewpoint.
It felt wrong. What could possibly a non-technical person contribute to the quality design of a data model? We were developers, we had the knowledge and experience, we were perfectly capable of designing it taking into consideration various technical factors like data integrity restrictions, keys and indexes. But we weren't allowed to do it right. We ended up with a very complex and in many ways a perverse data model with text fields as primary keys and absence of indexes at all.
Having done with the data model, we were supposed to code the logic. Here it came to round two.
The manager was regularly checking the progress and constantly correcting us in the slightest details. The choice of user interface controls, their locations, their texts and even the colors of the tiniest elements. Besides that this tuning was not yet needed and was simply irrelevant at the stage of the prototype development, it was very disturbing. We could see how many decisions were wrong from the points of view of usability, user-friendliness and harmony of colors. And we were forced to do this.
Basically, an unqualified person with no understanding of the things at any level, neither on the lowest technical end nor on the upper user interface end was deciding on everything. Developers were simply playing coders and were not treated seriously.
This was very disruptive and highly demotivating. When developers are not allowed to do their job right and forced to code crap from the very beginning, the project is not going anywhere. It is doomed at its birth.
It went further. Both managers were controlling us and giving us instructions on how to do things. In most cases they didn't agree on what had to be done. Or more likely they didn't discuss it between themselves so they didn’t know what the other one had in mind.
We were forwarded either in one or the opposite direction every few days. We completed one thing only to hear later it was wrong and had to be done the other way. When we did that and progressed further we were suddenly stopped and told to do it differently following redoing some of the work again. It felt like running while staying in place.
Not only does this form of micromanagement slow work down, it brings high risks to the project. A multitude of little things done wrong will turn a firm ground into a sand pool that will only engulf the vessel with time. A micromanaged project will see fiasco.
I didn't spend there long, happily. When I left I could see that the state of the project didn't change anyhow compared to when I joined the team. From what I could tell they didn't progress anywhere within two years. They designed and redesigned the data model about three times. They tried to build logic three times. They worked on three different UIs. When I left I had an impression it all was going to enter the loop number four. I felt relieved that I was not going to be around.
That was my first experience with the micromanagement in my until that time quite smooth practice. Of course, I didn’t know the word then but now when it's come to my attention I recognize the pattern.
Software projects cannot be managed in this way. There is a technical competence required for them to succeed. The competence that managers cannot usually provide. Developing a software project is not like opening a coffee bar. A manager could suggest the choice of furniture, music and maybe some drinks, but he cannot and should not even try to define the database model, application architecture and user interface details in the tiniest details. He has no knowledge and no competence. The team has. It should be allowed to do their job, to do what's necessary and to do it right. When there is a subjective decision to be made, it can be taken up to the manager and discussed. The manager knows more of the customer needs and his situation so he can provide some insight. He should perform the role of a consultant and a bridge to the customer, but not try to play the DBA, developer or a UI expert. Simply leave those in the hands of the team, trust them, believe in them and respect their decisions. Then there will be harmony in relationships and effective and productive work. And the project will get done.
Only strange that after all those years when software industry has seemingly learned all lessons already, has seen success and failure, with all those studies on the matters of team organization and project management freely available, with all those anti-patterns and best practices gathered and precisely described, somebody can still miss the point. Or is it only developers themselves who read these studies and learn from them while managers have never advanced beyond basic controlling skills?
