Hacker News Reader

Comment by nharada | Hacker News Reader

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.

View on HN

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

Reply on news.ycombinator.com