4 ms·
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 ha
by dmfdmf 12y ago
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".
- icyfenix 12y agoThis 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.
- dmfdmf 12y agoI 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.
- choppaface 12y ago(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.'
- fsloth 12y agoI 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.