________________________________________________________________________________
I don't see one of the most important parts of how to stop micromanaging, which is to _help your team grow_. I don't mean add more people, I mean to grow the skills and competencies of the people already on it.
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.
> I've noticed that often people micromanage because they don't trust their team
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.
Yeah it is a bit funny that naming is the go to bikeshedding example because in my experience poor terminology surrounding a project can be hugely detrimental (e.g. names that have nothing to do with what is actually happening) and vice versa.
For awhile there, I was “the second opinion” if you outsourced a project. You’d hire people like me to tell you if it really would take 100 man hours to make photo uploads faster, or did they really patch a security issue, etc. It was pretty neat to read so much closed source code. But more than once, the developer would send obfuscated code and claim that it was how they worked on it. Only once did someone say, “oops, here’s the right version”.
Those projects taught me how important naming is, more than anything. Some people like to say that you don’t need names.
I’ll be the first to say that they’re probably right (considering the code executes) but damn does it make life easier when things are named well... and less expensive for everyone.
I'm curious, how would they obfuscate code and how could you tell?
I think this is spot on. I took over a team of quite junior engineers who had been let loose without much guidance under their previous manager. I introduced a lot of new ideas, and imposed much higher standards on their work. At first this meant code reviewing everything myself and going through everything in so much detail that it would have been much quicker to do it myself. But that allowed the team to grow, and while I still give some input, they're now they're mostly working independently and reviewing each others work.
I'm not really sure i would call that micromanaging
The problem with larger corporations and bigger hiarchy is some Mangers egos are are boosted by their titles.
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.
What can make this hard is wearing multiple hats. Your boss might be micromanaging, but not with the boss hat, but a senior engineer hat, or an architect or product owner hat. I have considered introducing a convention where people declare what hat they are wearing first!
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.
There’s a joke I make with colleagues for a fantasy startup we’d call Micromanagr. The pitch “The problem with micromanagement is it doesn’t scale... until now”
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.
The opposite of micromanagement can be damaging as well. Let's call this "no management".
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.
A my last $job I had a direct manager for the first 3 months then they moved on and a replacement was never found. 2 years later his manager (my ex-managers manager) quit and was never replaced. I worked there for just about 3 years total with no real manager.
Luckily for them I'm very independent and they had a lot of obvious problems to work on. But it was rather silly.
Reminds me of Forgotten Employee [1]
1.
https://news.ycombinator.com/item?id=17332440
Interesting, I thrive with as little management interaction as possible. Ha. monthly 1:1 is more than enough.
I know all about this!
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!
The common pattern of behavior I have observed with micro managers is a fear of perception, such as a fear of looking bad. Most commonly this manifests as the boss wanting a hyper selective output they wish they could do themselves because either they do not trust the employee and/or because they cannot communicate what they want.
Contrast that against excellent managers who provide proper direction and allow their employees to safely fail for growth because you learn more from failure.
Micromanaging might be one way to salvage a project that may have suffered due to inexperience on the part of the ones it was delegated to. In an ideal situation, to avoid micromanaging altogether, a manager must have extremely capable team members that are aligned with the common goal.
I had a gig with a company that could only retain very junior developers. I was very nervous going in, because only retaining junior developers implies that the management can't get along with experienced developers.
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!
Excellent; thanks for sharing. If there were a convenient way to anonymously share links, this could be a game-changer for a lot of people.
If you are referring to a situation that you're in, you should consider sharing this with your manager. If you are worried that something bad will come from it, then it might be a sign that it's time to get away from that job.
Thanks -- but no, for me personally it couldn't be farrher from the case. Meant broadly / generically, bc IME there's so much of this -- and IMHO it's often perpetrated unknowingly. A convenient mechanism to shed light could end a lot of misery.
Make a throwaway email address, send it to your intended recipient.
I'd even go as far as label some of these behaviors as toxic, and not micromanagement. "Every task needs your approval" and "You need to be cc’d on every email" show that you, as a manager, are just a paper pusher who rubberstamps things to justify your massive paycheck.
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.
_Micromanagement, when used in the context of a business, is a situation in which managers (or anyone responsible for leading other people) are overly controlling of work or processes._
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).
To some people managing equals micromanaging. They don't want to be told what to do at all. But then can they do it alone? No. And this is the dilemma.
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.
I was a micromanager when my team refused to go in the direction the rest of the company was going. My hiring was actually a trap, in that my job was mainly to fix and/or fire an entire team of people. Nobody on my team liked me, nor did they like the direction the company was going, so a nontrivial part of my job was monitoring that my team doing anything at all in the right direction.
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.
I have heard Musk say that he is deeply involved in engineering. Makes me suspect he might be micromanaging. Or is what he does different?
According to Tesla employees, yes[1].
[1]
https://www.cnbc.com/2018/10/19/tesla-ceo-elon-musk-extreme-...
Well innovation or no mistakes. Which do you prefer?
I'm a fan of his work, but it wouldn't surprise me if he is. People will put up with a lot of shit from a boss if they perceive him as a "genius". The way some former Apple employees fawn with gratitude over Steve Jobs' abuse is puzzling to me.
I am sure he does. But he isn't a micromanager. He will do whatever it takes to get things done and done right. Same with Steve Jobs. If you can get it done and done right, you wouldn't hear a peep.
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.
Different situations call for different levels of intervention.
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.
What would be a situation where its appropriate?
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 - different perspectives (i.e. bigger vs. narrow picture), Second - skills and competencies gaps.
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...
I think some of what you describe, i would consider to be "mentoring" not "micromanaging". I at least view those differently, but i can see how they can look similar in a lot of ways.
I would like to see the other perspective, why it is good to micromanage.
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.
> 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.
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 + $$
"I’m a non tech founder And I outsource my teach overseas. I don’t trust my team."
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.
The problem I saw with startups that had technical problems were always related to founder having no insight to the technology that was used. I even saw very technical founders fail, who just happened to have skills in a different technology than their team.
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.
It sounds more like a cautionary tale against outsourcing your tech to me. If you had an internal team you could trust then you wouldn't need to micromanage and you could focus on running your business.
Micromanaging is not the only way to get from results you don't like to results you do. I don't claim to be the world's best manager or anything but the approach that I have been successful with is that I try to be very clear about the results I expect (and why) and then when the results I receive don't match what I expected I communicate about the delta in results (the _what_ as opposed to the _how_) and try again.
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.
> 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
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.
Outsourcing software development is very difficult to do successfully.
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.