I agree with some of this, and disagree with other points.
I think the idealistic goal of management is to help teams live up to their talent potential. The realistic experience of management is often an abstraction layer between upstream and downstream, to help flow information, each layer helping to make a finer-grained set of decisions and adjustments to keep the overall company moving in the right direction.
I think that she’s right about the idealistic sense of what management is: to lead, to help people grow, to back your people so they can take risks, i.e. the “protect” component of “protect, direct, and eject”. The conflict that middle managers end up in comes from the fact that executives often just want middle managers to be company cops– and the executives are the ones who evaluate their performance.
I realized pretty clearly that the scope of my ambitions was greater than the scope of my ability to produce things independently. I could not write enough code alone to achieve the kind of impact that I wanted to achieve on the company I was working for.
This makes a lot of sense. The Business tends to undervalue what X hours of coding effort can do, but sometimes we overvalue it, because we make “network is reliable” type associations about the organizations in which we work.
Miss an alignment with whatever the manager (or THEIR manager more likely) sees as valuable, and you risk losing those resources or having them siphoned off for “more important/pressing” work.
Right. This is the “manage or be managed” world. If you don’t have the credibility (at least) and authority (often, also required) of a manager, your projects won’t be taken seriously and you’ll be shuffled into the darkness.
Here is the alternate cynical perspective: the technical track exists so that we won’t lose people who do good work and have valuable institutional knowledge, but the impact that those people have is often not equivalent to the impact that managers have (for good and for evil).
This is true but not immutably true. See above. The “manage or be managed” world tends to squeeze out those top technical contributors in terms of their ability to influence others' work or priorities. Inspiring people is nice, but inspiration takes the back seat when there are people (actual managers) going around with guns who’ve proven that they aren’t afraid to use them.
Most companies don’t actually need nearly as many people at senior levels of the technical track.
Ouch. Disagree, at least when it comes to the long term. In the short-term, you can “get ‘ir done” with a large team of inexperienced, commodity Scrum programmers. In the long term, you actually need people who know what they’re doing.
At a functional company, people aren’t usually promoted as managers until they have shown they can do the next job by managing larger teams and actually doing the work to show the results. Why should the technical track be any different?
I disagree with this claim. Companies say that they promote confirmationally (i.e. you’re made an X when you’re already an X) rather than aspirationally (i.e. with the goal of someone growing into the role) but that’s never true of managerial positions, and it can’t be. Why so? Try taking over your manager’s job, and see how long you last. The confirmational promotion claptrap is something that companies say because it’s an easy way to deny raises and promotions, i.e. “We won’t make you an X because you’re clearly still an X-1”. The truth is, no one knows what “Level X” vs. “Level X-1” work looks like. People get what they can negotiate, and one of the most important things to learn how to negotiate is how your performance is evaluated, both before and after the fact.
I would personally observe that often, senior technical staff work less hard than senior managers.
That I disagree with, but the work is different. The senior programmer might take a walk at 2:00pm to figure something out, but she’s still working. She might wake up in the middle of the night and scratch out a solution. That said, she’s not necessarily ass-in-chair for 8+ hours straight.
The manager, on the other hand, is booked solid with meetings. This “looks like” work, but it’s often reading the news on your laptop while showing face to keep up appearances. Now, executives give meetings more credibility than “the fun stuff” because (a) it’s what they do, and (b) it’s fish-frying, but I disagree that they’re working harder.
That said, there is an effort thermocline, which is the point at which jobs become easier with increasing rank (because you’re more “in the club”, can more easily deflect blame and take credit) rather than harder. Under the ET, management jobs do get harder as you ascend. Even still, as much as it’s a pain in the ass to be a manager, most companies and bosses will find a way to make it even worse to be managed.
I think that she’s comparing being an IC with a really good manager to being a manager, and that’s a “grass is greener” comparison because most managers aren’t good.
Now, you can imagine a situation where you have an engineering manager who deals with all the “people” side of things, paired with a technical specialist who makes all the decisions about what needs to be done and how it should be done, as per their technical expertise. Why doesn’t this situation exist? Well, imagine putting yourself into the shoes of the engineering manager. You are basically a glorified project manager with little decision-making power. Except… all of the people report to you. You have hiring and firing power. You write their reviews. Do you really have no decision-making power? If you disagree with the technical specialist about what needs to be done, why would the technical specialist have final say? It is unrealistic to believe that the person with management authority over the people would have no influence over what they do, even with best intentions assumed.
I don’t really understand why the author shoots this down. I don’t know what it looks like everywhere, but I have executed this solution multiple times with great success. It involves having respect and trust in people, but it worked great. The breakdown is that the manager is in-charge of the employees career and growth and interpersonal issues and the technical person is in-charge of all the technical aspects of a team/project/whatever.
I feel like the author must be using words differently than I am because much of this didn’t make sense to me. I’m not especially experienced on either side of this so maybe the author is completely right.
One thought, though, is that assessing the impact of an individual contributor is very hard. Some people produce stuff quickly but it’s riddled with debt. Other people are slow but make high-quality solutions that don’t need as much maintenance work in the long run. Some people are on a team that makes a tool everyone uses, but it’s hard to determine what portion of the product came from who, so who had the most impact there?
Given how hard it is to assess the impact of an individual contributor, a manager is at least one degree of separation from the actual work, so how do you assess a manager’s impact? Is it easier to feel like you’re having more of an impact as a manager because you can shuffle people around and help individuals grow or would the problem have been solved anyways if you didn’t do anything? I’m not even sure it’s knowable.
In short, I think people should do the jobs they want to do and enjoy. But I always become a little shakey when they try to rationalize it through some means other than that. Maybe they feel like they have a bigger impact so that is enough, regardless of if they do. I think conflating this “what I want and how I feel” with “my actual results” is a common problem people have when they talk about these very difficult to measure things. But maybe someone can show me where I’m wrong.
Dan mentions in his piece that one solution is that we could be promoting people more aggressively on the technical track. I agree with this, if the problem we are solving is giving productive individual contributors more money/bigger titles. Here is the alternate cynical perspective: the technical track exists so that we won’t lose people who do good work and have valuable institutional knowledge, but the impact that those people have is often not equivalent to the impact that managers have (for good and for evil).
Why is maximizing the impact of the most-influential people any better a goal than “giving productive individual contributors more money/bigger titles?” That is, the unspoken assumption in this piece is that it’s better for a few people to have a lot of influence than for influence to be spread more evenly–but that hardly seems like so self-evident a thesis that it doesn’t require any support. Most of the places I’ve worked would have benefited from having fewer people with the authority to override the team’s technical consensus.
I agree with some of this, and disagree with other points.
I think that she’s right about the idealistic sense of what management is: to lead, to help people grow, to back your people so they can take risks, i.e. the “protect” component of “protect, direct, and eject”. The conflict that middle managers end up in comes from the fact that executives often just want middle managers to be company cops– and the executives are the ones who evaluate their performance.
This makes a lot of sense. The Business tends to undervalue what X hours of coding effort can do, but sometimes we overvalue it, because we make “network is reliable” type associations about the organizations in which we work.
Right. This is the “manage or be managed” world. If you don’t have the credibility (at least) and authority (often, also required) of a manager, your projects won’t be taken seriously and you’ll be shuffled into the darkness.
This is true but not immutably true. See above. The “manage or be managed” world tends to squeeze out those top technical contributors in terms of their ability to influence others' work or priorities. Inspiring people is nice, but inspiration takes the back seat when there are people (actual managers) going around with guns who’ve proven that they aren’t afraid to use them.
Ouch. Disagree, at least when it comes to the long term. In the short-term, you can “get ‘ir done” with a large team of inexperienced, commodity Scrum programmers. In the long term, you actually need people who know what they’re doing.
I disagree with this claim. Companies say that they promote confirmationally (i.e. you’re made an X when you’re already an X) rather than aspirationally (i.e. with the goal of someone growing into the role) but that’s never true of managerial positions, and it can’t be. Why so? Try taking over your manager’s job, and see how long you last. The confirmational promotion claptrap is something that companies say because it’s an easy way to deny raises and promotions, i.e. “We won’t make you an X because you’re clearly still an X-1”. The truth is, no one knows what “Level X” vs. “Level X-1” work looks like. People get what they can negotiate, and one of the most important things to learn how to negotiate is how your performance is evaluated, both before and after the fact.
That I disagree with, but the work is different. The senior programmer might take a walk at 2:00pm to figure something out, but she’s still working. She might wake up in the middle of the night and scratch out a solution. That said, she’s not necessarily ass-in-chair for 8+ hours straight.
The manager, on the other hand, is booked solid with meetings. This “looks like” work, but it’s often reading the news on your laptop while showing face to keep up appearances. Now, executives give meetings more credibility than “the fun stuff” because (a) it’s what they do, and (b) it’s fish-frying, but I disagree that they’re working harder.
That said, there is an effort thermocline, which is the point at which jobs become easier with increasing rank (because you’re more “in the club”, can more easily deflect blame and take credit) rather than harder. Under the ET, management jobs do get harder as you ascend. Even still, as much as it’s a pain in the ass to be a manager, most companies and bosses will find a way to make it even worse to be managed.
I think that she’s comparing being an IC with a really good manager to being a manager, and that’s a “grass is greener” comparison because most managers aren’t good.
I don’t really understand why the author shoots this down. I don’t know what it looks like everywhere, but I have executed this solution multiple times with great success. It involves having respect and trust in people, but it worked great. The breakdown is that the manager is in-charge of the employees career and growth and interpersonal issues and the technical person is in-charge of all the technical aspects of a team/project/whatever.
I feel like the author must be using words differently than I am because much of this didn’t make sense to me. I’m not especially experienced on either side of this so maybe the author is completely right.
One thought, though, is that assessing the impact of an individual contributor is very hard. Some people produce stuff quickly but it’s riddled with debt. Other people are slow but make high-quality solutions that don’t need as much maintenance work in the long run. Some people are on a team that makes a tool everyone uses, but it’s hard to determine what portion of the product came from who, so who had the most impact there?
Given how hard it is to assess the impact of an individual contributor, a manager is at least one degree of separation from the actual work, so how do you assess a manager’s impact? Is it easier to feel like you’re having more of an impact as a manager because you can shuffle people around and help individuals grow or would the problem have been solved anyways if you didn’t do anything? I’m not even sure it’s knowable.
In short, I think people should do the jobs they want to do and enjoy. But I always become a little shakey when they try to rationalize it through some means other than that. Maybe they feel like they have a bigger impact so that is enough, regardless of if they do. I think conflating this “what I want and how I feel” with “my actual results” is a common problem people have when they talk about these very difficult to measure things. But maybe someone can show me where I’m wrong.
Why is maximizing the impact of the most-influential people any better a goal than “giving productive individual contributors more money/bigger titles?” That is, the unspoken assumption in this piece is that it’s better for a few people to have a lot of influence than for influence to be spread more evenly–but that hardly seems like so self-evident a thesis that it doesn’t require any support. Most of the places I’ve worked would have benefited from having fewer people with the authority to override the team’s technical consensus.