In my experience, they have nothing to do with one another. This is especially true with technical leadership. Having people whose primary concern is organizational stability leading technical decisions is a recipe for resentment and dysfunction.
I would go even further and say if a person is concerned with making technical leadership decisions as opposed to people management decisions, they shouldn't be in "management". This includes being a CTO. Most CTOs are not as natural people managers as their VP Eng brethren, and CTOs are not best described as managers of other managers: they're entirely different roles.
> Software Engineering Middle Management is a toxin or a cancer.
In your second it seems that you don’t respect those lower on the ladder:
> Programmers are like cats and their opinions are more important and refined than anyone else's.
As a leader it’s important to distill good ideas from bad and be able to bring those lower on the ladder along. Give them the respect they deserve and you’ll get it in return.
> In your second it seems that you don’t respect those lower on the ladder:
That's a good point. I didn't intend any disrespect. Speaking as a programmer I was making a self-deprecating generalization. Not everyone has had the same experience as I have and I can see how that has weakened my comment.
I think I could have made my writing stronger if I had avoided the generalization and went straight to the point instead.
Thanks for pointing that out.
> As a leader it’s important to distill good ideas from bad
In a way I believe you're right.
> be able to bring those lower on the ladder along
However I don't think it's our job to deem which ideas are good. If we believe the source of goodness stems from our own personal experience and opinions then we may favor a team that merely agrees with us.
A good leader, in my opinion, must embody some of the qualities in TFA to make those determinations: being focused on the customer, the business, and their team. They need to look to the current context of all of these things and find the good ideas. They often come from unexpected places.
> Give them the respect they deserve and you’ll get it in return.
I believe this is a universal truth: give people respect, ownership, and accountability. It's important!
I inferred that they do respect the programmers - more than anyone else even.
The software we build ends up baking in those opinions: into the frameworks and libraries, into our philosophies, into the algorithms themselves, and ultimately into our culture. We end up with Rails whose claim to fame is being based, unabashedly, on its strong opinions. We end up with the LKML being what it is. We end up with ML algorithms with our biases built in. That's why our opinions are rather important.
Our opinions signal our status to other groups. If you're an opinionated statically-typed functional programming aficionado it's quite likely you're not going to fit in with people who are serious adherents to object oriented programming. And you will find many people without any opinions or whose opinions lie somewhere in between.
We can't avoid having them and it's important to be able to work with other programmers and so being able to set those things aside to focus on the customers' needs, the business context, and the well-being of your team takes precedence!
The refining part I don't get.
Being a leader is hard. Being a good technical leader is harder. Programmers are like cats and their opinions are more important and refined than anyone else's. And I don't think it's sustainable to work in an environment where your every mistake or bad day will make you seem like a dipshit to your team. It can be demotivating to work under someone who has a toxic attitude problem, for sure, but it's also hard to be perfect all the time.
One thing I would add to the Humility and Empathy section is that you don't have to be all these things all the time. It's okay to have a low-energy week where you don't feel up to mentoring junior developers. It's normal to get frustrated when you review code that consistently exhibits the same patterns and bad habits you've been coaching your team out of for months. Part of building humility and empathy is creating a team where it's fine to be vulnerable: the team knows you're having an off week, that your energy is low, and they trust you that you're going to recover and bounce back from it.