I've managed a few projects over the last few years, and one of the biggest challenges I face is avoiding becoming a micro-manager. I worked with a team once where I worked with a group of software engineers, and I was in the PM role.

When I communicate with the marketing team, or the design team, I find it much easier to trust their opinions and estimates than when dealing with the engineers on my team, mainly because I have worked as a software developer and have pretty strong opinions on what is the correct answer and what is incorrect. Looking back, sometimes I think that the decisions could have been a matter of opinion.

With the engineering team, I find we oftentimes get into debates about right and wrong, and I wonder if I'm crossing the line into micro-managing the project.

  • What situations have you been in when you've fallen into the trap of becoming a micro-manager?

  • How can one tell if he/she is micro-managing a project other than someone coming out and saying it?

  • What are some strategies that you've used to avoid becoming a micro-manager?

  • 4
    UPDATE: Thank you all for your wonderful answers! I upvoted each one! Each answer had some advice in it that I find extremely helpful. If I could accept all of them, I would. It came down to the two people who answered both the "How can one tell if [s]he is micro-managing?" and "What strategies to avoid this?" sections of the question. It was tough to choose between Johnny and OrenD's answers, but in the end the extra reading Johnny provided was very helpful; it focused on my problem but outside the field of software, which helped me see perspective more as PM instead of programmer.
    – jmort253
    Commented Feb 28, 2011 at 6:31
  • 2
    Very good question - thank you for asking it!! This is a good thing for any team leader or manager to watch out for: becoming an accidental micromanager.
    – user7102
    Commented Oct 15, 2013 at 17:14
  • 3
    As currently written, this historical post is an opinion poll. Polling questions are currently off-topic on PMSE. This question should be closed, but left for posterity.
    – Todd A. Jacobs
    Commented Aug 9, 2016 at 14:52
  • 2
    @CodeGnome Thanks for pointing this out and your continued efforts at helping to keep our site on-topic and clean over the years. Looking forward to more of your Scrum and Agile answers from you too! :)
    – jmort253
    Commented Aug 11, 2016 at 7:33

14 Answers 14


- What situations have you been in when you've fallen into the trap of becoming a micro-manager?

I agree with Ashes that this happens usually when there is lack of trust between managers and the team. Also, this can be a problem of the company's organizational culture, such as with a vertical, hierarchical organization.

- How can one tell if he/she is micro-managing a project other than someone coming out and saying it?

If you, in a manager role, survey your development team to know what is the motivation or realize they are leaving the company for the same reason i.e. "No hope of moving up", then it may be because the managers own every part of the project and don't let people make their own decisions. The problem is, when resolving conflicts, the manager usually is the one who has less information.

If you are making too many decisions to push the team forward then it can be a micro-management warning.

- What are some strategies that you've used to avoid becoming a micro-manager?

I like Joel's advice on Command and Conquer and the Herd of Coconuts:

  • everybody owns some area. When they own it, they own it. If a manager, or anybody else, wants to provide input into how that area is managed, they have to convince the owner. The owner has final say.

  • every decision is made by the person with the most information.

  • management is extremely flat. Ideally, managers just don't have time to get their fingers in the pies of their reports. You may be interested to read about a GE plant in North Carolina that has 170 employees who all report directly to the plant manager.

Avoid the "Command and Conquer" management or the "Hit and Run" management, unless you have a "Herd of Coconuts" on your development team. In other words, a manager must leave the developers alone.

  • 2
    Thanks for the links to Joel and the GE Plant article. I really like the fact that you included examples from outside software development! +1 I really enjoyed the GE Plant article.
    – jmort253
    Commented Feb 19, 2011 at 21:20
  • 3
    Thanks again for the non-programming example. We need more of those here, especially to help those of us who were former developers. The resources from other fields help us see how a PM doesn't need the technical knowledge to create successful teams, and it demonstrates how it is possible to trust the engineers to make the right decisions.
    – jmort253
    Commented Feb 28, 2011 at 6:33
  • @jmort253: You're welcome! I'm Glad that this answer (and also your question) helps you and many others who might have similar problems. Kudos on Joel Spolsky, who provided the GE article in the first place.
    – Johnny
    Commented Feb 28, 2011 at 11:04

One of the best methods I've found to avoid micro-managing my team is to ask questions rather than state statements.

Managers with technical background tend to feel they can solve their teams' problems, save them from making mistakes and tell them what is the right path to follow. This behavior causes micro-management, which prevents the team from growing and learning, as well as introduces an engagement hit in the team.

Whenever you would like to make a decision or state a statement and thus practically setting your opinion as the decision to be taken, just stop and ask your team a question. It could be a leading question, but let them think and come up with an answer. Sometimes the answer will not be aligned with your view. You can choose to let them make a mistake and bring it up for discussion with the team later on, so they learn from it.

By asking questions, the team make their own decisions and they feel they have the space and ownership in their domain. They do not feel they're being micro-managed.

Questions that could be asked to help teams reach high quality decisions could be:

  • Did you think about the performance implications of implementing it that way?
  • Do you remember what happened the last time we did this and that? How would you deal with this scenario occurring again?
  • How do you plan to make it on time to the integration point with the other team? How would you cope with the unstable lab setup we have now?
  • 6
    A coworker once gave me that same advice. Ask questions. And I have managers that do the same. It's very effective! +1
    – jmort253
    Commented Feb 19, 2011 at 21:26
  • 6
    One of my current managers over-uses this. He almost never makes a declarative statement. I understand why he is doing it, but now that I recognize the technique, I've learned to ignore the individual questions and listen for the line of questioning. @OrenD is right that if done correctly the employees "do not feel they are being micro-managed" - but if overused, the micro-management is still evident, and the indirection is annoying.
    – MCW
    Commented Oct 12, 2012 at 10:58

Micro-management is usually caused by deeper problems, notably a lack of trust between developers and their managers. Maybe this lack of trust is justified and maybe it isn't; but it needs to be resolved if possible.

Working both as a software developer and a manager, I can honestly say that both sides are happier when micro management is not an issue. As a PM, you just tell people to get things done and they take the responsibility to get it done. (Although, micro-management is an effective but often demoralizing way of ensuring an extremely high quality.)

If you're just debating estimates, I wouldn't consider that micro-management. I would say micro-management is when you take back and do the work that you've assigned to other people yourself. As an expert PM and ex-software-developer, you should provide your expert input into estimating.

  • 4
    I agree with what you've said, but don't ignore the problem of debating estimates. If you ask for an estimate, there should be mutual respect that the estimate will be fair, and that it won't be modified to suit some other purpose. If you find that a given person/team consistently overestimates their work effort, maybe it's because they don't trust you to not lower their estimates.
    – Elie
    Commented Feb 17, 2011 at 18:48
  • 3
    I believe that managers should be specialized in project management, not in their application domain. I've worked with managers who were both experts in software and inexperienced. The person doing the work usually has the best idea of how long it will take; trusting them is vital.
    – ashes999
    Commented Feb 17, 2011 at 20:39
  • 1
    Totally agree with the part about using PM expert knowledge into estimating rather than doing actual tasks.
    – WTK
    Commented Dec 7, 2012 at 10:41

If you think you might be micro-managing, then you probably are.

If you're getting involved in the technical debates among the technical team, you're micro-managing. The project manager should be doing project management.

If you're making all the decisions, you're micro-managing. Let your people who are most informed about the issues make at least some of the decisions.

If you're telling people how to do things in addition to what to do, you're micro-managing.

If in team meetings, you are the one doing most of the talking, you're micro-managing.


The best strategy is gaining an understanding that micro-managing is in nobody's best interest.

The best way to get past micro-management is to just stop. Easier said than done, but if you want to be a successful manager in the long run it's what you need to do. Be prepared, if your people are used to you stepping in to clean up their messes then they may fall on their face a few times because you have trained them not to look out for themselves. Let them clean up after themselves. It is the only way they will develop the necessary skills that you need out of them. If they can't do it then hire someone else. It is short term pain for long term gain. Your family will appreciate it when you aren't forced to put in the 70 hour work weeks because you haven't trained your team properly.

Every bad manager I have ever had has been an ex-developer that refused to give up the developer role. Being a manager is a full time+ job. You don't have time to be a developer also.


I stumbled upon this blog article that has some really great tips on how to avoid micro-managing a team and describes How to Better Track the Tasks You Delegate to Others.

The article includes helpful tips such as assigning a task to one person and making sure it's clear what the expectation is. Also, it's important to make sure that the timeline is clear so that there will be no surprises.

In addition, it's good to have a check-in date so that progress towards the goal can be measured.

The author of this article suffered from the opposite of micro-management, not following up on tasks. His advice not only can help a PM follow up, but I also believe the advice can help prevent one from becoming a micro-manager. According to the author, the best way to avoid micro-managing the project is to make yourself available for consultation if needed, but to stay focused on the outcome and not the process.


It seems like you're well on your way to avoiding micro-managing. Like they say, knowing is half the solution. Like Dunk says, the other half of the solution is to stop doing it.

Trust your team and let them make their own mistakes. --And build in buffer into the schedule to give accommodate those mistake. This is where your expertise should come in, in knowing what the schedule will be despite their estimates.

Part of your role as project manager is to be a leader. That means guiding them so that they can be their own, independent problem solving unit. By trying to solve their problems for them or arguing that they should adopt your solution, you are either being a pain to them or worse, appearing to use your position to get your way, rather than using it to lead them to become a better project team.


Micro-management is an indicator of problems in quality planning. You failed to institutionalize clear quality objectives. That's why very often you have to step in and discuss them again again.

As soon as you see a necessity to discuss "what is wrong and what is right" in technical decisions made by engineers - get back to the quality objectives. Are they specified in writing? Are they really objective?

A bit more on micro-management: http://www.yegor256.com/2015/09/22/micromanagement.html


One of the best ways to avoid micro-managing is to first realize that by micro managing you are turning yourself into a human bottleneck. Nothing will happen without you, and your productive time will be sucked away doing things and solving problems for others which they should have learned to solve on their own a long while ago.

Once you realize this, the question "how can I get others to learn how to solve their own problems?" becomes the leading question. From that moment on, you need to make time for your people to learn new skills, and that, coupled with a "I'll coach you to solve your own problems" attitude, is what will make them able to solve their own problems (aka "self organizing"). Along the way you will need to confront unrealistic deadlines, remove commitments, and confront issues you might have been avoiding-by-micro-managing head on.

Jerry Weinberg wrote

"Management, done right, is a very tough job".

He was absolutely right. I would read his book "Managing Teams Congruently".

I also will shamelessly add that I've written about this process in the book Notes to a Software Team Leader . I wrote the book I wish I had when I was just starting out leading teams.

Hope this helps.


Recognizing the problem is the first step.

Now, get to the root cause ... ask yourself why, then ask why you do that and so on until you understand what it is that's the core issue driving you to micro-manage?

Most of the time you need to let go, allow qualified people do their jobs and you need to work harder to make sure that they have whatever they need [just before they need it] to make them successful ... in other cases, although this is usually not the case, micro-managing is actually the appropriate thing to do [because somebody's not really mature enough or qualified for the assignment they've been given].

Recognizing the problem and then understanding the root cause will allow you to discern the difference.

  • Great advice. Thanks! +1
    – jmort253
    Commented May 11, 2011 at 4:12

By no means meant as a criticism, but perhaps the easiest solution is to find more work for yourself.

Micro-management is time intensive for the manager, and if you reduce your available time, you'll have to focus more on what you do or don't need to control.

Not recommended for workaholics, as they tend to borrow time from the wrong side of the work/life (or work/family, work/pub) divide.


Again, as a project manager, you have to lead , not to do.

To lead means you have to initiate your teammates' passion and expertise by asking questions and setting goals. Most importantly, to compromise the time frame for each phase of the project.

Afterwards, you only need to do project management and anticipate any risks involved by using risk matrix during the project phase.


I recommend that you recognize that, whether you are a subject matter expert or not, you are no longer a technical contributor. You don’t own those estimates or get to decide on what technique to use. To continue to try to define the technical aspects of the project will only lead to frustration on your part because you no longer have authority on those decisions. Change hats.

Some of the best advice I ever received, as a new app development manager, was when my manager told me he now measured me on the success of my team, no longer on my program development abilities.


I am Dana and I work as a project manager in a digital studio. I have 3 years experience in the field, in which I've helped build several web and mobile apps.

Here are my answers, I hope this helps:

What situations have you been in when you've fallen into the trap of becoming a micro-manager?

Especially when working with beginner/medium level designers or developers, I find myself trusting them less than I should. I start making design or coding decisions just to make sure we are moving fast enough, or in the right direction with the project.

What are some strategies that you've used to avoid becoming a micro-manager?

Trust your team! Give them the responsibility of the task - everyone will try to behave at their best if they know the client sees their work directly, and you are not there to clean it up. They will definitely check everything twice and be more aware of the quality of the design / code they produce. Be patient that they will also reach to the right conclusions - even if slower than you :). And maybe they'll surprise you and come up with even better solutions! Just make sure you state the requirements loud and clear, give exact & clear specifications for them to start with. Then, just "inspect what you expect" and give constructive feedback. By allowing your team to make mistakes and learn from them, you also allow them to grow and become more and more confident.

Not the answer you're looking for? Browse other questions tagged or ask your own question.