“When we promoted him, we lost a good engineer and gained a bad manager.”
It’s a common complaint. Engineering calls for a very different set of skills, aptitudes, and character traits than management, so there’s no particular reason to expect an engineer, no matter how smart and successful, to become a good manager.
Well, okay, there are actually two reasons to expect it, only one of them often backfires while the second one frequently fails to occur to engineers promoted into management roles.
The one that frequently backfires is that great engineers, like all great employees, have the habit of success: No matter what the assignment, they expect to get it done and get it done well, and they do whatever they have to in order to succeed in their assignments, too.
Including the assignment of being put in charge of a department. Too often, though, instead of this being a strength in their new set of responsibilities, it’s what does all the damage.
That’s because when an individual contributor does whatever it takes to succeed at something, it usually means figuring things out, picking colleagues’ brains, reading and learning, calling in favors, working more hours … you know, because you’re that kind of person yourself.
Managers, on the other hand, are supposed to keep things organized while delegating the actual work to the people who report to them.
The good ones understand that while they remain accountable for the results, they’re supposed to give both responsibility and authority to the employee to whom they’ve assigned whatever task or goal it is that they’ve delegated.
Too many engineers-turned-managers understand this only in their pre-frontal cortexes (cortices?), not their intestines — in theory, that is, but not when the rubber of that’s-how-I’m-supposed-to-delegate meets the road of maybe-the-assignee-won’t-get-it-done-right.
Worse, engineers being what they (we) are, “right” generally means “how I would have done it.”
Which is why so many engineers, when promoted into management roles, turn out to be lousy delegators, micromanaging, taking back assignments and doing things themselves at the first signs of trouble, or both.
They have the habit of success, which means that at the first sign of possible failure they do whatever it takes to prevent it.
On a task-by-task basis.
The second trait — the one that often fails to occur to them, is that they understand the form-follows-function principle and how to use it to design things that serve a well-defined purpose … and, for that matter, how to clarify the purpose of the thing they’re supposed to design, in order to put them in a position to design it properly.
Put in charge of an organization, engineers should be the best choice possible for designing the organization and the processes and practices it uses. They would be, too, except for two common blind spots. The first is that many engineers don’t think of organizational design as an engineering exercise in the first place. That’s easily fixed: Just call attention to it.
Their second blind spot, though, is themselves.
It’s all too common for engineers to organize information flows and approval processes so that everything has to loop back through them, and not just once, but several times.
Which brings us to a bit of communications protocol nostalgia (yes, KJR’s audience is capable of communications protocol nostalgia, and ain’t that grand?) — how the X.25 protocol was changed into frame relay, with an orders-of-magnitude improvement in both latency and throughput for the exact same physical connections.
X.25 assumed a high transmission error rate, and so included error-checking handshakes at every node of a multi-node transmission network. Frame relay assumes a low error rate, and so leaves the error-checking to the end points instead.
So we can call engineers-turned-managers who loop information and approval flows through themselves multiple times “worse-than-X.25 managers.” They’re worse than X.25 because, instead of relying on node-to-node handshakes as X.25 does, they pass all error-checking handshakes back to a central supervisory system instead (themselves). That slows actual transmission to a crawl.
They distrust both the links and the nodes, that is, and so they destroy both the cycle time and throughput (in network lingo, latency and bandwidth) of every process and practice they’re responsible for.
Were they to take off their succeed-at-all-costs hats and put on their engineer-the-organization hats, they’d recognize what they have to do: First, move to X.25, trusting their employees to recognize and correct errors without their having to personally intervene.
And second, establish the kind of staffing and level of trust among team members that reduces the time spent error-checking because there are fewer errors to find.
I strongly believe there are two additional reasons why engineers promoted to management end up being not-so-good managers.
The first was touched on in the column, but not really heavily: engineers are promoted based on their engineering accomplishments, not because of their management abilities. Many people, and it seems to be even more so for those in technical fields, simply don’t have the people skills to be good managers, and that’s what management is all about: people skills (both up and down the chain).
The second is that, in too many companies, being a manager is considered an additional duty rather than a primary one. The individual is still expected to get just as much coding, design, or whatever else done — with management duties piled on top. That sort of thing might work for a team leader position, but it doesn’t for manager.
Dave:
You hit the Bulls-eye! The expectations for a (fill-in-the-blank -position) is always:” We want to promote you (give you additional work) while continuing to do your former job…which you do so well.”
Organizations just don’t get it. Managing people is a full time job. It takes expertise, practice, and coaching/mentoring. People can be trained for years in their particular discipline, but for managing? They get thrown overboard and are told: “If you can swim and make it back to shore, we’ll give you a nice review.”
“Faster, Better , Cheaper” turns into “Slower, Worse, and much more expensive…until we go out of business.”
I can see myself in so much of what you’ve written. When it comes down to it, an excellent engineer or maybe programmer in my case, just don’t fully trust their subordinates to get it right (like maybe they would if they were to do it themselves) and so they end up doing more and more where their subordinates should be doing it. From the programming perspective, my concern was having to deal with the enevitable problems that the delegated didn’t or know how to avoid. So to not have to deal with the problems that I feared may occur it was often easier to just do it myself… Over time I would have a few “trusted” employees who I knew would do it right and not fail to live up to my expectations. These employees were like diamonds, valuable assets, that I just couldn’t do without and were the key to my success as a manager. More than just getting the assigned work done, they shielded me from my “fear of failure” as a manager responsible to my management for execellent results. Eventually I was freed from having to do the coding too. But that had its own negative consequenses too. I had to learn how to survive as a manager and eventually lost my well-honed skill as a programmer.
My family heritage (big dose of British) is that there is “my way” and “the wrong way”. I have gone to some effort to teach my children (son engineer, and daughter soon to be) the opposite … that there are an *infinite* number of correct ways of solving a problem. I had to learn this first hand as I saw many *successful* projects use styles and techniques that I thought were dead wrong. Sobering, but educational.
Bingo! (Don’t know if that’s British or not). Even beyond there being more than one right or wrong way, it isn’t as binary as “right” and “wrong.” There are better ways and worse ways, and even here people can disagree based on valuing different aspects of the outcomes differently.
Excellent analysis. I was an ace engineer, and became a poor first line manager, but for different reasons. I knew how to delegate, especially since I did not have the capability of many on my staff. I just didn’t understand company politics and the implied management loops that had preceded me.
Then I became a product manager, which in my company was a Marketing function. I wrote new product “requirements” documents that were approved an sent to development. I was careful to not tell them how to build the product, even though I could. When the design review came, and the prototype did not meet the requirements I asked why. The design engineers told me that they could not meet my requirements. I just asked “Do you want me to tell you how, or do you just want to try again?” Later, they asked in private for my ideas. The product was built that way and was a success. At least they were not embarrassed in a public meeting.
I believe the observations made are correct, but they are not limited to Engineers. I have seen many poor mangagers that are not engineers. There may be more engineers promoted to levels of incompentency, but that is not necessarily their fault. The promoting managers are looking for people that can get things done and there may be more engineers in that category.
Poppycock. These criticisms are just as apt with non-engineers who fail as managers. An engineer as manager uses his or her experience to the greatest advantage when decisions are aided by technical understanding. That was part of Steve Jobs’ strength. To often the decision makes have no clue and are to ignorant to even discern who does.
This article really hit home! I love engineering. I left engineering mid-career to accept a position as first line manager and was a poor one for many of the reasons you cite. I have returned to engineering (though not untainted).
Really Good Work…. You Helping People A lot