Hacker News new | more | comments | ask | show | jobs | submit login
Demoralize Your Teams Quickly and Efficiently with Micromanagement (2010) (stellman-greene.com)
203 points by sidcool on Dec 19, 2015 | hide | past | web | favorite | 63 comments

This thread provides me with an opportunity to ask for advice.

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.

People becoming lazy is a sign having no purpose. That's where the management comes into play. The best thing that can be done is giving people purpose. The next best thing is punishment and bonusses. And if that doesn't work people can be made to monitor each other when punishing one gains a bonus for the other (that's how the train ticket inspectors are made to check your tickets and not do favours to you).

Go with purpose first and don't assume it's the wrong path if it doesn't work at first. It's a hard path. Some simple things to start with: Do you ask your employees to provide input? Do you try to understand their input and adapt the company and processes accordingly? Do you show them how well the company does when they do their job well and how much it costs all of you when they do a mistake? Think of games. Show people numbers to optimize and they will do that because that's what we like to do!

Please come back and tell us your results from trying, maybe also start writing a blog. That's how you can interact with other managers to learn from each other, and to some degree to not feel too alone. ;-)

Yes exactly. You want people to take ownership of their work. To put their personal and professional pride into the work. Simply, you do this by involving people in the decisions on how to do the work. Then they are doing what they decided to do. It's theirs. Open a discussion. Take input. Play Socrates. Steer the discussion when it goes of track, but make sure that people still feel in control. That they have control, and that they matter. People want meaning and purpose most of all. This may sound Machiavellian, but people can be lured and persuaded into doing something they otherwise wouldn't, but they have to feel they made the choice themselves.

Automate as much as possible to make it difficult to make a mistake. Check lists are a good start. Keep aggregate stats on overall quality and at regular team meetings set goals for improving the stats of the group overall in small increments. Give praise of each improvement and then make a new goal. Privately keep stats on individuals if there is someone who is an outlier in terms if mistakes talk with them privately about how they feel about the job in general and how it might be effecting their mistake performance if they don't improve you might have to find a replacement.

Realistically though there is always going to be some number of mistakes unless you have both automated double checking and a second human in the loop checking everything.

Maybe you should handle the "unusual" transactions?

I bet you don't pay them much - maybe not even enough to live on (that would definitely be the case here in the US I don't know about Australia). I've worked shitty retail jobs (hotels) before, for years, if you're trying to assess their "status" they'll just lie to you to get you to leave them alone. A checklist is just an extra hurdle when it's busy (and even when it's not).

I've never been a manager so I'm not sure what to tell you as far as motivation. I think money might help. I'm sure you have your pets and the other employees will resent those people and you for having them. Maybe letting them vote on shift leaders or something so it's not you correcting them but someone they may already like/trust.

When you have people living on nothing they will perpetually be in a survival mindset - which is to say, cut-throat and self focused. I doubt whatever you want them to do is of any real concern to them and I doubt you can make it that way without spending money and showing that you actually care about the person and not just the job.

I can say for certain though, you'd be hard pressed to get people to hate you more and faster than to try to micromanage them. Your employee turn over will increase which will just mean more people for you to try to train "the right way".

Australia has a high minimum wage.

From https://www.fairwork.gov.au/how-we-will-help/templates-and-g...

The (Australian) national minimum wage is currently $17.29 per hour or $656.90 per 38 hour week (before tax).

Casual employees covered by the national minimum wage also get at least a 25 per cent casual loading.

Lots of people in lots of jobs make mistakes when they're busy or distracted or doing something unusual.

Maybe you need more people to handle the surge? There are hard physical limits on how much attention a person can pay.

If it's an issue of double-checking, have you considered a "peer-review" system? In other words, they have a checklist and the tasks that need double checking must get checked off by another staff member and signed off on.

You'd want to limit it to only things where you notice mistakes.

But sure if it's practical, just an idea. But it would take yourself out of the equation and might make peer pressure work for you.

Penalize them financially for making mistakes or give a bonus for not making mistakes.

That's bad advice.

Just going to cause resentment IMO.

The concept of double checking your own work doesn't really fly in engineering work. Not that everyone shouldn't do it but it doesn't tend to add much value to the end product. It is human nature to overlook your own mistakes.

In HW development, separate people verify and validate everything. The cost of a mistake getting through is too high to just hope it is all good.

The point is that mistakes will always happen. You shouldn't blame staff for being human but the mistakes can't get out the door. If it's that important, a second set of eyes needs to be there IMO.

However since this is a post office, really the important thing for the customer is to get in and out as quick as they can. The major complaint is probably the waiting time. So in one sense the employees are helping customer satisfaction by getting them processed quickly!

This is probably illegal (garnishing for mistakes), so check with you local labour laws before doing this. Though I would recommend against this unless you want employees quitting or stealing from you.

Even if you just bonus and don't penalize, if you do it often and regular, it becomes an expectred portion of compensation, and the lack of the bonus becomes the penalty. It does require skipping or reducing the next round of raises in lieu of the bonus structure though, unless you are fine with just paying out more money to employees to reduce problems (which for some people and/or some situations is fine).

Yeah, it's a good point. Carrots might work better than sticks. You can always fire people for incompetence though.

Penalize them financially for making mistakes - that is illegal in Australia, see https://www.fairwork.gov.au/pay/deducting-pay-and-overpaymen...

Perfect recipe for getting everyone to play it safe, never learn and someday when the guru on the team leaves the stress level skyrockets and you suddenly find out many have been giving out their resume for months and suddenly finding work elsewhere. Also a recipe for a lack of transparency leading eventually to catastrophic failure.

You've been downvoted, but I think you're right. These workers have no sense of the damage they could be doing -- if a package gets lost, for example, because of their error. They need to be made to feel it personally somehow.

At the very least they should know that if something goes wrong because of their error and the business is held liable, they will be fired. If there's no way to know which worker committed the error, maybe that's the first thing that should be fixed.

Bonuses for error-free performance are also a good idea.

I'm all for treating workers well, but it goes both ways: the workers also need to treat the job well.

In an ideal world, yes.

This world is not ideal. You'll want a caveat: talk to the people who are having trouble, _and make it clear that you're not just here to yell at them_. Your goal isn't to punish, it's to teach. Punishment is useless if you don't tell the person what they did wrong, or if you don't let them fix their mistake.

The biggest problem with micromanagement is that you're making it about you rather than whatever your goal is. It's not so much that you're making your team miserable (though you may be), but that you're making their goal keeping you happy rather than achieving whatever objective you have. Those two things might be closely aligned, and then the result might be ok, but if they aren't, things are going to go bad. Effectively you're making your team be as good as you are rather than as good as they could be.

This happens a lot when the managers are not technical, because they have some sort of anxiety of not understanding what the team is doing. That anxiety feeds their power hunger over team, and that ultimately leads to paranoia. Micromanagement ensues.

I've encountered a perfectly capable developer as a manager. He was micromanaging us in very similar fashion mentioned in the article (urgent tasks, doing things "his way", short delivery times) and it was even worse, because he could find reasonable arguments, why something is urgent, or "his way" is a good one.

Do you really think his arguments were reasonable? Why did they fail to persuade you?

My best remedy for this is to assertively establish and enforce temporal boundaries.

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.

it is not clear to me the roles of "you" and "them" in your post, but if I pick "manager" and "worker" (or vice versa) I still don't really know what you are trying to say.

I think what you are saying is "tell the manager you are tracking their time". but not sure.

I think he means that employee is telling the manager that the employee is tracking his own time, thus, when the manager requests work to be done, the manager will take a resource-oriented approach to the employee's time and focus. It might make the manager more conscious about this often subtle detail (time is money) and they will likely feel more restricted when it comes to managing the employee, instead of being empowered. This is good for curbing micromanagement.

Yes. Although this article isn't about "micromanagement" in my mind. Micro-management, in software, effectively turns the programmer into a secretary taking dictation.

It's someone caring about the details of the results along with the details of the implementation, and the process, and every other factor but then hiring someone else to actually press the keys and move the mouse. It turns the task of programming from problem-solving to satisfying effectively onerous checklists of ceremonial acrobatics. There's other ways to solve that problem.

The original post is talking about debilitating flow and a structure (stemming from a culture and engagement) that is fundamentally destructive.

My most demoralizing event at a startup, and it culminating in me quitting - may years back, engineering manager had the right idea of out sourcing the "less important" things. I agreed at the time in the abstract, delivery ended up using many hours of my time.

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.

> I'm pretty sure said micromanager was getting kickbacks for outsourcing.

I'm really curious how companies let this kind of stuff happen. I guess I expect this kind of stuff from larger companies with so many staff no one is really in charge? A friend claimed at his company managers were picking outsourcing companies based on where they wanted to vacation next. They'd then book business class tickets, get a refund, then buy 2 economy tickets with the refund and take their lovers.

At least one company I worked at had a whistle blower policy to report this kind of stuff without retribution and, at least at the time, seemed to be very serious about it to weed out bad people like this.

Put someone in a position of sufficient power, give them reign over budget and a professed plan, it happens.

In this case, the inability to justify "they are doing logging code, I still spend 20% of my time which is supposed to equate to 4 people contributing and their product is shit and I still have to review it" was the only argument that held weight.

Unfortunately, for me, this particular attitude is very particular (multiple companies) to a certain region/country.

Employees who are micromanaged lose confidence in their decision making abilities. At every decision they question themselves making it hard and even stressful to make decisions.

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.

You are showing the signs of a very confident leader. Your employees are lucky for this. Kudos.

This happened to me exactly. I was at a YC company and thriving and then they hired a "director of engineering" that was simply an arrogant asshole. I tried my best to continue performing but the last straw was when I was given a very complex task, told to make any bug fixes and escalations my top priority, and then blamed for not completing my task because I spent all my time on escalations.

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

This is basically how the entire company I work for operates. The biggest problem is wishful thinking when scheduling brand new features, as in "you have a week to write a robust one-dimensional edge-detection and comparison algorithm, but the hardware the data is sampled from won't be ready for another four weeks."

We're currently in the Death March phase, because our wishful thinking has caused so much stuff to slip that our milestones are slipping.

I'm currently working on my resume.

In my experience, micromanagement is often a sign that you're managing by disaster. By that I mean you spend months, or sometimes years, not expecting your staff to make judgement calls for themselves, not communicating your intent, not building those relationships, and then there's always some project where something needs to be done. At which point, the only way that you can do that project, given that you haven't invested in those relationships, haven't built those skills, is to tell everyone pretty much precisely what to do.

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.

The worst I've ever seen was a manager who held a morning meeting, one at the end-of-day[1], and then went to each developer and spent 20 minutes in their cube during the day. He didn't get that we actually needed to work on the code, and he never seemed to have time to get our questions answered or get the resources we needed.

Luckily he only lasted 2 months.

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

I have seen a lot of projects failing because of the opposite of micromanagement: no-management. Giving a team some vague project and trusting that everyone will take the responsibility to figure out what and how to do it.

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.

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

That's just the "grass is greener on the other side". I've seen both at work - I would take no management over micro management any day - particularly because micromanagement is a result of bad management - so you get a bad manager micromanaging you.

There is good micromanagement where the person managing understands the problem, has reasonable expectation of what can be accomplished, and pushes the team to perform to their max. There is bad micromanagement, often by non-technical people lacking a clear direction and who want a zillion status updates on what you have done (which are then ignored).

A good micromanager can push an amazing level of performance out of a team for a short time, but at a high cost - it is a bit like giving the team amphetamines - the performance is great for a short time, but the downer later is a killer.

"A good micromanager" == "an honest liar". There is no such a thing, micromanagement refers to bad, counterproductive behaviour, not a management style that can be used for good.

The definition of micromanagement is not bad, counterproductive behaviour - it management with excessive attention to details [1]. More generally it is used as a description of your boss watching what you do very carefully and/or telling you what to do.

1. https://en.m.wikipedia.org/wiki/Micromanagement

What I meant is that "excessive attention to detail" is bad by definition.

Yes, but what is considered excessive is situationally and person dependent.

The point I was trying to make was that close attention to detail can be a powerful tool to solve a short term issues, but it comes at a high cost in the long term. I am not arguiging for micromanagement as the default management style you should use, but it should be a tool every manager can draw on in the right situation.

I don't think there is anything vague about this. It's obvious management is responsible for setting attainable goals and priorization, and making sure 'things work'. The latter part is the hardest, I suppose. That can turn into micromanagement. Not focusing on the prior items is negligence, so yeah, in principle I agree with you that no-mamagement is worse ethically. Although there can be situations where the team actually does know the best and the managerial role focuses on non-project related issues

Arguably micromanagement can be beneficial provided it's used effectively. What the article outlines are mostly examples of flagrantly poor micromanagement.

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.

Having been down the micromanagement path it is extremely difficult to avoid on projects that will kill the company if they go wrong. When you are running a business that involves taking one critical gamble after another you really don’t want to take the risk of anything going wrong.

On the other hand I have managed in situations where this pressure didn’t exist and it was much more pleasant for me. I could just explain what was need, let the person come up with the best plan of attack, and if the project failed have a quiet chat afterwards on how thing might be handled better next time.

It's true - there is a time and a place... and a cost. Plan A is to avoid the need to micromanage. Plan B may be micro-managing, but in my book that's trading good will for short term results. This works when you maintain a high level of good will with your team, and doesn't when you're always optimizing for short term results.

Good micromanagement isn't micromanagement, it's just management. At the point micromanagement is beneficial, that means either the manager should be doing that job or the employee should not be doing that job. Both of those are managerial failures.

After talking with several managers who tend to micromanage I've noticed that they like to play strategy games on their free time where it's also possible to micromanage. Good example is Civilization where they always like to manage every single detail of their cities whereas I just want to leave that to the computer AI.

Yeah, I've noticed the same about managers that play League of Legends.

God forbid having a manager that plays Crusader Kings II or Europa Universalis IV!

https://news.ycombinator.com/item?id=8166701 argues that there's a time and place for controlling an employee, but that it's generally not a great idea

Thanks for linking that!

Micromanagement is exhausting.. Once you learn to let go just enough to be able to supervise and step in only when you need to, work becomes more fun.

> Remember: reading your mind is part of every team member’s job. That’s how they stay proactive!

> 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 currently have the role of the lead reviewer you describe and I often worry I'm focusing too much on minor details. Fortunately my coworkers are comfortable pushing back. I think if you're able to have an objective discussion and agree on your goals, and whether a suggested change meets them better than the existing code, you'll be able to get work done together without one of you feeling like you're being a problem. The reviewer also has to be prepared to let go of a suggestion if the change won't have an actual impact.

It's a tough issue. Having every line of code be exactly 100% consistent isn't a bad thing, in fact, it's a good thing. But, I question if it's worth the time, effort and frustration to do this. I feel it could be better spent on more pragmatic things, like code correctness.

And then of course, there's the minor changes that don't actually bring any improvement at all. It's tough though, because I feel that pushing back against these things, at least in the short term, just eats more time, is more of an effort, and causes tension.

> In fact, try to constantly find many small changes that your team should make, just to keep them on their toes.

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.

This describes stupid management rather than micromanagement. Not giving people enough time, interrupting them with urgent but unimportant work, failing to set clearly defined goals or to give clear feedback. All this has nothing to do with micromanagement per se.

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.

I agree the article is more about stupid management but micromanagement is another aspect of stupid management.

If there are over-detailed micro-goals and accompanying micro-status updates on everything, it devalues the employee. The goals have to have significance to the end product.

When managers sweat over details that have no meaning they lose their authority. It leads to bad morale.

The emphasis on lack of follow-up on thing-of-the-hour inclines me to say that the real problem being highlighted is not so much micromanagement as drive-by/ADHD chipmunk management...

micromanagement means managing microdetails. And microdetails you get, with all the possible paths from a root in that heap dump. As much time and attention you possess - you got it... It is either my friend who is going to listen to it on a coffee break (and we'd prefer instead to talk about Syria and new Russian stealth missiles which are extremely necessary weapon against sand people with AKs) or the micromanager. Somebody is gotta listen to my take on that heap dump :)

Any advices on how to react when you realize your manager is micro managing your team (and that it doesn't work great)?

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact