4 ms·

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 skil

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.

nicoburns 6y ago
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.
- bawolff 6y ago
  I'm not really sure i would call that micromanaging
Alex3917 6y ago
> 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.
- lkschubert8 6y ago
  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.
  - withinboredom 6y ago
    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.
    - telchar 6y ago
      I'm curious, how would they obfuscate code and how could you tell?
      - withinboredom 6y ago
        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.
        telchar 6y ago
        Oh yeah, that's some pretty clear obfuscation. It sounds like a PITA to work with code like that.
tamrix 6y ago
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.
antman 6y ago
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.

nicoburns 6y ago

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.

bawolff 6y ago
I'm not really sure i would call that micromanaging

Alex3917 6y ago

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

lkschubert8 6y ago
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.
- withinboredom 6y ago
  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.
  - telchar 6y ago
    I'm curious, how would they obfuscate code and how could you tell?
    - withinboredom 6y ago
      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.
      - telchar 6y ago
        Oh yeah, that's some pretty clear obfuscation. It sounds like a PITA to work with code like that.

tamrix 6y ago

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.

antman 6y ago

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.