This is a problem not just for coders but almost any technical area. A loooong time ago when I was still in engineering I worked for Big Corp, Inc. and they had a designation for master technical talent, I forget the name, so let's just call them Jedi Masters. It was a non-management path for those who didn't want to go the management route but it recognized their value to the company. If you reached this level you had no manager and had no assigned work but people from other projects could come to them for advice, help, consultation, etc. and they could choose what they wanted to work on.
Often the Jedi Masters were tapped to teach intro engineering course to new engineers on the specifics of the type of projects this company worked on, so this was a quasi-academic and quasi-consulting gig for the best of the best engineers.
As a fairly new engineer, I got assigned to a new group and invited to a meeting that could impact the system I was working on. I show up and it is a meeting with an engineering partner (outside company) that was contesting some calcs regarding the pipe strength and mounting requirements for an installation (multi-billion dollar project). Their engineering team was insisting on assumptions that would have quadrupled the cost of a system that our group was responsible for, not to mention weeks or months of delays to recalc and redesign the system. Unbeknownst to me, this dispute had been at logger heads for months with no resolution.
One of the Jedi's, let's just call him Fred, taught me years before in the intro courses and I had remained in contact with him over time. Based on the courses Fred taught I thought he might have the expertise and interest in this area to take a look at this problem so I met with him and gave him the technical details. He agreed to attend the next meeting and advise but he made me do all the calcs, presentation and etc. for the next meeting but all under his guidance. So I go through my PPT presentation and at the end the other company's engineers have all sorts of objections, disagreements, etc. So our Jedi steps in and starts fielding questions and asks them to justify their position. It turns out that their reference text they were using to justify their position was actually written by Fred! I can still hear the other engineer say, "you mean you are Fred XYZ that wrote book ABC" with awe and respect in his voice. It turns out they were missing some important exceptions and qualifications later in the book that Fred cited and the meeting and conflict was resolved.
So the moral of the story is to always have a Jedi in your corner? No.
The moral of the story is that engineers and problem solvers (and I assume coders) have different motivation than the "success" of big, showy career managing a lot of people. We (technical people) love to solve problems and management is projecting their values onto technical people when they offer them management positions as "promotions".
This is exactly the sentiment I was going for - people who want to stay engineers should be compensated for their badassery, and respected for it, which is usually all they want. That right there is exactly the "power to say No" I was talking about.
And how do you know if an engineer wants to stay an engineer or not? By asking them.
I don't want to disparage the whole management class but I think part of it is that manager types don't really get the motivation to solve problems. They think that if someone doesn't have a manager telling them what to do then they won't do anything, but that is just psychological projection. Fred was one of the happiest (and busiest) guys at this company and many strived to achieve his status.
Regarding respect; After this meeting technical colleagues praised me for bringing Fred in to get the problem resolved. Manager types praised ME for resolving the conflict. It was really a big deal and really advanced my career and Fred was happy to let me get the credit which is why he made me do the presentation but he got respect from the people "in the know" and that is all he really cared about.
(pure) managers don't attempt to solve technical problems because such action usually obstructs individual contributors. What's apparent here is the substantial difference in perspective between managers and ICs. Managers tend to see social equilibria and the network effects of tech problems. ICs can see much, much more deeply into specific (and usually key) aspects of tech problems. A lot of classic conflicts arise when ICs-turned-managers overestimate the depth and completeness of their comprehension and try to lead the technical effort rather than compliment it. Hence a lot of managers are 'uninterested in problems.'
> They think that if someone doesn't have a manager telling them what to do then they won't do anything
As someone who has moved from being an IC to being a manager, I can assure you that's not true. What we do think is that an engineer won't necessarily work on the right things. Engineers have a tendency to work on something until they've solved it, which isn't the same things as finishing it. This is why personal projects usually end up being unfinished and unpolished. Engineers also sometimes let the perfect become the enemy of the good. The oft-cited Malcolm in the Middle episode (http://www.youtube.com/watch?v=RHpJFROEOmg) illustrates this well.
As a manager, I don't see it as my job to keep my team busy or even productive...they do that on their own. I see it as my job to keep them focused, particularly on the tasks that will provide the most benefit for the business.
I don't think you are talking about the introspective capabilities of a whole class of employees (managers) but rather describe the percieved dynamic of an employee-manager relationship in a particular company culture.
Lots of industrial management theory offer this strategy oriented top-down command and control structure as the ideal dynamic for a BigOrg but my personal view is that it is the one that is most easy to describe academically and is probably best (best application for model, not the best model for...) for doing scalable things in a technologically fairly static setting.
If the company is structured around this top-down command tree then I imagine it's not as much necessarily about how the manager internally models peoples motivations but rather about the management culture of his colleagues and superiors within which he works.
>>This is the problem: manager types
>>There is no such thing, it is an absurd invention.
Of course there is. Management as a career track attracts certain types of people, just like engineering. Every manager is different but they share a lot of common traits. Hence, "manager types."
These 'types' exist only to allow academia administrivia to be more open for profit. There is not such a thing as a 'manager type of personality', or 'a tech type' - this is an invention, utterly arbitrary, and a product of a corrupt education system that allows such a mythos to occur in order to cater to industrialization of human economy.
Each company will have desired traits in their managers, whether they go for the servant leader or the authoritarian delegator, their desired traits will limit who they view as suitable for managerial positions. There will be "manager types," and to people who have worked for that company for 10, 15, 20 years, that is the "manager type" for all companies, in their view.
There are also some traits that _are_ required for managerial work, certainly not enough to define a personality type, but without them, people could not function in a delegating, influencing, or persuading position. They're the traits that allow people to perform those functions.
I'd certainly be willing to concede the point that those aren't even personality traits, but skillful applications of personality that could be developed.
TLDR: I agree with you, but there's enough nuance in what "types" could mean that you're looking at a discussion about very subtle things that many people might not consider at first.
At the base of typecasting/stereotyping is prejudice. If you prejudge someone as being 'a manager type' before they've done any actual, you know, management - then you are prejudicial in your approach. Just because someone doesn't wear a tie and conform to social normatives, does not mean they cannot do things "typically associated with" socially-constructed norms, or 'types'. This is the biggest problem with manager-culture today: that bigotry and prejudice is still very much a factor in human interaction.
Thanks for sharing!! Like this story a lot better than the linked blog article. A positive example of real evidence is so much more effective than an essay of meta.
I am glad you liked it. I know HN doesn't like the supposedly contentless "thanks for sharing" type of comments but I appreciate it and think it is important to express such sentiments. In fact, about half way in to writing my comment I almost deleted it -- thinking no one would really care. I am glad I was wrong and that I completed it.
I should add that HN doesn't like brief, content-free "+1" or "this" comments, but a few sentences explaining why you liked a comment, and why it was exceptional in some ways, is almost never a problem, and are often greatly appreciated.
For example, you'll note that choppaface's comment has not been downvoted below 0, and probably has a few upvotes.
By the way, I also very much enjoyed your comment.
I loved it entirely. It was literally the first thing I read after the front page (I always read comments before the article).
I understand HN reason for not wanting countless thanks as it adds to scroll and doesnt add to the discussion... but it would be nice if they had a simple collapsible thread like reddit so once you got the gist or saw things are getting repetative you could jump down to the next main comment
Incidentally, it was this comment thread that led me to find this[1] for the same reason you list. The lack of collapsible threads has bugged me for a bit and I have been considering doing my own bookmarklet for a while but never got around to it.
Often the Jedi Masters were tapped to teach intro engineering course to new engineers on the specifics of the type of projects this company worked on, so this was a quasi-academic and quasi-consulting gig for the best of the best engineers.
As a fairly new engineer, I got assigned to a new group and invited to a meeting that could impact the system I was working on. I show up and it is a meeting with an engineering partner (outside company) that was contesting some calcs regarding the pipe strength and mounting requirements for an installation (multi-billion dollar project). Their engineering team was insisting on assumptions that would have quadrupled the cost of a system that our group was responsible for, not to mention weeks or months of delays to recalc and redesign the system. Unbeknownst to me, this dispute had been at logger heads for months with no resolution.
One of the Jedi's, let's just call him Fred, taught me years before in the intro courses and I had remained in contact with him over time. Based on the courses Fred taught I thought he might have the expertise and interest in this area to take a look at this problem so I met with him and gave him the technical details. He agreed to attend the next meeting and advise but he made me do all the calcs, presentation and etc. for the next meeting but all under his guidance. So I go through my PPT presentation and at the end the other company's engineers have all sorts of objections, disagreements, etc. So our Jedi steps in and starts fielding questions and asks them to justify their position. It turns out that their reference text they were using to justify their position was actually written by Fred! I can still hear the other engineer say, "you mean you are Fred XYZ that wrote book ABC" with awe and respect in his voice. It turns out they were missing some important exceptions and qualifications later in the book that Fred cited and the meeting and conflict was resolved.
So the moral of the story is to always have a Jedi in your corner? No.
The moral of the story is that engineers and problem solvers (and I assume coders) have different motivation than the "success" of big, showy career managing a lot of people. We (technical people) love to solve problems and management is projecting their values onto technical people when they offer them management positions as "promotions".