In part 1 of this series, we looked at the underminer product manager. In part 2 we talked about the dinosaur. In part 3, we looked at the erratic driver. In part 4, we will look at the micromanager.

A micromanager refuses to trust other team members to do their work properly. Micromanagers can’t let go of their projects, and don’t give people enough time and space to complete tasks on their own.

This is the most challenging management anti-pattern to write about because it has been talked about to death by people a lot more qualified than me. However, it is so common on software teams and so destructive that it needs to be addressed. While micromanagers are often concerned about positive project outcomes and making team commitments, their behavior has the opposite effect of what they intend.

I repeat: IF YOU MICROMANAGE, YOU WILL CAUSE THE OPPOSITE EFFECT THAT YOU INTEND.

Microscope image from pixabay.

 

There are usually two different kinds of micromanagers:

1. Outcome obsessed. They are overly concerned with budgets, timelines, resources and logistics
2. Insecure. They are distrustful, lack confidence in their own abilities and project those feelings on to others

Early in my career I worked with two very different product managers: Mike and Jenn. Mike was a micromanager, Jenn was not. Both were programmers who were put in charge of their own products. They had developed new product prototypes on their own, and after there was sufficient customer interest and company buy-in, their job was to manage the product overall. That meant they talked to customers, did work on research, assisted with pricing models, and helped oversee product development and lifecycle management. It also meant they had to win over team members who worked on cross-functional teams to commit to working with them.

Mike was charismatic, an effective communicator, and had an overwhelming positivity about getting projects done and out the door. In brainstorming meetings, if someone said “it can’t be done”, Mike was the first to disagree and offer to try. He usually failed, but his efforts would inspire the team to figure out that there was indeed a way forward. Without his fearless efforts and inspiring manner, many useful ideas would not have been pursued. Mike was able to inspire others, and get them on board with his ideas, so he had a lot of initial team support for his product. However, he took any kind of criticism deeply personally, and would argue with people who didn’t appear to agree with him.

I was part of a small technical team assigned to both products, and we were closing in on shipping a version 1.0 of both within weeks of each other. It was hectic, and we could also be called in to help with customer concerns or high risk production issues at any time. The team was quite diverse; there were eight of us with different backgrounds and various levels of industry experience. It was up to the product managers to negotiate our time (within limits) and we had a senior project manager overseeing tasks and budgets and logistics. We were using two week sprints, and the project manager would meet with each of us at the end of each week to get a sense of where things were at and to see if we needed any help. The rest was up to the product managers.

Jenn worked on her own deliverables, and had publicized, daily office hours when we could stop in and ask questions without scheduling a meeting. She also wandered around and talked to each of us individually at the end of each day to see if we needed help. She let us determine the length and frequency of daily standups. Mike was militant about the daily standup, but the meeting would run over time because he would question absolutely everything anyone said. Mike also wandered around to check on us, but it felt like he was never not around. He would walk up behind us, stare at our screens over our shoulders, and ask what we were working on right then. He would then second guess our decisions, and argue with us.

At the end of each sprint, Jenn held us accountable for our commitments, and if we missed something, she would step in and help us adjust. If we felt we weren’t going to meet a commitment, we told her immediately, and she would work with the team to help us get back on track. Mike on the other hand held long, painful sprint demo meetings that could last for hours, mostly with him expressing disappointment in what we had done. We told him that he was getting in the way, and he needed to give us some protected time to actually deliver something instead of interfering all the time. He kept insisting that it was his ass on the line and that was that.

The micromanager:

• second guesses everything
• is distrustful of team members skills, their decision making, and their use of time
• never seems happy with anything you do
• focuses on the small stuff and loses sight of the big picture
• complains about people arriving late, leaving early, and taking too much time on breaks
• seems obsessed with up to the minute statuses
• loves heavyweight processes and lots of documenting of everything
• requires a lot of time entering and justifying time spent on tasks
• obsesses over measurement tools and metrics
• spends excessive time working and insinuating themselves in as many meetings as possible
• causes people to feel like someone is always watching them over their shoulders

As time went on, and Mike’s product was losing out to Jenn’s for time, focus and attention, his behavior worsened. We did everything we could to try to talk to him about it, but nothing seemed to help. Finally, out of desperation, all eight of us added an “arguing with Mike” item to our timesheets. After a week, the project manager came marching into the office to ask what the hell was going on. Why was there an “arguing with Mike” item in our timesheets, and why was there a team average of 8 hours per day being spent on it? It turned out that each of us were averaging at least an hour a day dealing with his micromanaging behavior. That averaged out to 40 hours a week! It was an expensive waste of time. This triggered a senior management intervention, and they talked to Mike. He was upset with what we had done, but understood we had run out of options. Eventually, his project was so far behind, he lost funding and Jenn’s project shipped. He was given two more opportunities, but in spite of a lot of senior management support, the behavior persisted and he was demoted and let go. Mike’s efforts had the opposite effect of his intentions. What went wrong?

There are some important negative outcomes of micromanaging to be aware of. First of all, when you don’t allow people the freedom to make decisions about at least some aspects of their work, they’ll be afraid to be creative and their work products won’t be as good. When they feel that you don’t trust them, they will resent you and will only do the minimum required. If they feel that you are counting every minute they spend on a particular task, and how long they stay for the day, they will count every minute they spend on your projects. When they have finished counting, you won’t get a minute more of their thoughts and efforts. If you second guess their decisions, they will lose confidence in their own abilities. When you measure at the micro level, you will miss the important things, like deadlines, budgets, key feature deliverables and even shipping the product itself. The last point might seem counter-intuitive – if we are really concerned about deliverables, budgets and timelines, won’t micromanaging help, even if people don’t like it? The answer is a resounding NO!

Measuring the small stuff causes everyone to lose sight of the big, important stuff, like features, deadlines and budgets. There are only so many hours in a day, and of those, only so much time where people can focus on project logistics. If you spend all that time worrying about things on the micro level, there won’t be any time to work on the macro level items. Furthermore, if you measure people at the micro level, they may deliver, but it won’t be in alignment with the rest of the team. They (and you) will lose focus and you’ll have what I call a “bucket of features”, but not a cohesive product.

The human cost is brutal as well. You will have people who only work for the time they are paid for, will be unable to be creative, won’t think about problems on their own, and will be worn out and fearful. Most of your team will actively look for another job. Creative people who are outspoken will at first display anger and find another job as quickly as they can. People who have more responsibilities and others depending on their salary will stay longer, but they will shut down and only do what they are told. Team morale will plummet, and you as a product manager will have to work ten times as hard to get anything out the door.

I’ve worked on teams that were dedicated, creative and had great cohesion and were in alignment with senior management, only to have a micromanager join the company. One example was a cutting edge startup that was well capitalized and was on a huge growth trajectory. I helped them with some basic growing pains, and it was a great place to work. People arrived early, stayed late, and the place was a constant buzz of energy. They loved their work and to be at the office with their coworkers. The problem was that people were doing too much, so they had to put in rules about how many hours a week you should work (so you could rest and be refreshed and productive) and to take your vacation. Employees still researched on the side, and took online courses to learn more to bring to the table. There was a quicksilver of creative problem solving that was infectious.

Six months later, I returned. The once bustling, busy office environment was quiet as a tomb. Management complained that people only put in minimal time and effort. The lunch room and break rooms, once hubs of knowledge sharing and teamwork were dead zones. People would rush in, get what they needed and leave. No one arrived early, and no one stayed late. (NOTE: This can be abused too, so don’t expect people to work overtime for you without pay. When people want to spend a few minutes here or there extra, try to reward them for it.) Productivity was down, and senior management had to put in a lot of overtime and have a lot of meetings to repeat goals, and supervise product development. A bit of investigation revealed that they had hired a micromanager and put them in a significant position of power. One project that year shipped on time. Product quality suffered, clients got upset, and staff turnover went through the roof. On some teams, people would stay for an average of three months. It was horrific to witness. One bad hire ruined the company and they never quite recovered.

What do you do instead?

• give people enough time to meet deliverables – days, not hours
• leave people alone to get stuff done! (unless they need help)
• be visible, available and encouraging in case they need to ask you questions or need encouragement
• make lost time due to micromanagement (especially your own) visible
• empower people and trust them to do the right thing. Just because they do things differently than you like doesn’t make it wrong
• people make mistakes. If they are honest mistakes, use them as learning experiences, don’t hold a grudge.
• pick battles: live with some outcomes that you may not like, but move the process towards shipping instead of nitpicking
• measure value points at a higher level such as features delivered, products and services shipped rather than individual tasks
• hold people accountable for missing their commitments and make it visible so everyone knows where the project status is
• succeed as a team, fail as a team – don’t single people out unless it is required due to performance issues, attitude problems, and do that in private

More recently I was asked to help a team that was struggling with delivering software for a new client. This was a startup that was well funded, but the CEO was worried about team performance, so I was called in. Dave, the CEO, had hired experienced developers and an experienced project manager. The team was very small and deeply experienced, so the first red flag to me was that they needed a project manager at all. Dave and I had worked together in the past, and while he saw the value of a product manager, he decided to also play that role to save money. Dave read articles about product management, and took a short webinar on how to be a product owner on an Agile team. He did his best, but he knew something was wrong – they had been working on a 3 month project, and 6 months in, they had nothing to show for it.

When I arrived as a product management consultant, the project manager was on the way out. The programmers had resorted to working from home as much as they could, in spite of having a well appointed, modern work environment that they had designed for themselves. Any meeting of three or more people would devolve into arguments that were unhelpful. Any meeting of two or more people would catch Dave’s attention (he had a nice office with glass walls, and faced outwards) and he would swoop in, eavesdrop, and then start to get involved, no matter the topic. Daily standups were no longer held in the dev area, they had moved to the boardroom with everyone sitting down. This was because every person who spoke up and reported what they were working on, what they had accomplished and if they were having any problems were grilled by Dave. It took far longer than a few minutes. To cope with this,if you didn’t want to be grilled, you didn’t say much. Also, if you didn’t do much work at all and kept a low profile, you flew under the radar and were spared. (Result? Several people were doing little to no real work for fear of reprisal.)

Dave was a type-A personality extrovert, and he was working with mostly introverted technical people. They needed protected time to be productive, and he needed to talk to people to think. Anyone that was sitting quietly that caught his eye would fall victim to a chat. Dave didn’t realize that the programmers needed protected quiet time to be productive. It was even worse when they were pair programming. Dave’s efforts had the opposite effect of his intentions.

This required a major intervention, and I wasn’t sure if it would work, because it meant Dave had to go through some personal growth. I would too, by virtue of working with him and both of us solving this particular problem together. I was willing, Dave was willing, but were we both able?

The first thing I did was create a product roadmap. Dave felt it was an unnecessary expense since the team was small, and they were already behind schedule. Why would I spend the first few days on that? But, he trusted me, so we worked on it together. Once we had that squared away, and the team agreed with the vision, I implemented a simple project management system. We used spreadsheets to create a product backlog and sprint backlogs. We only used the project management software they had been using for bug reports and high level features. We created a status dashboard on a whiteboard, and since the team was now a bit distributed, we re-created it in a spreadsheet that everyone could see.

Dave was banned from standups until he could learn to be an observer, not an active participant. He was also banned from engaging with staff who were working, unless they initiated it, or were in a break room or the lunch room. If they were at their desk, unless it was an emergency, they were to be left alone. If he needed to talk, he had to talk to me first. We also recruited a couple of his peers that he trusted deeply to stop in or call him more frequently so he could talk through ideas and get what he needed.

Next, we prioritized features and tasks, and the programmers made their own commitments for them. They decided a two week sprint was adequate, and signed up for an ambitious set of deliverables to demo at the end of that sprint. I was skeptical because it was so ambitious, but I kept my thoughts to myself. Dave was also skeptical, because he wanted more. Thankfully, he kept that to himself (and me of course.) I also told him to back off for two weeks, and if the deliverables weren’t met at the end of that sprint, then we would be worried. People needed protected time where they actually had a chance of delivering. We empowered them to make their own decisions, and to come to us if they needed help, but they were on their own. I would be visible and available, but no one would hound them anymore.

This was INCREDIBLY hard for Dave. He constantly backslid, and he would pull me into his office or phone me several times a day. I sent him daily status reports using a template for client billing, and he would phone me immediately after I sent them with lots of questions. But after a few days he settled down and decided to trust the process.

I’d love to tell you that at the end of two weeks the team delivered and everyone was happy, but that was not the case. It was a mess. There was nothing tangible that was delivered. Two team members realized they were in over their heads and resigned, and one engineer was put on probation for poor work and was eventually let go. Dave was furious at first, and told me he wanted to fire everyone, but after sleeping on it realized where he had gone wrong. His constant micromanaging had hidden skill gaps, and there were no real methods of accountability. He went from one small problem to another small problem, and people didn’t sign up for anything, didn’t commit to anything, and he had no way of measuring real progress. Micromanaging actually destroys accountability. With the simple, yet visible system we used, problems related to product development became apparent almost immediately. People signed up for their own commitments, and if they failed to meet them, it was visible.

The team was in crisis, and Dave knew they were in serious trouble. If they didn’t meet this commitment, they would have no revenue growth and would likely go under. However, instead of panicking, he rose to the occasion, as did the experienced senior team members. We managed to recruit a couple of expensive, but skilled consultants to help address the skill gaps, and we got it done. The product was gorgeous looking (we had a fantastic visual designer), but it barely worked. However, the client loved the first version, and it was good enough. There was an enormous amount of refactoring that was required, but it got the job done. Revenue trickled in, board members and angel investors were appeased, and the company lived to fight another day. One of the consultants even stayed on to work full time with the team because they enjoyed the work and technology so much.

Eventually the team were able to go back to the process they had been following in the past, and left the spreadsheets behind and mirrored that functionality in their productivity tools. It was harder for Dave to adjust. He went through a lot of painful personal growth, but came out the other side as a much more solid leader. After the fact, he shared with me just how difficult it was, and how he had to resist his initial instinctive reactions. A couple of board members and trusted advisors answered his call for help and really helped him through some tough times outside of the office. It took a long time for him to regain trust in the people, the team as a whole, and the process. I urged him (and still do) to measure outcomes that demonstrate value, (such as working features, products and services) rather than on tasks. That way, the team can excel at doing what they do best, and he can be involved and completely focused on the incredibly difficult job of CEO. (Yes, he did hire a product manager to delegate to, and project management is shared among senior team members.)

Mike was a product manager who was insecure and unable to go through personal growth to become a good manager. Dave was an outcome-obsessed leader, but he still had to go through painful growth. The Mikes of the world have talents outside of leadership, and that is fine. The Daves are usually fantastic leaders, but need good creative product builders. Mike went back to being a creator rather than a leader, and had much better success. Jenn was a unicorn who could switch between technical and leadership roles – they do exist.

There is a lesson here for all of us: all of us will have elements of dysfunction in our leadership approaches and personalities. When under extraordinary stress, these will become much more apparent. When we feel pressure and the team doesn’t seem to be responding the way we’d like, it is incredibly tempting to micromanage. But remember: IF YOU MICROMANAGE, YOU WILL CAUSE THE OPPOSITE EFFECT THAT YOU INTEND. All of us need to take a cue from Dave from time-to-time and deal with our weaknesses head on, for the good of the team, and most importantly, for our own good.

Note: I first wrote about the micromanager management pattern in this article for Agile Connection.