I've noticed that often people micromanage because they don't trust their team, but it's not necessarily because the manager is a dumb narcissist who vetoes their team's brilliant ideas as some of these articles tend to imply (although it certainly can be). Often it's because the team is more junior, or missing a critical competency, or simply hasn't had time to grow into an area they're working on.
If you feel like you're the only one who can do something correctly/to a high enough quality bar, it's probably worth teaching someone to do it the way you want. Sure it'll be more work in the short term, but ultimately it feels like your goal as a manager anyway is to get to the point where your team basically doesn't need your help.
There's also some tasks that just shouldn't ever be done by one person. E.g. naming features and global classes and functions. There isn't any way to know if a name is intuitive to everyone else unless you actually ask everyone else. Although this the canonical example of bike shedding, I've never once had a discussion about what a bunch of things in some codebase should be called that didn't result in the codebase getting massively better.
They then conclude that they're more senior and treat others, even people with far more experience than them, as juniors.
I've found that some Mangers like to micromanage so that they can claim more success of the project as well.
Also if the manager is also the expert in the technical area this can have the same effect. This often happens in small companies where the managers have been there about 10 years and wrote all the early systems. They take the role of manager, mentor, architect and code reviewer.
The solution which takes time is to start delegating out a stream of that work to a individual contributor who becomes the expert. This is a win for everyone. Less bottleneck for the team, less micromanaging, new ideas can flow in, and members build up skill and experience. New eyes on code, if they are good eyes can also lead to tech debt being paid off.
Jokes aside micro-management has its roots in insecurity and lack of being able trust. Perhaps for a small number it’s also about a power trip but for most it’s simply a lack of understanding of how to delegate and a false belief that you’re the only person that “gets it”.
That said one of the greatest feelings a manager is seeing people step up, take things on and do it in a newer and better way. You have to allow them to make mistakes which they will at first. But when you can get to this with a whole team, you end up doing things collectively which are truly bigger than the sum of the parts, and that’s an amazing thing to be part of.
I quit a job where I would only see the manager on 1-1 meetings, and was clueless about the state of the business and how to help team members succeed and get promoted.
I stopped discussing work topics on the 1-1 meetings since I didn't see any point, and eventually quit, as well as other team members.
I worked at a large Telco and after a year my manager retired. For the next 18 months I literally thought I didn't have a manager. Nobody ever came to check on me or assign me work (I had tickets to work on and fires to extinguish). When HR asked who my manager was and I had to tell them I didn't have one.
They were shocked and explained that by default the manager of my previous manager became mine, and I had to tell them we'd never met.
In 18 months he had never once come by my desk, called or sent me a single email. It was company policy to have monthly one on ones with all employees.
Of course, after that he got promoted!
Luckily for them I'm very independent and they had a lot of obvious problems to work on. But it was rather silly.
Micromanagement is a 'type' of management. As others have mentioned, it primarily arises from lack of trust or having a very rigid way of looking at things.
The manager that you mention should hardly be called that. These people are the ones who have been put in their position without acknowledging their strengths and weaknesses and will obviously end up back-firing.
I ended up shipping something that literally became the deal-maker for prospective customers who were considering us and a competitor.
The key word in that definition is "overly" and the measure of over, under, or just right amount of control is the person being managed -- what works or doesn't work for that person.
None of the behaviors the article listed are good, bad, right, or wrong in the abstract. If the person responds positively to very firm management and asks for it, it's not micromanaging. For another person, very light management may be too much.
How do you find the optimal amount? Partly by asking, partly by observing, partly by experiment.
Bottom line: management (and leadership) is a human-human interaction. What works is based on the person you intend to manage (or lead).
One solution is to hire more competent people and hand them the work. It's like outsourcing but inside. It's insourcing. And outsourcing works too. Place the work outside the business. This eliminates management.
Another solution is to minimize the complexity of what needs to be managed to the point where management is almost redundant. Instead of micromanaging, you create repetitive microwork that cannot be mismanaged. This also eliminates management.
I've witnessed first hand both methods in action and working pretty well.
On the flipside, I've seen many workers that require microapproval. They need appreciation for every task and credit for all of their achievements. They want to be supervised, but instead of managed, praised. They fail to find meaning in their work and are unhappy otherwise.
Also, micromanagement gets a bad rep, but actually, figuring out when micro management is needed is also a skill. It depends on your own skills and availability, your team seniority, etc. Outside of very junior programmers, the need to micro manage is often a sign that you did not hire well, but managers don't always have a say in firing people.
There are more subtle forms of micromanagement that even well-meaning managers and senior engineers do. The best instance from my experience as both is "leading by example." Even as a tech lead and a manager, I went oncall, I fought fires, and I was just not efficient at delegating.
I later realized my juniors took this message in a different way. I wasn't "leading by example", I wasn't empowering them to take on what they perceived to be "my work" and drive organizational change in a way I couldn't.
It was rough, because I was held accountable for things that my team refused to take part in. I was a new manager, and my boss had made it clear that I should basically do whatever it took to not fire anyone. I was a new manager, and I tried really hard to work with the team to get them on board, but ultimately there just wasn't any resolution other than "These people aren't right for this company". By the end of it (meaning when I quit), I was so burnt out I didn't care. I fired two, two quit, one changed teams. I got terrible reviews that year, but I also didn't really care. I didn't want to be good at what they wanted out of me, I learned.
That situation (team that refuses to 'get with the program') is actually one of the typical setup experienced managers have encountered in their career I think.
Contrast that against excellent managers who provide proper direction and allow their employees to safely fail for growth because you learn more from failure.
I couldn't quite "put a finger" on why I wasn't happy and had trouble getting along with the management and tech lead... And, why the tech lead was always frustrated with the manager.
It's because they were all micromanaging each other!
I’m a non tech founder And I outsource my teach overseas. I don’t trust my team.
I really feel over billed (I pay US prices (over six figures per year per programmer) even though this team is in South America) and they have failed over years to really provide a quality service. Not only that but they over bill me and I frequently catch it. Why don’t I switch forms - well, I’m scared I’ll have a worse experience with another firm, that I’d have to share the code base with someone else, and it would take another team a long time to learn the code.
So, I micromanage my billing, which sucks. Then I also micromanage the team - the design, the dev progress, etc. Why I do this is they don’t get it. I tell them to organize projects better and they don’t. I tell them how customers are interacting with the software and why we’re building new features and design doesn’t get it. I get software and it’s full of bugs which I have to personally test and the dev team says we should just launch.
I’m not going into super details here, but I’m on burnout constantly trying to deal with these people. If I were to let them just do their thing, my project would have failed long algo.
When you hve a vision, micro manage. If you’re at some firm where you are struggling to spend your overly massive budget every cycle, dont micro manage.
Big difference in big companies and small ones. If you’re not micro managing as a small startup, you will fail.
Ever seen a real rich person outsource to another firm, share their idea, and let the firm create everything in their own - that’s a bit fail waiting to happen. And the dev firm knows it and is happy to take as much money from you as possible.
Well that seems to be your first problem. If someone isn't doing their job, and they don't get better after having a talk about their performance, you find someone else. Watching their every move is not a viable solution.
It sounds a bit like you're not setting clear/reasonable acceptance criteria, and as a result are not getting what you want.
> Ever seen a real rich person outsource to another firm, share their idea, and let the firm create everything in their own - that’s a bit fail waiting to happen. And the dev firm knows it and is happy to take as much money from you as possible.
Yeah, and they probably deserve every penny. People who want something very specific, but don't really know what it is and can't explain it, are miserable to deal with. Running a business is a skill, it takes more than just an idea + $$$$
This is the least surprising sequence of sentences you could have possibly come up with.
"If you’re not micro managing as a small startup, you will fail."
This is patently, provably, and demonstrably false.
You could be making the classic mistake of throwing good money after bad money. If you try a new firm, you still have a chance of things going wrong. But if things are going wrong with your existing firm and you can't pinpoint/address the root cause, you can be a lot more certain things won't change.
> Big difference in big companies and small ones. If you’re not micro managing as a small startup, you will fail.
Success is a better teacher than failure, so are you sure you should be speculating about what kinds of management styles succeed or fail when by your own admission, your micro-management leaves you burnt out and without results? Based on my experience, it's almost always the case that startups only succeed in scaling by avoiding it. It has to do with delegation.
Micro-managing is tacit acceptance of an inability to delegate. A team which fails to master delegation will fail to scale past the team lead's individual communication bandwidth capacity. That happens really quickly if you hit hypergrowth. You basically guarantee failure in a way that will make it really difficult for you to learn how to run a team any more effectively.
It looks like that's your experience. Could you consider the possibility that an alternate approach could get you mileage? Why not find a trusted advisor to help you select a better firm? Perhaps you might have difficulty selecting a good firm, but it's possible that someone you know who has more experience with software could help you. After all, by your admission, you spend a lot of money on this purchase. Why not experiment with different approaches and see if you can get more ROI out of it?
I'd bet money that if you found a good engineering leader and delegated delivery to them, you'd save money, time and headaches. Of course, you'd need to be willing to take the risk to invest in that, which is something you could fail at. But running a business these days is all about figuring out how to take risks successfully and improve your ability to do so.
Such people try to get away with this by micromanaging because they panic, but that's usually no solution.
That said, it can work if the non-technical founder is lucky and just happens to get a good team, but they have no way to evaluate the required skills themselves.
Using this approach can be a little slow in the beginning or when adding new team members, etc. but over time you and your people come to understand how to communicate with each other and trust each other and the team will be happier and more productive because they are given the space to work the way they find most effective and enjoyable.
People that are micromanaged are almost universally miserable and it's hard to reach the highest levels of productivity with a miserable team. At least (in my 25 years in business) I've never seen anyone do it.
Some things to keep in mind:
1) Having a project manager on-site that works directly for you helps.
2) Keeping the productive team members and not renewing the rest works well.
3) Outsourcing items with a past history of success and keeping other items that failed on-shore can work too. For example, I outsource web design and QA, but keep development local.
4) Dumbing down items to match abilities helps. (One PM I know told some members writing bad code to do Stackoverflow research for the project instead.)
5) Beware of common outsourcing games.
i was once on a project where an app didnt even have images that were the correct (not even proportional) size becuase "sqaure images" werent mentioned in the spec!
[1] https://www.cnbc.com/2018/10/19/tesla-ceo-elon-musk-extreme-...
No one at that level has issues with delegation either. It's far too much work and too many people. So what they activily manage are results. And because results involve people, you can get yourself steamrolled if you're in their way.
The way Elon gets his hands dirty in so many parts of the business attest to this. A micromanager would manage everything all the time. Elon simply goes from one hot spot to another with uncompromising focus on detail.
Engineering requires attention to detail. A disgruntled employee can always pull out the micromanager card. And any executive coming down the chain to put out a fire or fix or change something will be deeply "on your case".
Think of it this way. If you work at Tesla is Elon your manager? No. Then if all managers at Tesla abide by a "code of micromanagement conduct" then I'll take that as valid evidence. Anything regarding executive decisions, preferences towards automation, and employee complaints? Not so relevant.
Is Elon perfect? No. The way he reopened his factory amidst Covid was disturbing to me. And although we have all these "Elon is a micromanager" pieces, the media generally gave him a pass regarding Covid. It was not brought up during his earning report reporting and no one seemed to care on HN either when commenting on earning related stories. But I guess it all depends where the voices are coming from.
https://www.cnbc.com/2018/10/19/tesla-ceo-elon-musk-extreme-...
Sometimes, a manager may be very involved in some specific artifact which may 'seem' like micromanaging but really it's 'topical' management.
Often Micromanaging isn't actually inherently 'wrong' or even bad, rather, it's the emotional corrosiveness that is the problem, i.e. people just don't like to be managed in that way, but, if we were all 'perfectly and completely mature team members' it wouldn't bother us if it was appropriate. But that's hard and most people just don't like it.
That said, it can be a 'true problem' in the sense that managers are too in the weeds - and a 'true problem' in the pragmatic social aspect in that if people 'really don't like it' then it's just not going to work out even if technically it could be warranted.
There are so many managers I've seen who are really high EI, who would never dare micromanaging, because they instinctively see their job as a popularity contest. They really don't actually care about the product or outcomes, they are not built that way, they have been managing their lives through the spectrum of likability, and instinctively feel that when 'everyone is happy' they are doing a 'good job' irrespective of outcomes. In many organizations this is actually normative.
And of course, there are just a lot of bad managers out there as well, micromanaging where they should not, with no sense of making better outcomes even as they believe they do.
Self awareness is really hard.
Either you hired someone whose competent so you should let them do their job, or they're incompetent and you should fire them and hire someone else.
First 'Special Conditions' - The gap between 'customer' and 'engineer' can often be quite large. Junior Engineers especially generally don't have an intuition for those things, and often 'the technical details' deal directly with feature orientation. There are legal issues, operational issues, so many 'bigger picture' things that are relevant. Cross-functional issues are definitely a thing, which is why a guy like Musk is probably managing a few layers deep, and 'very deep' in some specific scenarios.
Musk is a good example - because when he intervenes, because he has 'a lot of legitimacy' as 'founder and supposed genius' - people may not feel 'micromanaged' whereas if it were any other situation they very well might.
You may have a very complex code base where the architects, or Senior Devs who built the system need to intervene with a bunch of things to ensure consistency, communicate much of the 'unspoken' idioms that exist, and provide 'leadership by example' etc. etc..
For example, I trust my team members a lot more in the Java/Python domain, I almost don't trust anyone in C++ there are just so many ways to skin the cat, so many horrible anti-patterns, I've seen it all, so I like to take a really good look at the code. Often a second set of eyes helps.
On the whole, yes, micromanaging probably shouldn't be constant, but it can be consistent.
Second - there are skills (and communications) gaps in every resume. I'm literally managing a small offshore team right now, not getting adequate response when asking some specific questions. I've come to the conclusion they are literally not considering a whole pile of corner cases. I'm going to have to step in and hold their hands through a set of functions that they, for whatever reason, are not wading through very well. Fortunately, I have a ton of experience with this, and it will be ok.
This idea of 'if they are not good enough use someone else' is a little bit glib because far more often than not, it's not an option - either you have an incumbent team, budgetary/timing issues, and frankly, even if you didn't have limitations there, it's hard to evaluate people anyhow.
Finally - I will say that there are some situations where micromanaging probably is going to be constant. For very young and new developers on any kind of complex system ... they will need to have a lot of coaching and oversight. Even little things like tooling usage, which may not be 'formalized' because the team is in good sync, or the team is senior, but you have a junior who's not familiar with the git idioms on the team etc...
