Demoralize Your Teams Quickly and Efficiently with Micromanagement (2010)

I am a manager of a family-owned post office. It's a rather intense job, and I ensure that I'm aware of the "status" of each of the 6 employees. If they're feeling unwell or worn out, I'll tell them to do the simpler jobs. It's much like a typical retail job with handling of stock and money.. but there's a very important difference: we have strict procedures to follow for mail, money and identity services. I've told the staff that the procedures set out by Australia Post are paramount and that their "habits" when dealing with customers must ensure everything is verified and triple-checked.

Unfortunately, some of the staff have developed lazy habits. They easily notice any issues when it's quiet, they're feeling good and performing a typical transaction. However if it's busy, they're distracted or handling an unusual transaction, they are prone to making mistakes.

How do I help them develop better habits? If they are willing to change but having trouble, what do I do? If they are unwilling to change, what do I do?

I really don't want to micromanage, but they're simply making too many mistakes and we may be liable for them. I've told them at times to go slower yet their comfort with their habits makes them go quickly even if I tell them to take their time and double check. If I make a checklist for them to go through in the longer transactions, they just check every box without truly thinking about it.

Any advice would be appreciated.

Track the time and say its "just for your own diligence".

An attitude of acknowledging there is always a clock running and you engage with how you allocate it has, in my experience cuts through this kind of poor teamwork quickly.

You never say they aren't important or you don't have time, you just make it explicit how much time and how often that liberty, which they are always free to take, is being invoked. In a way you value them more by committing your undivided attention.

This response is analogous to when people look at the health information on a snack and think " maybe i ought not eat the whole box in a sitting ". They are still free to do so, but the information makes the responsible and foolish choice more apparent.

At its core is teaching a new level of conscientious relationship with professional engagement. You're helping them grow as a human while maintaining dignity and encouraging a more intentionally sincere and personal relationship.

I made it known to management that "outsourcing wasn't working", when said micromanager proposed we give more to the outsourcing firm, I said "fuck no" with a myriad of reasons why. Said micromanager was pushing me on my tasks and ignored the work I had to do to clean up his messes.

In the end, I left but outsourcing core components didn't happen. I'm pretty sure said micromanager was getting kickbacks for outsourcing.

Karma caught up and said micromanager didn't advance as expected mainly on other key engineers being done.

Startup exited ok, but they had shed said individual.

The way I correct employees work, this would be in a professional kitchen, is by cooking a dish they way I think it should be done and have the employee cook the dish how he thinks it should be done. Then I ask the employee which dish he thinks is best, or which technique has the best result either in quality or is quicker. They decide. It's their decision how to run their work station. Most of the time they choose my way. However, sometimes they don't. I have to respect that for two reason. First, I'm not always correct even if I think I am. Second, they have to be the one's making the decisions and they have to believe in themselves.

I was gone within 2 months after that with half the other team.

It's a bad situation, and I think it's fairly transparent to most people who've worked for any significant length of time that it's not a good way to manage, but once someone is in that sort of situation there never seems to be a good time to move to a better model of management without having to let some commitments lapse. That's a very hard sell to make to the rest of the organisation: Yes we're going to make mistakes, and yes we're going to miss some deadlines, (or need some forgiveness on deadline,) because we need to actually develop our staff.

The situation is, of course, exacerbated by the fact that even where that time is available; you're working on a less intensive project; a lot of people want to think that what they're doing at the moment works. They want to think well of themselves. And there's a certain penalty that people, especially people with large egos, are going to pay in admitting that what they've been doing up until this point has certain flaws in it.

Luckily he only lasted 2 months.

1) he even scheduled a 7:30AM and 5:30PM meeting one day

It ends usually with most of the team just having fun time and couple that really works hard but in the wrong direction.

And I am pretty sure that most developers rather prefer micromanagement than no-management if you would do a survey.

Ideally it should be somewhere in the middle whereby the developers have enough freedom to make decisions and management to steer the outcome.

With hard-to-elucidate projects, it's probably not possible to have everyone precisely on the same page, especially in a large organization.

I'd say good micromanagement is best employed as a last line of defense against work that, for whatever reason is not living up to the vision or ideals of the project.

Good micromanagement is also not judgemental, and doesn't involve the micromanager being an asshole to people.

> Did someone on your team do something differently than how you would do it? Reprimand them! They might tell you that it works just fine, and that their way is just as good. But it’s not your way, so it’s not right.

An important question to me: what is a reasonable level of code-style guidelines for a manager / lead code-reviewer to enforce? I was in a position where all my code had to be reviewed and approved by this guy before it would be merged. It felt like I had to read his mind in order to get it correct and get it merged. I would spend as much time tweaking things stylistically to appease him as writing actual code.

So how do you determine what's an appropriate level of strictness and what isn't? Obviously a consistent code-style in a codebase helps make it more readable, yet obviously it's also possible to be too pedantic. I have trouble knowing where the line is. In my case, I don't know if the guy reviewing my code was the problem, or if I was the problem for being annoyed by it.

I worked for someone early in my career who followed every item on that list, especially this one. It made me pause -- I thought it was just him.

But thanks to the experience I've completely lost my taste for this kind of management; give me the specs and the authority to make small executive decisions and I'll get it done (that's what you're supposed to be paying me for). It is definitely demoralizing, and is a great way to lose your employees.

In addition, I'm unable to believe that constant attention is bad... unless the boss is a jerk and his attention is of an incorrect kind.

As a former employee, I loved real micromanagement, with a liberal but attentive boss who would never forget to ask for my input and would always set clear and realistic goals.