The traits that make for the best engineers … the habit of success and the ability to design effective systems … could turn them into outstanding managers. Too bad the one backfires on so many engineers-turned-managers, while they ignore the other.
“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 reduce the time spent error-checking because there are fewer errors to find.