Better to micromanage than be disengaged
lethain.com
lethain.com
Very task-oriented + very hands-on = micromanager.
Very hands-off = a disengaged manager.
In my experience, the best managers can find a beneficial spot on those axes for each employee.
Give the technically competent people lacking confidence reassurance (be hands-on and people-oriented), micromanage a bit with people who aren’t doing their work effectively and not as a result of something that can be fixed with empathy or encouragement, and be disengaged when you’re working with competent self-motivated misanthropes.
IMO, saying one extreme is better than another tells you a bit about the author, nothing helpful about management in general.
Regarding the complaint of not moving decisions forward with a disengaged manager, if you plan to be absentee you must delegate, i.e. be laissez-faire. If you’re forcing people to get your approval and you’re not around to give it, you’ve combined the most incompatible bits of micromanager and the disengaged manager.
I did the exercise for myself, and here's what I got:
hands-on + task-oriented = micromanager
hands-on + people-oriented = professional office politician (deeply involved, but only to the extent it enables shaping the org chart)
hands-off + task-oriented = scrum master (no technical background that would allow being hands-on, but still very concerned with tasks)
hands-off + people-oriented = HR rep, I guess? Relatively distant from the day-to-day of the team, but still concerned with "people."
On reflection, maybe that last one is a bit of a stretch. But — definitely an interesting thought experiment overall.
A team of high-performing engineers needs something different from a manager than a team of low-performing juniors. A team building a new product in a fast-growing startup will have different needs to a maintenance team in a bluechip.
Nonetheless, I do like your thought experiment. It provides a model to think about what might be necessary.
https://en.wikipedia.org/wiki/The_One_Minute_Manager
It covers this, is very short, and (IMHO) is a good book to give all brand new managers. eg when they're promoted from individual contributors
Seems to set new managers on the right path. :)
2x2s can be really entertaining. One I've seen a lot covers the dimensions of lazy-hardworking and idiot-clever. The outcome is
* hardworking-clever: Ideal!
* lazy-idiot: don't need to worry, they'll not usually progress.
* lazy-clever: hmmm. not ideal but may still be useful from time to time.
* hardworking-idiot: bad! They can do a lot of damage
In truth there are usually more than two relevant dimensions.
https://quoteinvestigator.com/2014/02/28/clever-lazy/?amp=1
I think it requires a certain definition of "lazy" that basically translates to "delegate everything you possibly can" - which we all know can be hard work in itself.
IME they are the first people to challenge assumptions about the way things are done, and the least happy with the answer "that's just the way we do it"
Just make sure you review their code.
Spend the time that needs to be spent implementing the generalisable aspects, so that the work never needs to be repeated.
Implement the problem specific aspects (with minimal code) against those changes (and if any similar problems come up in the future, the changes can be made in minimal time and with minimal work).
I'd also say that very few people are inherently lazy, they're often just demotivated through misalignment of their responsibilities versus interests.
Captain and Commander - appropriate control and perspective, seen as that flow state in FFA chart
Micromanager - has too much control, not enough perspective, work gets out of control because it's being squeezed too hard
Crazymaker - has not enough control, but has lots of perspective. Work doesn't happen because new ideas pop up like fungus covering everything and nobody can iterate on anything because of all the context shifting.
Victim - not enough control or perspective, just responds to crises. Sounds like TFA version of the disengaged manager to me.
The thing is that the control and perspective axes change on the subject matter, so a person can be a Victim in one space and a crazy maker in another and a captain and commander in a third, at least at this point in time.
Halvorson, Heidi Grant & Higgins, E. Tory. 2013. Do you play to win - or to lose? Know what really motivates you. Harvard Business Review 117.
I took the OPs point on this to be that, at a certain level of seniority, delegation isn't enough.
I.e. lots of decisions will require consensus with ones peers to actually implement. And when you don't have active engagement and coordination from the level above:
1) peer consensus can take a lot more time and energy to achieve.
And 2) you can often end up with a compromise solution that's the worst of all options, because nobody has the authority to say - "we're doing it this way".
In general, I get the sense that at more senior levels management becomes much more about managing conflict between subordinates rather than managing individual activities. I think the article was written from that perspective.
Agreed - I would also add that the "sweet spot" for a given employee is not fixed; it may be context/situation specific, may change over time, etc.
That is to say, you may have to be more hands-on with the self-motivated misanthrope when a situation requires close collaboration with colleagues, or be more task-oriented with the technically competent people when they're overwhelmed with tickets.
So what's the lesson here?
If the manager is actually shitty at what they do/manage and has great people working for them, then being at the pub might actually be the most constructive / least destructive thing they could be doing.
The problem is: No manager ever thinks of themselves this way. They usually think they can do each one of their reports' job better than they can, when it's rarely true.
The best managers I've ever had throughout my career were the ones who knew their own limitations and acted accordingly.
The software engineering crew composed of 5 people straight out of college plus one grown-up to play the role of kindergarden teacher is quite common in our industry, but I very much doubt that such a team produces more/better stuff than if you just had one senior person do it all by themselves with zero communication/management overhead.
The real reason for having such teams is that you have to have some way of progressing these junior people to become senior and of progressing ICs to first-time managers.
In those teams, the manager is at least part-way a teacher/mentor. And, in some cases, they might best teach a lesson by letting their subordinate make a mistake, so they experience the consequences first hand and have the bad experience of having to dig themselves out of it. ...so, even in such uneven teams, there might be surprisingly good reasons for being less involved than a manager's impulse might naturally be. And the first-time manager gets to develop certain mindsets like reflecting on the right level and kind of involvement and so forth.
Department heads on a film set are usually people with long and proven track records. So are the people who work directly below a CEO, which the original article talks about.
I agree with the conclusions and overall thinking. I would however regard the example as an exception rather than the rule. Furthermore I think the creative industry has some peculiarities of its own (ie. most people would do creative work or hobbies without being paid, Justice as a rewarding activity). My point is that in a company or startups the intrinsic motivations might be very different.
Far from it. The times I've been put in charge of producing commercials or large art projects where I wasn't personally doing the work, I've done it by phone, mostly from a bar, and only intervened when someone made someone else cry on the set. This is the way to do it. Find the best people you can find, tell them what you want, give them a budget and let them do their best.
The great part is that the client will never have any idea if it could have been better. It probably couldn't have been better anyway.
Not every manager is like this.
Good managers will be able to evaluate their team members' actual abilities, and adjust their approach based on what is actually going on. As a manager, if you are able to hire experts who know how to successfully coordinate amongst themselves—and want to coordinate without sabotaging each other in some way, and are able to stay on-task, and prioritize things properly—then you can and should leave them alone to work, after pointing everyone in the right direction.
But who gets to decide if the people doing the work are really as good as they think they are? It's not just bad managers that delude themselves about their own abilities. Sometimes people need guidance or can benefit from guidance, but don't think they need it and are offended that you would even think they could benefit from it.
A lot of people you hear complaining about micromanagement fall into this category. Not everyone who resents being closely supervised can be successful without close supervision.
> The best managers I've ever had throughout my career were the ones who knew their own limitations and acted accordingly.
Same here. I would wager, though, that the best co-workers and subordinates you've had also were those who knew their own limitations and acted accordingly.
It really helps if a manager more or less knows how to do the tasks they assign/delegate. But hopefully they’re hiring people better than them at a subset of tasks. The managers job is to understand how it all comes together and the bigger picture of the company.
In essence, a maestro. A maestro can play all the instruments but not anywhere near as well as each individual player. The maestros job is keep them all in harmony so they can all play their best within the confines the maestro provides them.
I'm kind of suspicious about this story. It sounds either apocryphal or like a key piece is missing.
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.
> 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.
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.
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.
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.
The moment I got the micromanager my productivity dropped and I lost interest in the job. I hate having someone constantly check on what I am doing. I quit the job because I started hating it so much.
Now I have a boss who only ever communicates with me when I get something done and I come to them first. It's the best and I am very productive. So, I think one size definitely does not fit all.
However, to be fair, I don't work well in any corporate environment either so there's that.
Micromanagement happens when you can't trust that people will do the work.
Disengagement becomes bad if you can't trust that people will do the work.
Hire people you can trust to do the work and let them do it.
The interesting part was left out. How do you determine trust? How does trust differ by role? How do you verify continued trust? Etc.
Start with small wins to build trust that you can increasingly delegate larger and larger areas of responsibility.
The reality is you verify by being more hands on than you or your report want to in be long term - but a good manager explains what you're doing and that it is time limited intensity to build trust.
Assuming, of course, that you gave them a fair chance initially.
Define metrics that you both agree are an accurate measure of accountability for the role.
If the metrics are off pace, have a convo about what's happening and what needs to change to get them back on pace.
If they can never get back on pace, then there is a problem with the metric (trust in the system), or person (trust in the employee).
Again, it all comes down to trust.
And give them pay increases in line with inflation, in line with their gained experience and equal to or above market rates
I was just reading a story about how a king pretended to be a wandering drunken lout, and when his guards stopped him, he bribed some of them with gold, but others whipped and beat him and put him in a cell. Then he revealed who he was, and the guards who didn't lock him up and beat him, were whipped and banished.
Failing at team leadership doesn't mean you can't be a detailed product manager with a strong vision for a successful product. But you shouldn't be managing the team, those responsibilities need to go to someone focused on the team and not the vision
me: wtf is this doing connecting to this socket and getting this response?
mgr: because ............
and:
me: how do i claim expenses on the last trip i went on?
mgr: get form ... i will sign it, and then take it to accounts
unfortunately, you don't often get both, but i have had a couple, so it is possible. and i have tried to be one myself - it is hard.
But this serves as an object lesson.
If the manager is the CEO (often referenced in article), then either the writer is high level, or in a small company. If this is about CEOs then it's really not quite a question of management style, but leadership style - at a pretty high level.
It's not sustainable though. The idea is to dive in, figure out what to fix, then fix it into a system you can stop micromanaging. Otherwise you just won't have enough time to do the other important stuff.
Keeps you on your toes.
Which usually boils down to hiring processes which are generally shallow and mediocre in our industry no matter how much pride we take in them.
There's rarely any other reason.
- flexitime
- good salary
- more time off than the law enables (we live in the EU so this is not a small thing)
I mean seriously what else?
as employee I optimize "work rate" for value output as shareholder I optimize spending for profit
In real life of software building value output is decoupled from "work rate" for other professions like factory where quantity and quality are metrics easily measured then value output can be coupled with work rate.
If the job is task oriented why bother having employees just pay per task but maintaining and evolving software is not task oriented even some structures consider software engineers as transpilers of (bad written) user stories :)
Because the transpiling part is gone in few years LLM will do it better than any average programmer
> action could be seen as micromanagement
Micromanagement is a certain way of doing action — the typical micromanager is someone who wants to control all the details of everything, all the time.
Granted sometimes it is beneficial for a manager to go through something with their subordinates in all the detail, so the subordinates gain some implicit understanding how you would approach the thing on a detailed level. But this should be a one off, not something you do all the time.
Also: every act could be misunderstood as something else, that is in itself the reality of working in a team.
The best teams I have ever worked in intuitively did something similar to Crew Resource Managment (CRM as used in aviation, expeditions, ...) — the point is, the manager is a resource themselves if they micromanage they spread themselves too thin for when a real problem occurs — if they are not present, they waste their resource and have a team that might be used to work without management, so when a problem arises the new focus of the manager might or might not help. A manager is part of a team and a manager is a resource of the team. If your team will work better if you are gone, or collapses if you are gone, you are doing it wrong.
You want someone who can generate energy and not always chase it. You want someone with skin in the game and drives ownership in others. You don’t want someone who never takes a watch apart only to put it back in the same exact way, but experiments regularly with the parts.
Either extreme you will resent them. With a balance however, you will respect them.
I would love to hear a very clear and succinct definition of micromanagement. Any good references?
A manager should give the broad strokers and directions and their subordinates should work out the details. If a manager manages in such a way they basically end up doing the complete mental work themselves, they are micromanaging.
This might be bad for two reasons: first the manager themselves might loose the big picture, second the subordinates loose interest in their job because there is no challenge, no creative freedom, no wiggle room and no trust in their work. If you want your subordinates to grow and improve you need to give them work with which they can learn and grow and you need to have a certain level of trust in their ability — all things a micromanaging manager will not need to do.
That being said it is not micromanagement if a manager goes into the topic deep once in order to explain it to their subordinates — if they do it constantly then it becomes micromanaging.
When things are getting done on time and on budget, let the team run free.
When they don't, step in; if in the course of inquiry there's a bunch of bad decision-making, dysfunctional team, shoddy results, or an otherwise drastic departure from best practices, then it's time to micro-manage.
Trust & responsibility is a two-way street.
But there is a lot more nuance than that in the day-to-day life of a business.
What if things are getting done in an unsustainable way? Maybe there's a toxic individual on the team who's delivering lots of value, but building up a key person dependency by not collaborating. Maybe someone's burning themselves out and needs slowing down. Or there's a big upcoming change where the team will need hands-on help to deal with it.