3 ms·

> their heart is usually at least in the right place I've normally seen that people in role #2 are just not prepared for the hard conversations that come with

> their heart is usually at least in the right place I've normally seen that people in role #2 are just not prepared for the hard conversations that come with being a manager. Sometimes, you have to call people out on poor or below-potential performance. If you do, I've found that most people will either pick up the pace or quit. If you don't, well... things get bad. The unfortunate chaps in role #2 leave poor performers around to poison the team (most coworkers slack off when they see somebody else slacking, particularly if you have the corporate-standard opaque compensation schemes), avoiding dealing with negative actions until either somebody else comes around and fixes it or the team is killed. I was in this situation once, where a string of #2s had been managing a decently-sized development team I was merging with and it took several months for me to sort through the people, clean house, and build a functional team again. You know the worst part? There were a few fantastic people who had utterly languished due to being surrounded by mediocrity. On the other hand, that was also the best part, because the "let's talk about how we're going to get you working on bigger and better things" talk is much more enjoyable than the, "concretely, we expect you to be doing X, Y, and Z at your level, none of which you are" talk. Type #2 managers leave a trail of broken teams and wasted potential in their wake. I respect few things as well as working for an upper-manager who can pick up on that behavior and nip it in the bud. At least, I think I would, if I'd ever seen it :-)

razzmataz 15y ago
I've seen type #1 managers alienate top notch developers due to a lack of being able take constructive criticism, and in general not knowing jack about software development. I've seen fantastic people who were canned due to minor technical disagreements with management while poor performers were left around to cause damage in addition to poisoning moral. I've seen people get the "we expect you to be doing X, Y, and Z at your level, none of which you are" talk, and when they those folks leave, everything falls apart, because either the expectations were bogus, or it really was a personal issue with the boss and the person in question. I've seen junior developers (with talent and potential) languish because they were given zero guidance, yet expected to perform at the level of a senior dev by a type #1 manager without any expectations being presented. I really don't think you can group managers into these two distinct camps. Maybe you need to have an axis or two extra for rating things like technical competence and interpersonal skills...
- larsberg 15y ago
  That's certainly true, and I apologize if I made it seem like I was encouraging type #1, in particular the "tends to micro-manage, frequently overrules consensus with his own views." Micro-managing your reports is a sign that you're either working on the wrong problems, your organization has span of control issues (i.e. you only have three directs), or you've got too many extremely junior/new-college hires who aren't yet capable of independent work. And if you need to overrule consensus, you failed to be clear about what success would be measured against when you delegated. These are pretty basic issues, but shops can certainly get them wrong. I guess, if nothing else, I'd argue that managers need training. I'm of course biased, but the training they provided at MSFT, particularly at the manager-of-managers level, was just fantastic. I only wish it had been available to people lower on the hierarchy so they could have learned about these mistakes as their scope grew and not after it had!

razzmataz 15y ago

I've seen type #1 managers alienate top notch developers due to a lack of being able take constructive criticism, and in general not knowing jack about software development. I've seen fantastic people who were canned due to minor technical disagreements with management while poor performers were left around to cause damage in addition to poisoning moral. I've seen people get the "we expect you to be doing X, Y, and Z at your level, none of which you are" talk, and when they those folks leave, everything falls apart, because either the expectations were bogus, or it really was a personal issue with the boss and the person in question. I've seen junior developers (with talent and potential) languish because they were given zero guidance, yet expected to perform at the level of a senior dev by a type #1 manager without any expectations being presented. I really don't think you can group managers into these two distinct camps. Maybe you need to have an axis or two extra for rating things like technical competence and interpersonal skills...

larsberg 15y ago
That's certainly true, and I apologize if I made it seem like I was encouraging type #1, in particular the "tends to micro-manage, frequently overrules consensus with his own views." Micro-managing your reports is a sign that you're either working on the wrong problems, your organization has span of control issues (i.e. you only have three directs), or you've got too many extremely junior/new-college hires who aren't yet capable of independent work. And if you need to overrule consensus, you failed to be clear about what success would be measured against when you delegated. These are pretty basic issues, but shops can certainly get them wrong. I guess, if nothing else, I'd argue that managers need training. I'm of course biased, but the training they provided at MSFT, particularly at the manager-of-managers level, was just fantastic. I only wish it had been available to people lower on the hierarchy so they could have learned about these mistakes as their scope grew and not after it had!