The Micromanagement Disease

One of the many advantages of being an Agile Coach is that I get to interact with folks across the organization. I get to observe how developers work and how the folks leading and/or managing them behave. My organization has managers and directors of varying degrees of maturity. They also possess their own unique styles of management. In a development org where there are over 50 folks in management positions, invariably you find the world's most popular management anti-pattern - Micromanagement.

Symptoms

Our mature Agile implementation, which empowers teams to manage themselves acts as a great deterrent for micromanagement. That being said, having an Agile organization does not imply micromanagement cannot exist. Practices that are individual-focused, rather than team-focused are clear symptoms of micromanagement. These symptoms can include -

• Stand-ups that are status reports as opposed to opportunities for the team to collaborate.
• Focus on individual metrics over team metrics
• Multiple status requests all day, every day
• Manager/Lead needs to be in every meeting and ratify every decision
• There is an "Owner" for the process and for architecture
• Team has no involvement in making commitments, leads/managers make them
• Product Architecture is dictated to developers and only "Architects" can change/question it
• Team members do not make suggestions for improvement out of fear or apathy

There are many more symptoms, but the last one on the list here is the one that shows that the disease is in its most advanced stages. When folks doing the actual work, feel that they have no business voicing concerns or suggesting improvements, the management battle and conceivably the project is already lost. After all, people doing the work are the ones who know the problems they are facing and often the best at coming up with ideas to remedy those problems. Another important thing to note - Micromanagement is not just limited to Managers, it extends and is often exhibited to a greater extent by Architects and Tech Leads. These folks have often earned their stripes and seen code from other developers that makes them firmly believe that they can do things better. If you are "living with" an architecture, your Architect is probably a micromanager.

When folks doing the actual work, feel that they have no business voicing concerns or suggesting improvements, the management battle and conceivably the project is already lost.

Diagnosis

Managers and Architects are not bad people. Most are trying to do what they truly believe is in the best interest of the products and the organization they are involved in. Why, then do they exhibit the negative symptoms of micromanagement? I believe that there are two underlying causes for the symptoms.

1. Fear that employees will not do the right thing
2. Fear that upper management will not do the right thing

When managers are afraid their direct reports or the people they are leading are not going to do the right thing, the symptoms of micromanagement emerge. Managers might believe that their employees will not do the right thing for a couple of reasons. The employees might not have earned the trust of that manager that they are not 'lazy' and can actually make progress without multiple status reports. The manager might have been a great 'doer' who was promoted and firmly believes that she/he can solve problems better than the people currently doing the work. In either case, the result is the same. The manager maintains the firm belief that the project will only be successful if they are intimately involved in every detail and decision. They are only doing what they believe is the right thing to do, regardless of how unhealthy it might be for the overall system.

When mid-level managers believe that their superiors do not have their back and will not do the right thing by supporting them, they, in turn, transfer the lack of trust downstream. Since the middle managers are being asked for regular updates and are not being trusted, they do the same thing to the people they are leading. There are definitely cases where the middle managers absorb the pressure and don't transfer it downstream. Those managers, in my opinion, are the ones that need to take higher positions in organizations. When a middle manager's boss does not trust them, it also means that they have to prove their indispensability. This leads managers to be more hands-on and involved in the details and hence, not living up to their own potential. They respond to the lack of trust by being a micromanager that needs to have all the details available to them at all times in order to answer the questions of their superiors on the spot. When managers (especially the inexperienced ones), believe that their superiors will not do the right thing, they themselves start doing the wrong things. 

Cure

I wish I could say that I know the cure, but the cure has to be very context specific. If our diagnosis is correct, there is a trust issue somewhere in the organization. Lack of trust more often than not also manifests itself via fear. Fear to innovate, fear to try process improvements, fear to change or abandon prescribed architecture, even fear to speak up at times. How we get rid of that fear would depend a lot on the organization and the willingness of the people that make up that organization to try.

ask the question - "Do you feel that we are doing the right things and do you feel you have the freedom to change the things we are doing wrong?"

One way would be to establish and promote a culture of trust where everyone is encouraged and trusted to try to improve things every day. An approach would be to start at the line level and ask the question - "Do you feel that we are doing the right things and do you feel you have the freedom to change the things we are doing wrong?". If the answer is no, find out if it is just the direct manager that has the trust issue or is it systemic and goes up the chain to the highest levels. Very few will argue that fear and lack of trust is bad. Hopefully we can, through some tough conversations, drive consensus that we are going to trust the people we have hired. More so, when the symptoms of micromanagement emerge, we will diagnose where they are coming from and apply the appropriate cure to re-establish trust and remove fear from the equation.

Follow Up

We believe that it is our job, as managers, to make the project successful. When in truth, it is our job to help our employees make their project successful.

No one sets out to be a bad manager or a micromanager. There are conditions that lead some of us in that direction. For many of us, it is the fact that we ourselves were such good "doers" that we do not trust that our employees can do things well without our help. We believe that it is our job, as managers,  to make the project successful. When in truth, it is our job to help our employees make their project successful. If we trust and empower our employees to do the right thing, not just the current project, but any project the team undertakes will have a high probability of success.

Turning Our #NoEstimates Game Up A Notch

In an earlier post, I described how one of my teams went down the #NoEstimates route.  We had pretty good success going down this path. As a manager and a coach, it validated for me that how long it took for a story to get done had little correlation with the size or complexity of the story. In an organization with 30 development teams, we were definitely not the first team to stop estimating stories. We had other firsts under our belt, but that was not one of them. Very soon though, there was not a single product development team that was using story point estimates. It was the end of story point estimation, but as much as I would like to tell you, this was not the end of estimation.

First, a quick description of our work breakdown structure. We take long-term strategic initiatives and break them down into features. These features are then broken down into stories. The teams have the freedom to decide if they want to break these stories further down into tasks or not. Most teams choose not to use tasks as they do not provide much value to them.

At the story level, as described in the previous #NoEstimates post, limiting our WIP and right-sizing the stories made us more predictable. We were more predictable than we had been after years of trying to figure out estimation. The transition was easy for developers, as they always found the estimating conversations time consuming and wasteful. It was also easy for the folks on the product side of the house. The predictability gained counteracted the desire to get story level estimates. The other reason that the business did not have an issue with us going to #NoEstimates was our delivery level. We, as an organization, delivered Features and not Stories. Eliminating story points stopped teams from spending time guessing the exact "size" or exact "complexity" of a story. It did not stop the business from asking the teams to spend time guessing the exact "size" or exact "complexity" of a feature.

Teams across the organization were no longer estimating stories but were providing estimates for features in the following format -

The product team at that point would take these estimates and the team's forecasted capacity for the release into consideration for release planning. The product team would play 'Tetris' in order to fit as many of the features into the release based on these story estimates. For example, if the team working on the features listed above has a projected capacity of 80, the release plan would say that they can do features A, B and C (12 + 55 + 7 = 77). These features would then be advertised as the ones we are committing to for the upcoming release. 

On the face of it, this seems completely logical and sane way to go about releases planning. Unfortunately, this approach suffers from the same problems that story-level estimates have. 

• It is impossible to know the exact count of stories in a feature beforehand, regardless of how much analysis we do on the feature. 
• Features, more often than not "grow" and more stories are added while they are in flight. Planning to capacity puts features at risk, even if one of the features grows.
• In order to ensure completion on time, the largest of the features has to be started Day 1 of the release even if it is the lowest priority feature. This almost always puts higher priority features at risk.
• These estimates are based on initial guesses, which, when later invalidated, did not always invalidate the commitment.
• Large features are turned into multi-release efforts as opposed to being sized appropriately.

After struggling with these issues for a number of releases we started to attack these problems. We realized that we already had a blueprint for how #NoEstimates has worked for us at the story level. We decided to start applying the same to Features. To start, we first collected some data on our features. We discovered that 85% of our features consisted of 25 stories or less. This was our stake in the ground. We asked teams to start using this as a yardstick for whether a feature is too large or not. Teams had already been doing this for stories. Each team was very adept at "right-sizing" stories based on their data. The other necessary step in order to get #NoEstimates to work at the feature level was to limit WIP at the feature level. We asked teams to establish Feature level boards and limit WIP on each stage of Feature lifecycle (Selected, Analysis, Development, Test, Done to start with). Teams had again, already been doing this at the story level and this would be a natural transition for them. We, as a coaching group, set these guidelines and left the implementation in the hands of the teams.

The results were mixed. Some teams, due to various reasons, including external pressures, implemented a loose feature WIP and didn't quite go down the path of sizing features. Other teams, took the advice to heart and implemented strict WIPs on the number of features they would work on and not accept any features that were above 25 stories. When a feature seemed like it would be much larger, they broke it up into smaller features that could flow through their process smoothly. There were some things missing though. Even in the teams that took the approach head on, they did not do everything that they were doing to make themselves predictable with stories. They were not breaking up features into smallest deliverable features as they gained more information about them. They were violating their feature WIPs when emergency requests came in. In other words, our roll-out was only semi-working. Which means, we were becoming only semi-predictable.

Of late, we have changed our approach a bit. We have picked one team to work closely with and try out our approach. Apart from ongoing coaching, we are actively encouraging them to not provide feature estimates and to break up features as much and as often as possible, especially as they seem to approach the 25 story mark. We are trying to turn our #NoEstimates game up a notch. We are taking all the principles that we know work with stories and applying them to the Epics/Features. Limit WIP, Control Batch Size and Manage For Flow at the feature level, the same way as we do on the story level. Once we have these concepts proven out with this one team, we will roll them out to others in the department as well. Hopefully, all estimation conversations turn into simple conversations of "Does this work-item look like it is too large for this level, if yes, let us break it up, if no, let us start work on it."

We expect that this approach will make us more predictable with our features. The predictability gained should allow us to answer the question of - "When it will be done?" without having lengthy estimation conversations. The expectation is that this approach will also help us get to Just In Time commitment, where a feature is committed to only after it has been started Before the feature is started, the business can easily de-prioritize it and replace it with a different right-sized feature. This should allow us to be more agile and respond to market pressures and feedback more often. The hypothesis is that limiting WIP and controlling batch size allows for these things to happen naturally. Watch this space for results in the future.