When I was dealing with a micromanager I just stopped letting him know what I was actually doing - because bothering to communicate with him only ever made my job harder than it needed to be.
As an example, we had two very large ant build.xml files in our deployment tooling (~8000 lines each) - with inlined groovy scripts (why have compile time errors when they can be runtime errors instead?).
One was for deployments to JBoss 6 and 7, the other for EAP 6.4.
There were ~10 lines of difference between them. Being sane, I unified them - and came in the next day to the angry demand that I restore the second copy.
Luckily, he's a fuckwit, and failed to notice that when I restored the second copy I didn't actually revert the reference change; the second copy sat unused in the codebase until he left the company.
>> When I was dealing with a micromanager I just stopped letting him know what I was actually doing - because bothering to communicate with him only ever made my job harder than it needed to be.
Man, this. I was dealing with the same shit and just did what you did.
I stopped to show what I was doing in a low level, because he is a super technical guy and would try to find issues in things that don't matter and/or were not high priority.
And then I started to show and discuss only what matters. My mental health had a 100% improvement.
Another way is to bombard micromanagers with questions all the time and note each decision they give (in an excel sheet) and ask more questions about each decision and hold them responsible for every little thing they answer. When a decision is reverted re-ask all the questions again. Soon they’ll be avoiding you:)
As someone that manages I will usually push it back on the asker with rhetorical questions ie: we’ll how do you want to tackle it. I’ll waste just as much of their time as they want. And when if the project slips it’s on them or if I have to engage to keep it on track it may or may not be reflected in their eval.
I engage just as much as I need to and nothing more. My more senior guys I try and get them to focus on deliverables and seeing the forest for the trees. For some that’s natural and others less so.
I prefer not to micromanage and be hands off. But at the end of the day I’m deliverable oriented and if it’s not getting done I will engage with the team members to get there or get them on track.
Most of my better guys know this and do enough and come prepared enough that they have basically full autonomy.
Others will end up in follow up meetings with me until what needs doing is done. In the few times they have communicated frustration I’ll usually, again, tell them if they want me to disengage then they need to come to the table with problems identified and solutions and know which ones really need my input and which don’t.
My job is to teach them ways to work and manage their workloads and projects (as well as the skillsets of the trade). They are wasting their own time and mine by taking that tactic.
So yes, if they are clearly trying to shirk ownership of their projects and tasks and pass the buck that is on them.
Project deliverables are just one component of my job. Fostering skillsets and career progression are others.
If someone wants to try and be clever by purposefully being obtuse and shirking responsibility, that is 100% on them. I grant them the freedom of manuervability and decision making to not do that. They are in charge of their own destiny in that way.
And to be clear I have only had maybe 1-2 people that really brought that to their finish line. Most times as soon as we have some type of talk and communication opens of what I’m trying to do and why, it works out.
I get that this place is very anti-management. But the reality is in most orgs you do need some level of hierarchy and leadership.
> Luckily, he's a fuckwit, and failed to notice that when I restored the second copy I didn't actually revert the reference change; the second copy sat unused in the codebase until he left the company.
When I was dealing with a micromanager I just stopped letting him know what I was actually doing - because bothering to communicate with him only ever made my job harder than it needed to be.
As an example, we had two very large ant build.xml files in our deployment tooling (~8000 lines each) - with inlined groovy scripts (why have compile time errors when they can be runtime errors instead?).
One was for deployments to JBoss 6 and 7, the other for EAP 6.4.
There were ~10 lines of difference between them. Being sane, I unified them - and came in the next day to the angry demand that I restore the second copy.
Luckily, he's a fuckwit, and failed to notice that when I restored the second copy I didn't actually revert the reference change; the second copy sat unused in the codebase until he left the company.