So You Want To Be An Engineering Leader?
For twenty years now, the Spider Man quote, “with great power comes great responsibility” has been used so much that it deserves no further veneration. Software engineers for the past ten years found themselves in a rather unusual spot. Not only are they paid a ton, the cost of failure in anything they do has very little bearing. When a surgeon screws up, life is at stake. When a software engineer screws up, all that’s needed is a hotfix. I say that because a Software Engineer earns around as much as a surgeon yet the former found himself cuddled with bean bags and free food and ping pong tables.
This phenomenon of course, which is supposed to be a breeding ground of gratitude, ended up being a breeding ground of greed (or as Charlie Munger rightly pointed out recently… envy.) Instead of celebrating their positions in this capitalist society, software engineers ended up, like any other normal human, fighting over dominion… and with that comes titles.
Back in those days, there are no such things as Staff Engineers, Principal Engineers, Distinguished Engineers, Fellows, and so forth. There are just Software Engineers… and we’re perfectly happy with it. I used to work in a company where most of us had eight to twelve years of experience and our titles are… you guessed it… Software Engineer. No Senior, no Staff.
Yet the world has changed. A new generation of engineers who haven’t been through the 2000–2001 dotcom crash and the 2008–2009 Global Financial Crisis created an industry of entitlements… a chasing after the wind, which then of course created in itself some of the rather toxic hiring processes and even work cultures. It turns out that adversity does not build character, it reveals it.
Adversity does not build character, it reveals it
Looking at career matrixes, I have yet to see one that attributes maturity to seniority. How mature must your Principal Engineer be? Does he roll on the ground screaming like a two-year-old when things don’t go his way? What about your Director of Engineering? Or your CTO? Does he have the backbone to be the bad guy? Can he make a decision not everyone will be happy with? Can he take criticisms, more specifically, those unfair ones… and move on?
It’s rather interesting that software engineer interviews have a lot to do with detecting technical skills (nothing wrong with that) but too little to do with detecting their maturity. Software Engineering, it turns out, is as much a technical endeavor as it is a team effort.¹
Looking at the inventory of Software Engineers I’ve worked with, from Junior all the way to VP/CTO levels, I’ve seen around 15–25% of them have problems with emotional maturity. While this can be sandbagged better for the individual contributors, those who reach the Middle Management and Senior Management levels end up becoming trouble.
The Software Engineer’s primary job is to help the business win. His secondary job is to write good code. An immature software engineer will flip those two around. For the business to win, there should be alignment between people and between teams. As much as the engineer hates meetings, that’s exactly what is needed to drive alignment. If meetings are expensive, try misalignment.
Which leads me to another point.
Fire Fast, Hire Slow
If there’s one thing I learned in my years as an engineering leader, it’s that at the moment I lost hope on a direct report, there’s no point in not firing the person. I’ve always found that delaying a decision not only adds more suffering to the person, it also adds more suffering to the rest of the team. Firing is not fun, that’s why most people want to avoid it.
Over the course of my career, I’ve recommended several dozen to be let go. Those whose recommendations were denied end up causing more trouble. Some were let go later. Others demoted. Still others were left without the senior management lifting a finger, hence thus, remains a festering problem.² Is it fun? It’s never fun. What reasonable human feasts on the suffering of others?
I’ve also found quite a bit of managers (some very experienced ones), who dread firing. If the engineering leader hasn’t built a backbone to stand up to criticism, he should not be an engineering leader. Tech Leads, Engineering Managers, Directors, VPs, and CTOs are magnets of criticism. The higher you go, the worse they are. The higher you go, the more people you will take livelihood away from… because unlike being a Software Engineer, you’re now sitting in between the business and the person and you have to often make difficult decisions. Sink the ship, or throw one overboard? The engineering leader’s main responsibility is toward the people that should stay, not the people that should go. Often, there are no easy decisions, and the night after you let someone go… the soup will taste like corpses.³
This, therefore, means that one should be very careful with hiring.
I’ve made a mistake myself whereby I felt strapped with the time to fill and, in wanting to appease a colleague, ended up hiring someone who wasn’t a good fit. I also learned along the way that of all the people we ended up hiring that I had doubts about, and there are dozens of them, only two performed to, or above my expectations. Every one of them I wished we never hired.
I learned that a colleague who fails to respect the overall opinion of the hiring committee either has to change attitude or change company. I did worry about this in the past and I may end up making the same mistake in the future… yet every time I worry that someone smart might harbor bitterness because he didn’t get what he wanted, I end up being instrumental to an outcome nobody wanted. In essence, I could have prevented a sour outcome and chose not to.
Leaders Lead. Coders Code. Learn the Difference
Another common problem I’ve seen is that many engineering leaders can’t let go of coding. Every hour an engineering leader spends coding is an hour he could have spent leading. Leading requires vast and thorough strategic thinking, influencing, driving alignment, executing, and measuring.
If the engineering leader can’t let go of coding, one better believe a dysfunctional team is buried beneath the surface. To be clear, a dysfunctional team is not always a team of unhappy people. Rather, it’s a team of underutilized talents and suboptimally deployed resources.
So if the engineering leader can’t let go of coding, he should not be a leader. There’s no shame in handing over the mantle to someone who can do a much better job.
Conclusion
So you want to be an engineering leader? With great power comes great responsibility. Life doesn’t get easier the higher one goes. The stakes are higher, the problems are tougher, and often, there are no easy options. If the engineering leader can’t take unfair criticisms, can’t fire people, and can’t stop coding, he’s probably not ready.
Now that 2023 is coming, if you haven’t soiled your hands with blood as an engineering leader, be prepared. 2023 will be a tough year in tech. If you’ve been cuddled all these years and didn’t have to do the dirty job, prepare a garbage bin. You might need to puke on it a few times. There’s a very thin line between charity and capitalism. Idealism and realism. The wish is that you can have both… yet many a time, you have to choose one at the expense of the other… that’s… not fun.
___
¹ For the most part. Unless of course you’re the sole engineer in your company, in which case, you can code in Wenyan and nobody cares.
² The truth, of course, is always somewhere in the middle. Which means my opinion does not fairly represent the aspects that I don’t see.
³ Pulled from Elie Wiesel’s Night. Go read it.
