this post was submitted on 13 Jan 2024
702 points (98.0% liked)

Comic Strips

12026 readers
1875 users here now

Comic Strips is a community for those who love comic stories.

The rules are simple:

Web of links

founded 1 year ago
MODERATORS
top 17 comments
sorted by: hot top controversial new old
[–] [email protected] 43 points 8 months ago (3 children)

To be fair, even if I was letting an employee make their own decisions, I’d still want to know what they are doing even if I don’t plan on interfering

[–] [email protected] 30 points 8 months ago* (last edited 8 months ago) (4 children)

So, as a manager (by technicality, I'm more of an engineering lead in truth) I see both sides of this. It IS better when everyone can just... Go constructively contribute. I love it. I get to focus on my own work. It is absolutely the way to go. Unfortunately sometimes hiring doesn't go perfectly. And there are certain people where you have to micromanage them, because otherwise they're just go to git commit absolute fucking shit, and it's better to cut that off earlier via micromanagement, then allow it to pollute the repo.

So if your boss is pulling this, I see three options:

  1. They're just a micromanager, which sucks.
  2. They think you're a fuckup, and they are actually the fuckup.
  3. They think you are the fuckup, and you are actually the fuckup.

Easy way to tell- is literally everyone on the team getting treated like this? It's #1.

Are several people that you think are morons treated like this? Are there several people who don't get treated like this, even the people who don't stand out as 'rockstar coders'? You're the fuckup.

Is everyone except the manager's special rockstar- even the highly qualified, solid workers- being treated like this? Then the manager is the fuckup.

[–] [email protected] 7 points 8 months ago

I was going to say something like this but probably less well written.

I've definitely had coworkers that I simply do not trust to commit code without review. And there's one guy who's a cool dude and all, but all of his ideas seem to be "let's throw everything out and do it with a different library/language/paradigm". And I'm just like no please no.

I'm not a manager thankfully.

[–] [email protected] 6 points 8 months ago

I've fretted for a long time about whether I was the fuck up for "micro-"managing someone on my team but this post makes me realize it really was just them. Marketing not engineering.

They would get really nasty when I would feedback with "you can't just make your task names "write marketing email" 5 times, you have to specify what the email is about, and for what project, otherwise I can't check if the email will go out on time.

And also they would go totally off piste - a blog on disaster recovery rigs for data centers came back totally about rebuilding cities after earthquakes, nothing about attacks or power failure or database backups.

I've worried myself for a long time that I was micromanaging and I'm a bad person for it, but it really honestly was them.

[–] [email protected] 3 points 8 months ago (1 children)

And there are certain people where you have to micromanage them, because otherwise they're just go to git commit absolute fucking shit, and it's better to cut that off earlier via micromanagement, then allow it to pollute the repo.

Way to make sure they'll never improve. We have merge requests and four eye policy for this, no need for micromanagement. There's never a need for micromanagement, and if you feel like there is, your processes suck, which is your responsibility as a tech lead.

[–] [email protected] 3 points 8 months ago (2 children)

That's really not enough.

Review stops people from polluting your repo with bad code and lets you give feedback.

It doesn't stop people from wasting time writing unfixably bad code that just needs to be thrown out.

Now of course what you can do is give people very small coding tasks and regularly review them before getting it into a shape where it can go in the main repo. But this is just micromanagement via git.

[–] [email protected] 3 points 8 months ago* (last edited 8 months ago)

Yeah, I'm glad for redprog that they haven't ran into this sort of thing, but sometimes you end up with people where you sort of have to sit on them a bit to get usable code that you even CAN code review out of them.

I even had one contractor who would, from the very start, refuse to do any work without a step-by-step list of implementation details as his 'project requirements.' First time I've ever had someone DEMAND me to micromanage them. I fucking hated it, I was spending nearly an hour and a half for each hour of billable work I was getting out of the guy. I can only assume some client in the past was wishy-washy about requirements with him, and I totally feel for him on that, but I personally feel he was taking it a bit far lol.

Only upside of that clusterfuck is that it gave me the political position to ensure that no more contractors were hired to work with my team without someone on my team being involved. The quality of our contractors went up rather significantly at that point.

[–] [email protected] 1 points 8 months ago

If that person made it through the probation period under your supervision, that's still your fault. And if that person was there from the beginning, a senior in your team could still support them by teaching them good practices, showing them better options, etc. Or, as a last resort you could always assign them tasks that are more within their capabilities.

Micromanagement will never lead to people improving - quite the opposite in fact, they'll start to care less because there's always someone who prevents them doing mistakes.

[–] [email protected] 2 points 8 months ago

And then there's the places where the CEO git commits absolute fucking shit

[–] [email protected] 5 points 8 months ago

Yep, I'm an engineer, just one on the team. We are all doing different stuff. So I give him high level updates based on our OKRs, that way he can properly communicate my progress were it needs to.

[–] [email protected] 3 points 8 months ago

There is being in control and being in command. Being in command means you ultimately decide stuff being in control is when you allow no agency. What I typically do is give the people under me their own turf and gradually extended it as they show success.

[–] [email protected] 41 points 8 months ago

You aren't supposed to actually listen to what they say, just make them feel good about being bossy, ~~even~~ especially when they fail to earn respect.

[–] [email protected] 18 points 8 months ago (1 children)

We have the data. This type of command-and-control systems where one person is allowed to be smart and everyone else has their ideas shot down and dignity removed results in the worst products, the lowest quality control, the slowest ability to change to new conditions, and makes the least amount of money. This structure only exists because it is the simplest to setup.

And everyone is mystified why cost disease is running rampant. Why government projects are behind schedule, over budget, and don't work very well. My employer for example has systems that accomplish the same goals for private vs public sector. The public sector ones are crap and every time I attempt to update them slightly I am told not to by the middlemen between the government and us. Meanwhile our private sector machines continue to advance.

Big fuck you to the taxpayer

[–] [email protected] 2 points 8 months ago

You‘re the first person in a long time to put it this accurate.

Had a boss like this recently. Looked like he invented micromanaging and got frustrated every day about the lack of progress the company made.

Big surprise there /s

[–] [email protected] 12 points 8 months ago

You should do everything you can to get people like this fired.

[–] [email protected] 10 points 8 months ago

I still can't believe social media isn't absolutely reviled.

[–] [email protected] 1 points 8 months ago

Well the problem is always by the decisions....