5 ms·

I've reported directly to good CTOs and really bad ones. The shitty ones: - Either never built trust or broke trust. - Were impulsive and reactionary. - Did

I've reported directly to good CTOs and really bad ones. The shitty ones: - Either never built trust or broke trust. - Were impulsive and reactionary. - Didn't rely on the expertise and skills of their reports as much as they told them what to do because they already knew everything. Didn't ask questions. Gave orders. - Literally used the words, "because I said so". - Believed that they were the only one doing any real work. Used the words, "easy" to describe work that was assigned to their reports. - Were very insecure - questions were often received as challenges to authority. - Set in place policies which they were the first to violate. - Their actions and their words disagreed. - Lost their best people within a year.

colechristensen 4y ago
The challenge in technical leadership is letting go of the specifics and delegating them and only in very rare specific circumstances issuing orders. There are a lot of "person who did everything" types who end up in leadership positions who try very hard to continue doing everything of any importance instead of appropriate delegation and leadership instead of control. I've had that problem, it's hard to let go.
- ajmurmann 4y ago
  This is such a good point. And doing this right can result in the technical leader feeling like they aren't providing value, especially if they are used to being great at solving technical problems themselves in the past. The manager dopamine loop is much longer and can at times not exist at all and you are still doing it right. I can see that it might be very tempting to try to get the feeling of accomplishment my stealing it from folks by disempowering them.
ctothrowaway8 4y ago
This comment may have been the tipping point into seriously considering quitting. Deep down I already felt it coming on but seeing it laid out like this hit home. The person currently in that leadership position fits every one of these bullet points and somehow remains in that position. All their direct reports just seem to accept this lot in life, everyone else does their best to avoid drawing their ire. I imagine that maybe something will happen and they will get the picture and actually grow as a leader. It's growing old though and I miss being on a team wherein this wasn't the day to day morale. Maybe they'll read this. Maybe it's you. Please take this seriously. You could do better.
- theteapot 4y ago
  > Maybe they'll read this. Be proactive, send them a link.
- jasonm23 4y ago
  Sounds like me 10 years ago, and I wish I took this advice. If you love technical work, QUIT being an exec, a VP, a manager... do the work. You WILL have a crazy time getting back into tech work, after 10 years, even if you were hands on the whole time. Management / CTO and everything in between is best served by people who are technical, and are ready/aware/willing to move into a deeply political and financial driven domain. I hated it, but it took me a years to really let that sink in and feel it hurting me. If you can short circuit that wasted time. Do.
  - jon-wood 4y ago
    Absolutely agreed. I'm currently working my notice after 5 years of technical leadership, after which I've got a job lined up where I can get back to sitting down and writing code. The last few years have been great experience, and I have no doubt they'll make it easier to work with management types in the future through understanding the sort of decisions they're having to make, but I have no desire to play politics for the rest of my life while other people go and do the bits that motivate me to get out of bed in the morning.
    - johnnymorgan 4y ago
      I'm a sysadmin background, did CTO for 9 years and then moved to product afterwards from the knowledge I gained. Being on the other side of the fence has really helped me move around, I still to sysadmin/DevOps type work but mostly moved into product and I've found it really helps. Too many C level see product as only UI/UX and the teams I manage appreciate my understanding of the pain points for everyone
deleted 4y ago
[deleted]
29athrowaway 4y ago
Because bad organizations conflate leadership and dominance. Raw dominance is the dynamic governing primitive social animals. Chimps are a bit smarter, and would collaborate as a group to beat up alphas that they hate.
- jasonm23 4y ago
  Let me rephrase that. The group is smarter, than an individual's dominant strategy. They'll collaborate as a group to embarrass and undermine and quit that scene.
- nix23 4y ago
  Fun fact, there are nearly no Animals who life in groups with "real" alphas, especially not Wolfs, maybe you can say Elephants where the oldest (most of the time) female is the leader (however that is because she is the most knowledgeable (location of waterholes, food etc)) and not because of her Character or "i want to be a leader" mindset. There is one exception that comes to my mind with "real" Alphas and those are Gorillas.
bruce511 4y ago
Interestingly this list covers "bad manager skills". Which emphasises the point that bad managers are bad. Equally a good manager with average tech skills can do everything opposite to this list with the help of technical advice. Sure we'd all like a great tech guy who somehow is also a fantastic manager. But let's accept those are rare. Next best is a great manager (emphasis on good, not bad) who listens well and takes advice regarding pure tech matters. Over time their tech will improve (remember, good manager) but in the meantime IT flourishes. Only then comes a great tech guy with poor management skills. Frankly poor management will kill a team faster than good tech skills can save it. So yeah, as the article suggests, a great all rounder would be the best option. But I feel there aren't enough of those to go around. In that case I'll take a good manager over a good techie all day long.
hef19898 4y ago
In defence of "because I say so", it sometimes necessary. And not a big deal in my book, if the person giving the order is also owning all the outcomes, good and bad. Fully agree on everything else. Additional caveat, I have a supply chain and logistics ops background, so a completely different environment to design and development.
- jon-wood 4y ago
  "Because I say so" is a terrible way to communicate why a thing is being done. In senior positions it is definitely necessary now and again to pull rank and tell people something is being done despite their protests, but I don't think I've ever found a situation where I couldn't articulate why that decision had been made. People may disagree with that decision, hell, sometimes I've disagreed with the decision I'm communicating, but you owe it to your people to communicate the reasons.
  - hef19898 4y ago
    Fully agree on giving reasons. And more often than not there is room to discuss them. Also, from time to time, it doesn't matter weather or not we agree with those. And then there are those moments were there is no time to discuss. Good leaders know to tell those appart, and professionals can accept it. Unfortunately, this combination, good leaders being in charge of professionals, is rarer then I'd prefer.
    - johnnymorgan 4y ago
      Too rare but when you get it, it's gold baby
      - hef19898 4y ago
        Solid, 24 carat gold.
  - bluefirebrand 4y ago
    I had a situation recently where I had a report argue with me constantly over team agreement stuff like code standards and unit test coverage. I explained every piece of rationale I could come up with for why the team chose to do things the way they did. I offered to schedule team discussions for her to try and convince the team to adopt other strategies, with the understanding that if the team didn't want to do things her way that would be the end of the discussion. It wasn't the end of the discussion for her though, she kept complaining. Eventually I just had to say "that's the way we do things here so you have to get on board". It's awfully close to "because I said so", and I hated saying it, but I exhausted every other avenue I could think of. She wound up giving her notice, so I guess we were on the same page because I was working with my manager on letting her go. But if she had been able to keep her head down and do the work we would have kept her for sure. She was a good coder, good systems knowledge, just really didn't like writing unit tests I guess.
samhuk 4y ago
Adding to that list, and somewhat related to your first point: Never built anything technical of any quality. A coach that never played can't teach.
- ambicapter 4y ago
  Hard disagree. A good coach only needs to see the players on the field, notice the things that wins game, and figure out the way to motivate their players. Don't need to have played the game, though it helps. I'm thinking of one of the best coaches in the world, who played the sport at an unimpressive level as a teen...but at a young age he watched his father work as an assistant coach. That's where he learned his skills. As well, the requirement for "must hit X bar of quality", where X is some arbitrarily high level, is nonsensical. If they're so good at building quality products...then why aren't they doing that in the first place. Necessarily, your best builders should be builders, and your best managers...should be managers.
  - samhuk 4y ago
    > notice the things that wins game > motivate their players These are made so much easier if you have "played the game" that you pretty much end up back to the original argument of it being a requirement if being "a coach" to remain competitive. There of course will be outliers to this, like your aforementioned "coach that never played", but why deliberately base your point on an outlier? > "must hit X bar of quality", where X is some arbitrarily high level Quoting myself, I said "of quality", i.e. something that is reputable and, relative to some reasonable and well-known industry standard software development principles and benchmarks, of quality. I wouldn't say it's totally arbitrary.

colechristensen 4y ago

The challenge in technical leadership is letting go of the specifics and delegating them and only in very rare specific circumstances issuing orders. There are a lot of "person who did everything" types who end up in leadership positions who try very hard to continue doing everything of any importance instead of appropriate delegation and leadership instead of control. I've had that problem, it's hard to let go.

ajmurmann 4y ago
This is such a good point. And doing this right can result in the technical leader feeling like they aren't providing value, especially if they are used to being great at solving technical problems themselves in the past. The manager dopamine loop is much longer and can at times not exist at all and you are still doing it right. I can see that it might be very tempting to try to get the feeling of accomplishment my stealing it from folks by disempowering them.

ctothrowaway8 4y ago

This comment may have been the tipping point into seriously considering quitting. Deep down I already felt it coming on but seeing it laid out like this hit home. The person currently in that leadership position fits every one of these bullet points and somehow remains in that position. All their direct reports just seem to accept this lot in life, everyone else does their best to avoid drawing their ire. I imagine that maybe something will happen and they will get the picture and actually grow as a leader. It's growing old though and I miss being on a team wherein this wasn't the day to day morale. Maybe they'll read this. Maybe it's you. Please take this seriously. You could do better.

theteapot 4y ago
> Maybe they'll read this. Be proactive, send them a link.
jasonm23 4y ago
Sounds like me 10 years ago, and I wish I took this advice. If you love technical work, QUIT being an exec, a VP, a manager... do the work. You WILL have a crazy time getting back into tech work, after 10 years, even if you were hands on the whole time. Management / CTO and everything in between is best served by people who are technical, and are ready/aware/willing to move into a deeply political and financial driven domain. I hated it, but it took me a years to really let that sink in and feel it hurting me. If you can short circuit that wasted time. Do.
- jon-wood 4y ago
  Absolutely agreed. I'm currently working my notice after 5 years of technical leadership, after which I've got a job lined up where I can get back to sitting down and writing code. The last few years have been great experience, and I have no doubt they'll make it easier to work with management types in the future through understanding the sort of decisions they're having to make, but I have no desire to play politics for the rest of my life while other people go and do the bits that motivate me to get out of bed in the morning.
  - johnnymorgan 4y ago
    I'm a sysadmin background, did CTO for 9 years and then moved to product afterwards from the knowledge I gained. Being on the other side of the fence has really helped me move around, I still to sysadmin/DevOps type work but mostly moved into product and I've found it really helps. Too many C level see product as only UI/UX and the teams I manage appreciate my understanding of the pain points for everyone

deleted 4y ago

[deleted]

29athrowaway 4y ago

Because bad organizations conflate leadership and dominance. Raw dominance is the dynamic governing primitive social animals. Chimps are a bit smarter, and would collaborate as a group to beat up alphas that they hate.

jasonm23 4y ago
Let me rephrase that. The group is smarter, than an individual's dominant strategy. They'll collaborate as a group to embarrass and undermine and quit that scene.
nix23 4y ago
Fun fact, there are nearly no Animals who life in groups with "real" alphas, especially not Wolfs, maybe you can say Elephants where the oldest (most of the time) female is the leader (however that is because she is the most knowledgeable (location of waterholes, food etc)) and not because of her Character or "i want to be a leader" mindset. There is one exception that comes to my mind with "real" Alphas and those are Gorillas.

bruce511 4y ago

Interestingly this list covers "bad manager skills". Which emphasises the point that bad managers are bad. Equally a good manager with average tech skills can do everything opposite to this list with the help of technical advice. Sure we'd all like a great tech guy who somehow is also a fantastic manager. But let's accept those are rare. Next best is a great manager (emphasis on good, not bad) who listens well and takes advice regarding pure tech matters. Over time their tech will improve (remember, good manager) but in the meantime IT flourishes. Only then comes a great tech guy with poor management skills. Frankly poor management will kill a team faster than good tech skills can save it. So yeah, as the article suggests, a great all rounder would be the best option. But I feel there aren't enough of those to go around. In that case I'll take a good manager over a good techie all day long.

hef19898 4y ago

In defence of "because I say so", it sometimes necessary. And not a big deal in my book, if the person giving the order is also owning all the outcomes, good and bad. Fully agree on everything else. Additional caveat, I have a supply chain and logistics ops background, so a completely different environment to design and development.

jon-wood 4y ago
"Because I say so" is a terrible way to communicate why a thing is being done. In senior positions it is definitely necessary now and again to pull rank and tell people something is being done despite their protests, but I don't think I've ever found a situation where I couldn't articulate why that decision had been made. People may disagree with that decision, hell, sometimes I've disagreed with the decision I'm communicating, but you owe it to your people to communicate the reasons.
- hef19898 4y ago
  Fully agree on giving reasons. And more often than not there is room to discuss them. Also, from time to time, it doesn't matter weather or not we agree with those. And then there are those moments were there is no time to discuss. Good leaders know to tell those appart, and professionals can accept it. Unfortunately, this combination, good leaders being in charge of professionals, is rarer then I'd prefer.
  - johnnymorgan 4y ago
    Too rare but when you get it, it's gold baby
    - hef19898 4y ago
      Solid, 24 carat gold.
- bluefirebrand 4y ago
  I had a situation recently where I had a report argue with me constantly over team agreement stuff like code standards and unit test coverage. I explained every piece of rationale I could come up with for why the team chose to do things the way they did. I offered to schedule team discussions for her to try and convince the team to adopt other strategies, with the understanding that if the team didn't want to do things her way that would be the end of the discussion. It wasn't the end of the discussion for her though, she kept complaining. Eventually I just had to say "that's the way we do things here so you have to get on board". It's awfully close to "because I said so", and I hated saying it, but I exhausted every other avenue I could think of. She wound up giving her notice, so I guess we were on the same page because I was working with my manager on letting her go. But if she had been able to keep her head down and do the work we would have kept her for sure. She was a good coder, good systems knowledge, just really didn't like writing unit tests I guess.

samhuk 4y ago

Adding to that list, and somewhat related to your first point: Never built anything technical of any quality. A coach that never played can't teach.

ambicapter 4y ago
Hard disagree. A good coach only needs to see the players on the field, notice the things that wins game, and figure out the way to motivate their players. Don't need to have played the game, though it helps. I'm thinking of one of the best coaches in the world, who played the sport at an unimpressive level as a teen...but at a young age he watched his father work as an assistant coach. That's where he learned his skills. As well, the requirement for "must hit X bar of quality", where X is some arbitrarily high level, is nonsensical. If they're so good at building quality products...then why aren't they doing that in the first place. Necessarily, your best builders should be builders, and your best managers...should be managers.
- samhuk 4y ago
  > notice the things that wins game > motivate their players These are made so much easier if you have "played the game" that you pretty much end up back to the original argument of it being a requirement if being "a coach" to remain competitive. There of course will be outliers to this, like your aforementioned "coach that never played", but why deliberately base your point on an outlier? > "must hit X bar of quality", where X is some arbitrarily high level Quoting myself, I said "of quality", i.e. something that is reputable and, relative to some reasonable and well-known industry standard software development principles and benchmarks, of quality. I wouldn't say it's totally arbitrary.