[deepGem]

I think micro management is often misunderstood. The usual run off the mill micromanagement, that almost every terrible manager follows is what I call micro verification. Double guessing every step you take and adding a verification layer on top of it. In the long run, it erodes the confidence and risk taking abilities of employees and overall completely detrimental to a company.

Real micromanagement is the ability to dive in and solve unsolvable bugs or issues, rally the team until the minutest detail of an issue has been hashed out or remove any micro obstacle. Once a manager shows skin in the game and proves themselves, they often win the minds and hearts of all engineers, who then feel inspired to get into micro details themselves.

Now like a sleight of hand, you have scaled accountability and integrity in your team.

So micromanagement done in the right situation and in the spirit of moving things forward is highly beneficial. In most cases, however micromanagement devolves into this micro verification tool that every mediocre manager uses to justify their existence.

[DandyDev]

Why is verification bad? I think it’s actually the thing that prevents the worst forms of micro management. Micro management to me means telling people what to do in detail. That removes autonomy.

The way to build trust and create autonomy while also keeping surprises to a minimum, is to tell your team what you expect of them and why. And crucially, you ask your team about their plan on how to get there. This still lets them decide on the “how”, while you can step in if you feel the plan is wrong. That is verification and it helps.

[eastbound]

Managers systematically micromanage when employees are showing incompetence. Because yes, every spelling mistake must be corrected before sending to the customer (“You are reviewing ALL my emails!”). The employee can’t be trusted for a task he’s not competent at (and it’s neither’s fault, maybe lack of courage to fire, or too much compassion for the employee - better that than unemployment).

I don’t see micromanagement as a red flag. I can’t imagine a manager who wouldn’t enjoy independent autonomous reports who only require broad directions and resources to perform their work.

[deepGem]

What you are saying here is, for the lack of a better word, macro verification and that's completely valid.

[DandyDev]

Yep that is a good way of putting it

[johnnyanmac]

sounds more like "micro-leading" than micromanagement. Every company varies, but management's time tables tend to be 80-100% meetings while a lead is more 40-60% depending on the week. A manager may not even be technical enough to understand the problems being solved by who they manage in smaller orgs.

[deepGem]

I really don't get managers whose timetables have 100% meetings. Weekly 1:1s is at the max 10-20 hours assuming a 10:1 engineer to manager ratio.

If a manager is not technical enough to delve into an issue within their team, should they even be leading that team ? They may choose not to do so, but if a problem is not getting solved and they can't act in such a time of need, their existence is totally questionable.

[ebiester]

A manager with 100% meetings is often one of a few cases:

1. They use useless meetings as shields for their time. That is, I can put myself on a meeting that I never attend so that I am less likely to be booked for that time. I will often have time blocks on my calendar because I work in functional workplaces for me, but this can be useful in toxic environments.

2. They have additional project/product management responsibilities. This is common for platform teams that they don't have PM support and have to wrangle people themselves.

3. They're really working 50+ hours a week and do their real work afterwards or before. This is common in places that oversubscribe managers. (I've hat 15 and even 25 reports before. I've even seen 50.)

4. They don't know how to say no and guard their time. This is common with younger managers.

[johnnyanmac]

>If a manager is not technical enough to delve into an issue within their team, should they even be leading that team ?

From my experience, this type of manager is more like that of a producer, merely called manager. Their job leans more on the lead to understand the technical planning, while they themselves coordinate between leads. In addition, they are also the direct contact for (often non-technical) stakeholders, so their strengths may lay more on securing deals/clients as opposed to developing/maintaining the product.

Lots of hats being worn in such a role between "kinda tech", PR, sales, and producing, so these happen semi-often in smaller companies, and almost never in a sufficiently large company.

[deepGem]

Oh yeah, you are describing a leader here. They are hustling for the next best project to take on for their team and/or for the company. They have moved beyond solving today's problems and spend most of their time on tomorrow's or the next year's problems.

[koreth1]

Wouldn't maintaining that standard make it effectively impossible to ever find any manager able to lead a team whose members have deep specialized expertise, especially if the team has expertise in more than one area?

[williamcotton]

I'm sorry, but 100% meetings is incredibly unproductive. There is plenty of work to do as a manager in a business. Most involves a spreadsheet for doing time-tracking, resource management, cost analysis, ie, managerial accounting. A healthy administration is aware of how the money flows through a business and this depends on having eyes and ears on the ground.

You'll see this approach to running a business everywhere other than the tech industry.