Signs you might be a micromanager | Hacker News Reader

Signs you might be a micromanager

unito.io

186 pointsjamyot66 comments

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?

Imagine every variable, class, file, and method name being gibberish with no comments. Also, no white space devs usually use to group related functionality in a method. You have to not only figure out what the heck is going on, but also why. It’s very difficult to figure out at first.

A normal code base has some (not always descriptive) names. But it’s at least useful for context.

Oh yeah, that's some pretty clear obfuscation. It sounds like a PITA to work with code like that.

I feel like controlling naming is a great example of micromanagement. I mean, if in addition to manager you act as a code reviewer then as a code reviewer you might suggest a name. Or if you are an architect in addition to a manager and you came up with a name for a thing that was your idea, then cool. But if Jim or Jane came up with a thing and named it, global or not, then ideally they have an established process to have that reviewed (like as part of normal code review) and ideally the manager stays out of it unless they are part of that process as a reviewer (not as manager). The reviewer-not-as-manager part is crucial since it establishes trust: you’re saying to your folks they can have that authority at an equal level to you if only they are a code reviewer. Flexing the manager muscle isn’t the right thing there IMO.

Yeah managers shouldn't be carte blanche naming things. Basically there should be discussions about names during the architecture phase of any project, and any name that gets flagged during code review should get brought up in some meeting that happens every couple weeks. What shouldn't be happening is passive aggressive comments constantly getting traded back and forth between developers and code reviewers.

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.

There is also the common case of a cash strapped department that hires only juniors.The secret sauce in that case is hidden micromanagement, supported by CI and splitting work and commits to mini modiles.

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.

This startup exists many times. All those team time tracking and work optimising apps.

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.

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!

Of course he got promoted! They clearly determined he'd be better off with fewer direct reports and moved him up another rung.

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

I agree that 'no management' is really damaging but I don't think that's that the opposite of micromanagement is.

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.

Interesting, I thrive with as little management interaction as possible. Ha. monthly 1:1 is more than enough.

As a counterpoint, I think I did some of the best work to my career when I only talked to my manager every 3 to 6 months. I talked to other people on my team, I talked to our customers, and I figured out for myself what was important, and just did it.

I ended up shipping something that literally became the deal-maker for prospective customers who were considering us and a competitor.

> 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.

Indeed. Some teams I took over complained to me I was micro managing them, because I was reviewing code and asking on a regular basis them when things would be done. The regular basis was once, max 2 a week, and I was not reviewing more than 1 PR / dev per month. They were used to no accountability, and ofc compared to that, everything feels like micro management.

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.

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.

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.

If the problem is that the members aren't aligned with the common goal, micromanagement would be a sure-fire way to get them to quit.

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.

Wow, asking a new manager to do this is terrible. You certainly did the right thing to get out as soon as you could.

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.

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.

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.

Those mechanisms exist. The worker could talk to their boss about it. Failing that, they should go to their boss's boss or to HR.

Sure -- but I specified "anonymously" bc so many of those suffering from micromangement, almost by definition, don't have a great working relationship w their superiors.

So you think that anonymous feedback instead of direct feedback would improve that working relationship?

Directly? Maybe not. But I do think the OP's post was targeting a sizeable share of the micromanagers out there who are simply unaware of the harm they're doing, and who might change their behavior if their attention were drawn to it. Which in turn could radically improve said working relationship.

If the managers aren't aware, then there should be no problem with being direct about it. It's hard to build relationships indirectly.

We're going in circles or talking past each other or something. Not to belabor it, but my point was simply that the ability to share the feedback anonymously would, IMHO, lead to said feedback being provided in many more cases than it'd otherwise be. Do you really disagree with that? What specifically are you arguing? Saying "there should be no problem with being direct" is tangential, and offers no plausible path to solving the problem. Sure, there "should" be no problem -- in some ideal fantasy. But here in the real world, there is a great deal of suffering under micromanagment.

Make a throwaway email address, send it to your intended recipient.

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.

> 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.

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.

I am usually not directly accusing people here on HN. But this post of yours makes you the exact manager not a single employee in world would prefer. And therefor noone will be ever motivated for his or her job. Your style leads to a guaranteed failure of any startup.

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.

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.

another thing about outsourcing is, if its not in the spec, it literally wont get done

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!

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.

Why is this being downvoted? Even in the cnbc article above, there is little "micromanaging" going on as far as I can tell. He has new ideas, rejects proven methods sometimes, and wants everything a certain way. But compare that with the list in the original article "signs you might be a micromanager" there is little in common.

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-...

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.

The book Drive is phenomenal. Goes deep into what brings intrinsic motivation in people and why micromanagement is awful.

One of the biggest signs is that you are very against remote working.

Reply on news.ycombinator.com