
Demoralize Your Teams Quickly and Efficiently with Micromanagement (2010) - sidcool
http://www.stellman-greene.com/2010/11/29/demoralize-your-teams-quickly-and-efficiently-with-micromanagement/
======
DecoPerson
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.

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

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

~~~
kbenson
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).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

~~~
ricardobeat
"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.

~~~
danieltillett
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](https://en.m.wikipedia.org/wiki/Micromanagement)

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

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

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

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

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

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

------
e28eta
[https://news.ycombinator.com/item?id=8166701](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

~~~
sidcool
Thanks for linking that!

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

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

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

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

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

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

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

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

------
trhway
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 :)

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

