Usually this sort of thing occurs when management perceive fixing technical debt as a distraction instead of an investment.

That's the cynical take - not that it doesn't happen, but there's a lot of reasons why a manager might have better context for what is important to work on at any given moment that are genuinely useful. For example: business priorities (not just "tech debt" vs "tick feature boxes", but "which of these 8 aspects of this feature should we build first", etc.), more experience in what aspects of a problem are worth spending time on, being more connected to what others are doing around the business in different departments, having more time talking to customers to know what their real pain points are, etc. etc.

In fact, as a manager in my current team I probably spend more time nudging people to fix technical debt they've forgotten about because they're excited to work on the next feature than vice versa. In other teams I've spent more time cautioning away from writing functionality that isn't needed right now to avoid overengineering the solution.

How you communicate that guidance and extra context has to depend on the team, what works for one won't necessarily work for another. What you found to be terrible another developer might love - as a developer who now has some management responsibilities I had to learn that some people actually want a lot more management than I would have ever wanted - my "micromanagement" is their "I am supported and know what's going on".

Anyway I'm not saying there aren't bad managers out there (or that I'm a good one), but it's a lot more nuanced than you imply, and what you might hate in a manager others might actively seek out.

It’s bad management to drop by people’s desk every day to check in with them, then “nudge” them. I’d say that’s a failure of product vision, strategy, communication and leadership.

> my "micromanagement" is their "I am supported and know what's going on".

What you’re really seeing here is people grasping at any life preserver they can grab in an incredibly poorly run organization. In a well run organization management is extremely hands off, because the machine runs smoothly and scales.

If you've worked on both sides of engineering and management, you'll discover it's a lot more nuanced than that. Many engineers don't need managing. Many more do. Many need micromanaging.

I’ve worked both and micromanaging is never good. For one, it doesn’t scale. It’s also indicative of poor process, communication and documentation.

> It’s also indicative of poor process, communication and documentation.

I recall one engineer in a team of 20 or so that, whenever he ran into a problem, he'd stop, fold his hands, and sit back in his chair. And wait until the manager noticed this, would come by, ask what the problem was, fix it for him, and he'd then proceed.

You could say this was all the manager's fault, but the rest of the team did not behave this way.

Another time, I recall one who needed micromanaging. Eventually it turned out he was on drugs.

> whenever he ran into a problem, he'd stop, fold his hands, and sit back in his chair. And wait until the manager noticed this, would come by, ask what the problem was, fix it for him, and he'd then proceed.

Certainly there are better ways to communicate than looking to see if someone is sitting back in their chair. Either they are delivering or they are not. If not, a good manager will ask what the problem is, then fix it. Not delivering should be a temporary state, if it’s not, that employee may not be a good fit for the org.

I mean I would totally agree with this but sometimes you end up in a situation with someone like the described engineer; obviously you should get rid of them - but getting rid of people quickly and efficiently is not possible in every organization and country therefore managers sometimes need to manage someone that should be gotten rid of because it is not the propitious time to get rid of them.

Yeah, because it's NEVER the programmer's fault, they're always perfect :-)

Of course not, but micromanagement is never the answer. I will say there are a lot more decent programmers out there than there are managers. Many programmers are motivated by curiosity, 90% of managers are motivated by ego. Wfh is going to decimate the latter as egoless orgs become the norm.

perhaps the devs on his team were the kind apt to go down interesting rabbit holes.

Because they were always drifting off onto something more fun.