5 ms·

1. This is what happens when there are non-technical folks in the upper-echelons of an organization. The CTO should have highly technical backgrounds and should

1. This is what happens when there are non-technical folks in the upper-echelons of an organization. The CTO should have highly technical backgrounds and should be able to do the work they’re pushing down to the rest of the engineering staff; however, oftentimes, they cannot and/or never could because their station comes from business acumen, not tech. 2. Now, there’s the other side of that where you have technical leaders who can code but cannot effectively communicate and/or make it known to other leaders why requested roadmap items are not feasible, possible, etc. This is a very common scenario where technical leaders are not great at communicating to other business leaders and making realities known. The third issue is when a technical leader draws a line in the sand and gets sacked because the rest of the leaders hate having their ‘vision’ quashed. This leads to #1 and #2, above.

passwordoops 4y ago
Agree with everything, but I wouldn't be too strict on the requirement that the CTO be able to do the work - within reason and depending on the org. They definitely have to be able to understand it and have an intelligible conversation. For example, my current place does hardware and software - CTO comes from the software side so he's not a specialist on the hardware and can't contribute directly to the electrical engineering work. But at least he knows how to ask the right questions, learn when he needs to, and got the right people under him to get the job done. And to your point, he has no formal business education and our CEO is the founder, and an electrical engineer
willcipriano 4y ago
> This is what happens when there are non-technical folks in the upper-echelons of an organization The described behavior can be found in non technical organizations as well. A room full of people will never blame itself, they will always blame someone not in the room (or failing that push someone out of the room and blame them). In group VS out group behavior[0][1]. You could tell the same story around a lemonade stand, "Looks like we are going to be busy next week, should I order more lemons?" "no, we ordered plenty", a week later "Why didn't you order more lemons!". It's not a technical problem in the slightest, or even a human nature problem, this stuff was wired in when we were early primates. [0]https://en.m.wikipedia.org/wiki/In-group_and_out-group https://en.m.wikipedia.org/wiki/In-group_and_out-group [1]https://en.m.wikipedia.org/wiki/In-group_favoritism https://en.m.wikipedia.org/wiki/In-group_favoritism
- oblio 4y ago
  This probably predates primates and it's just a standard social animal trait that's useful so is kept around. Think dogs, wolves, ants, whatever.
- asoneth 4y ago
  I used to believe this too, but I've worked in multiple organizations now where there was no shame associated with assessing who or what factors contributed to project failures. The primary desire was to understand them accurately to mitigate those same failures in the future. Ultimately it comes down to the organization's culture and whether failures are punished or accepted as a necessary side-effect of doing ambitious work.
ryanbrunner 4y ago
Another pattern I've seen is that the CTO is technical and can do the work, but all their experiences actually coding for the company is from the early days where releasing half-baked bug filled messes was the standard. As the organization grows, maturity around quality, security, reliability, etc. increase but they still have an internalized notion that the company should be able to ship product "like the old days".
- IneffablePigeon 4y ago
  Alternatively, the slight variation where even shipping good clean robust code was easier in the old days because the product was much smaller and didn't have years of accrued product and technical decisions to work around or unpick, all of which were good at the time but don't work a few years later. The "maturity makes things slower" thing can apply even if the quality of code was always good.
  - P5fRxh5kUvp2th 4y ago
    Then there's the 3rd issue, where everything has become a moat and it's just not worth the effort of trying to do a good job anymore. I've literally seen things that should take an hour be weeks because it ended up involving 10 different teams. And while you may think that's an exaggeration, it's not. software is often used to assert authority so people CAN'T even attempt to work around these issues. Paradoxically, software can actually make companies less effective.
tbrownaw 4y ago
> This is what happens when there are non-technical folks in the upper-echelons of an organization. Technical people can forget things and then try to play "shoot the messenger" just as well as non-technical people can.

passwordoops 4y ago

Agree with everything, but I wouldn't be too strict on the requirement that the CTO be able to do the work - within reason and depending on the org. They definitely have to be able to understand it and have an intelligible conversation. For example, my current place does hardware and software - CTO comes from the software side so he's not a specialist on the hardware and can't contribute directly to the electrical engineering work. But at least he knows how to ask the right questions, learn when he needs to, and got the right people under him to get the job done. And to your point, he has no formal business education and our CEO is the founder, and an electrical engineer

willcipriano 4y ago

> This is what happens when there are non-technical folks in the upper-echelons of an organization The described behavior can be found in non technical organizations as well. A room full of people will never blame itself, they will always blame someone not in the room (or failing that push someone out of the room and blame them). In group VS out group behavior[0][1]. You could tell the same story around a lemonade stand, "Looks like we are going to be busy next week, should I order more lemons?" "no, we ordered plenty", a week later "Why didn't you order more lemons!". It's not a technical problem in the slightest, or even a human nature problem, this stuff was wired in when we were early primates. [0]https://en.m.wikipedia.org/wiki/In-group_and_out-group https://en.m.wikipedia.org/wiki/In-group_and_out-group [1]https://en.m.wikipedia.org/wiki/In-group_favoritism https://en.m.wikipedia.org/wiki/In-group_favoritism

oblio 4y ago
This probably predates primates and it's just a standard social animal trait that's useful so is kept around. Think dogs, wolves, ants, whatever.
asoneth 4y ago
I used to believe this too, but I've worked in multiple organizations now where there was no shame associated with assessing who or what factors contributed to project failures. The primary desire was to understand them accurately to mitigate those same failures in the future. Ultimately it comes down to the organization's culture and whether failures are punished or accepted as a necessary side-effect of doing ambitious work.

ryanbrunner 4y ago

Another pattern I've seen is that the CTO is technical and can do the work, but all their experiences actually coding for the company is from the early days where releasing half-baked bug filled messes was the standard. As the organization grows, maturity around quality, security, reliability, etc. increase but they still have an internalized notion that the company should be able to ship product "like the old days".

IneffablePigeon 4y ago
Alternatively, the slight variation where even shipping good clean robust code was easier in the old days because the product was much smaller and didn't have years of accrued product and technical decisions to work around or unpick, all of which were good at the time but don't work a few years later. The "maturity makes things slower" thing can apply even if the quality of code was always good.
- P5fRxh5kUvp2th 4y ago
  Then there's the 3rd issue, where everything has become a moat and it's just not worth the effort of trying to do a good job anymore. I've literally seen things that should take an hour be weeks because it ended up involving 10 different teams. And while you may think that's an exaggeration, it's not. software is often used to assert authority so people CAN'T even attempt to work around these issues. Paradoxically, software can actually make companies less effective.

tbrownaw 4y ago

> This is what happens when there are non-technical folks in the upper-echelons of an organization. Technical people can forget things and then try to play "shoot the messenger" just as well as non-technical people can.