The outstanding engineer who wanted to become a mediocre manager | Maroun Baydoun

The Other Side

When your title changes, how much of you changes with it?<br>Software engineers are built differently. The great ones at least. Throughout my career, I've had the pleasure and privilege of working with—or under—a handful of them. They're the ones who taught me what books couldn't. The ones who proved that breaking the rules is sometimes the only rule. The ones who somehow balanced a healthy dose of scepticism with an undeniably open mind.

As I reminisce about the great ones that helped shape the engineer I've become, an uncomfortable question keeps nagging me. What happens when the mighty fall? I was there and I remember the announcements, the celebrations, and the aftermath. Here's the tale of outstanding engineers that succumbed to the lure of management.

A demotion in disguise?

The software engineering industry – and the corporate world at large – want you to believe they are meritocracies. Engineers are encouraged to hone their technical skills. We're told to choose a stack, a letter-shaped expertise and a 10-based output multiplier. In return, good performance (and savvy politics) often lead to promotions that bring higher income, a shiny new title and a load of responsibilities. Associate Junior Engineer, Engineer 2.5.0-beta, IC-ex-machina... the naming schemes get creative, and engineers happily sign up for the game. It's all smooth sailing until the dangling of the manager promotion flips the script.

The title is certainly attractive, especially when sold as the natural progression. "It's the only cure for your career plateau." Suddenly, all the years spent laying the bricks of engineering excellence fall by the wayside. Gone are architecture diagrams, proofs of concept and obscure JavaScript quirks. And in come spreadsheets, pre-alignments, alignment meetings, post-alignments, alignment follow-ups and follow-up alignments.

Careers don't have to be ladders in the first place (especially if you're afraid of heights).

The temptation is easy to understand. Who wouldn't want a promotion? It's only human to desire more and think big. But how do you survive when the career high sends you into the stratosphere, without the proper suit and helmet? How do you cope when you land on an alien planet where you don't speak the language?

Will you manage to manage?

You'd be forgiven for assuming I'm looking down at managers. Let me assure you—and them—that it isn't the case. I have nothing but respect and admiration for those who choose that path, especially those aware of the challenges lying ahead and equipped to tackle them—or willing to learn. Even when they fail, watching them struggle garners nothing but empathy (and a little unspoken I-told-you-so moment, if I'm being honest).

Managing human beings must be one of the most demanding jobs out there. Despite their complexities, computers, compilers and databases don't complain. They crash, time out or stop responding and generally recover after a reboot, a patch or a debugging session. Humans, on the other hand, disengage, burn out or slack off, and no reset button or IT-approved tool can come to the rescue.

Juggling between compassion and decisiveness, flexibility and rules, is a gift that very few possess. And it turns out most of those are not among the great engineers. The set of skills a manager employs are a far cry from what the industry moulds engineers to become, or what they're best equipped to tackle.

You'd also be forgiven for assuming I'm making the case that engineers are inherently ill-suited to management. And you'd be wrong yet again. There's no denying that our culture portrays us as nerdy caricatures wanting nothing more than to stare at gigantic monitors all day long. But great engineering has never been just about technical prowess. Navigating office dynamics, communicating effectively are hallmarks of great engineers. Knowing one's way around people is as valuable as knowing one's way around a codebase. Building consensus is as important as building great software. But none of that automatically makes you a good manager.

In my experience, the best managers operate somewhere at the intersection of both worlds and make it seem effortless to jump between the two as needed.

Don't take my word for it. Just ask Peter!

Peter saw it coming. Well, Laurence J. Peter did. In 1969, together with Raymond Hull, he put a name to what many had already been witnessing. In fewer than 200 pages, The Peter Principle walks us through a series of workplace vignettes and observations that have, perhaps unsurprisingly, withstood the test of time.

The book's thesis goes well beyond what I'm covering in this post, but the most relevant point is the following:

People get promoted based on their performance in their current position, even when these skills are non-transferable to the new position.

The authors provide plenty of examples where employees...