I look at it a bit less negatively. I think there are people who believe in micro-management. Most micro-managers don't think of themselves as such, but it isn't really up to them.
IMO you know you are looking at micro-management when negative outcomes are dominated by decision fatigue on the part of the micro-manager. I call it decision fatigue because I generally assume my manager is a smart guy.
A micro-manager's first instinct is to find something to change whether it is needed or not. Don't give it to them. Make them ask questions and work through the problem themselves. If they are allowed to skip to the end you tend to find they end up off in the weeds and are dogmatically opposed to retreading ground where they have made a mistake or an incorrect assumption.
That's your Mad Men style turn a no into a yes sort of situation and you are going to be fighting against the decision fatigue your manager is feeling because they micro-manage :-)
This is the same strategy I use when mentoring or managing. If I can't convince someone who thinks they are subordinate to me then how do I know I am right? How do I equip them to come to the correct conclusion on their own in the future? I generally ask people to articulate rather than trying to figure it out myself because I am usually juggling N other balls and they can do it faster and better.
I care a lot less about larger organizational issues. Why take on someone else's responsibility? Employees are free to leave at any time in the current environment so why borrow trouble? Are you expecting someone to thank you?
That's "manager"-style micromanagement. There's also "lead"-style micromanagement: someone who was in the trenches handling everything, and now is supposed to delegate and manage others, but doesn't necessarily know how—their first instinct is still to do everything themselves, and when they don't have enough time, to micromanage whoever is doing it so that the result will come out the same as if they did it themselves.
I wish there was a single book I could hand to these people, or a training course I could suggest for them, because they frequently know they have a problem "letting go" but don't know what to do about it.
If such a book existed, I could imagine it becoming the standard "gift" a VC gives a founder the day they hire their first salaried employee. ;)
I recently read "The Principles of Product Development Flow: Second Generation Lean Product Development"[1] that was recommended to me.
Some of it was familiar. Some of it was new. The language used and how the book articulates the reasoning behind various strategies has been invaluable to me in expressing to others why something is a tractable problem as opposed to an unavoidable one that is just the cost of doing business.
To date I have not succeeded in getting anyone to read it though.
This is exactly why I think that managers are counterproductive to the success of technical products and should not have the authority to make these kinds of decisions. If you can't solve problems, you have no business managing people who can. If I'm really making the decisions, I shouldn't have to give up credit for the decisions I've made, or make someone else feel like they were useful when they weren't to feed their ego.
Managers in many tech companies are just secretaries who somehow were given titles, authority, and pay that makes it seem like they are the decision makers, when in fact their only value is to handle the paperwork and PR so that the actual problem solvers can solve the problems. It's unfortunate, because it's really holding our entire industry back.
I vehemently disagree with this sentiment. Not to argue against the existence of bad managers (nearly everyone has an anecdote from one time or another), but that doesn't diminish the worth of a strong manager (especially in larger organizations). A good manager of technical team server 2 main purposes in my mind. The first is an insulation between the team and and the outside world. Your "problem solvers" aren't going to get anything done if they spend their entire days negotiating with clients or fielding reqs from other departments. Secondly, a good manager acts as a focusing lens for the team. This allows the individual member to concentrate on any given technical problem without needing to expend the bandwidth to constantly come back to how their piece needs to work into the bigger picture.
There might be a whole host of things holding the tech industry back but the idea of the manager certainly isn't one of them.
If you just want a position that gives the people around them those two benefits—without assuming where the position would sit on the org chart—then you will notice there exist a lot of other, similar jobs, that do not also possess the assumption of "supervising" and "being responsible for" the output of the people around them.
For example, what you're describing fits closely to the idea of a shared administrative assistant. Or a talent agent. Or a sports coach (or "team manager", which is a misnomer.) Or a diplomatic envoy.
None of these people are the boss of the people they work with; they assist the people they work with in getting things done. They do not hire or fire the people they work with; they are not blamed for the incompetence of the people they work with; and they have no incentive to play politics with the lives of the people they work with for the sake of a promotion. Their job is purely to help their team work, and to deflect things that prevent work.
Personally, I think we could use way more of these types of "pure interfacer" people in companies; and, in so having them, the need for "managers" would decline sharply. There'd still be some managers—people whose job is to take ultimate responsibility for the output of a group, and who are thus incentivized to direct and reorganize that group. But, with the jobs of keeping the team protected and glued-together taken care of, the active role of "manager" would be reduced enough that they could either be scaled across greater numbers of people, or could be a "manager" for their own group as an accessory role to their regular job.
> The first is an insulation between the team and and the outside world. Your "problem solvers" aren't going to get anything done if they spend their entire days negotiating with clients or fielding reqs from other departments.
This is exactly the role of a secretary.
> Secondly, a good manager acts as a focusing lens for the team. This allows the individual member to concentrate on any given technical problem without needing to expend the bandwidth to constantly come back to how their piece needs to work into the bigger picture.
This is exactly the problem: technical problems will never be solved well unless you are constantly coming back to how each piece needs to fit into the bigger picture. Contrary to your belief, any half-decent programmer is quite capable of doing this. And managers who try to prevent programmers from doing this are literally preventing programmers from doing their job. This is why programmers do things like present an almost-correct solution to the problem so the manager can feel like they've "acted as a focusing lens for the team" to get the last part of the problem. And that's a moderately decent-case scenario for your hypothetical "focusing lens manager"; the more common case is that this manager focuses on the wrong thing entirely because they don't know what a computer is capable of.
I have a manager and I greatly value his ability to communicate with the stakeholders and CEO, as I have little desire to do so. Ours is not a tech company, however. I'm happy to delegate the paperwork and PR to him, I certainly don't want to do it, and consider our pay differential the price of happiness. Sure I could do it, but why?
Why do you care about the success of the technical products you're working on? Aren't you aware that it's going to mainly hinge on the quality of the marketing? Do you want to take responsibility for marketing too? If so you should really go to YC and found a company.
> Why do you care about the success of the technical products you're working on?
If you're asking that question, then really everything else in the pile of mediocrity you just wrote makes sense. If you don't care, then dysfunction is not a problem.
> Aren't you aware that it's going to mainly hinge on the quality of the marketing?
Sure, if you're producing a Web 2.0 Social Media glorified ad server, sure, your shitty product can only be saved by advertising. I prefer to work on actual problems such that solving them will provide value, though.
> I prefer to work on actual problems such that solving them will provide value, though.
I think you're living in a fantasy world. It's not enough that you solve a problem. You actually have to bring it to the world. Mochizuki claims to have solved the ABC conjecture, but isn't doing anything to promote his work, leaving the rest of the mathematics world to pick up his slack. Tell me what you're working on is that important, that the rest of the world will seek you out if you fail to promote it.
I work for a cosmetics marketing company. We design and market three different lines of cosmetics and skincare. I do their website backend. Our products are really good, and attractively priced compared to our competition. We are not producing a Web 2.0 Social Media glorified ad server, but it's not a shitty product, but it does need effective marketing.
My contribution is to enable their marketing efforts. Me putting in 3x the effort isn't going to help their bottom line a whit, and it might even hurt it by lowering the stability of their platform.
> It's not enough that you solve a problem. You actually have to bring it to the world. Mochizuki claims to have solved the ABC conjecture, but isn't doing anything to promote his work, leaving the rest of the mathematics world to pick up his slack.
The problem isn't that Mochizuki hasn't marketed it: his solution is widely known despite him not marketing it at all. The problem is that his solution is incomprehensible, even to other mathematicians. And it's worth noting that, if made comprehensible, his solution will provide enough value that people are willing to take the risk of attempting to understand his work.
> I work for a cosmetics marketing company. We design and market three different lines of cosmetics and skincare. I do their website backend. Our products are really good, and attractively priced compared to our competition. We are not producing a Web 2.0 Social Media glorified ad server, but it's not a shitty product, but it does need effective marketing.
Your product is not your website, it's the good cosmetics at a good price. In the current economy, yes, you do need marketing to get there, but your marketing would be worthless if you had a crappy product (or maybe not, but that's even worse).
So you're working on a product that provides value, and your job is not a disproof of anything I said.
> Me putting in 3x the effort isn't going to help their bottom line a whit, and it might even hurt it by lowering the stability of their platform.
That's quite a straw man you're presenting. I never said you should put in 3x the work: I'm a big proponent of keeping a sustainable pace. But I'm also a proponent of understanding the problem you're solving, and if you're looking at a piece of code in isolation from the context of the business, you don't understand the problem you're solving.
I forget the source but I remember a story about an ipod prototype being shown to Steve Jobs, where they deliberately showed him a flawed early model that he could evaluate and reject, allowing him to realize what should be fixed. Then when they showed him their improved solution he would be better able to accept it, feeling that he was a part of the thinking that improved the design.
Steve Job's name was on a number of patents - I expect however that a significant amount of those reflect his involvement though this sort of "handling", where it was important to draw him into a consensus by letting him think through a design problem that was probably already solved.
IMO you know you are looking at micro-management when negative outcomes are dominated by decision fatigue on the part of the micro-manager. I call it decision fatigue because I generally assume my manager is a smart guy.
A micro-manager's first instinct is to find something to change whether it is needed or not. Don't give it to them. Make them ask questions and work through the problem themselves. If they are allowed to skip to the end you tend to find they end up off in the weeds and are dogmatically opposed to retreading ground where they have made a mistake or an incorrect assumption.
That's your Mad Men style turn a no into a yes sort of situation and you are going to be fighting against the decision fatigue your manager is feeling because they micro-manage :-)
This is the same strategy I use when mentoring or managing. If I can't convince someone who thinks they are subordinate to me then how do I know I am right? How do I equip them to come to the correct conclusion on their own in the future? I generally ask people to articulate rather than trying to figure it out myself because I am usually juggling N other balls and they can do it faster and better.
I care a lot less about larger organizational issues. Why take on someone else's responsibility? Employees are free to leave at any time in the current environment so why borrow trouble? Are you expecting someone to thank you?