[angersock]

So, this actually reminds me of a super sore point, and so a quick Angersock PSA:

Hey! Hey you! New founding CTO!

If somebody on your team comes to you with a technical improvement, support them. Ask what they need, setup dedicated work time (not some after-hours exploitation) to explore the idea, have the present, pay attention, and generally act like you give a damn about the quality of your codebase.

You don't have to promise to roll out the hottest new Reactular ES9 framework immediately, or even that you'll assign other engineering resources to it. You don't have to say "let's refit everything". You certainly don't have to take such suggestions on faith.

But you can do so much damage to your team, especially your early engineers, by being negative and conservative and saying "no" or "not yet" to everything.

Don't fuck this up.

Also, never say no just because you don't understand the new tech or language. Your job, as the chief technology officer, is to be constantly on the bleeding edge--even if you don't use that in production.

If you say no because you're uncomfortable learning or because it might mean the team may have to learn some new things, you are being lazy at your job and your displaying mistrust in your team.

[eropple]

Best PSA in a while. I left a job once largely out of friction with the top decision-maker (not actually the CTO, a director-level, but functionally the same thing) where there was tons of fear around well-established technologies that the decision-maker had never gotten around to learning and pretty obviously didn't trust that we had a handle on it. The visible lack of trust led to defensiveness all around (us because we weren't feeling trusted, him because he thought we thought he was dumb), and nobody who championed those ideas were there six months later and the company's tech-debt hole had only grown deeper.

[lawnchair_larry]

Your PSA comes from the perspective of a smart employee with good ideas falling on deaf ears with the dumb CTO.

What of the good CTOs who have mediocre teams with a lot of bad ideas that are poorly thought out?

Note: if you answer with something like "CTO should quit", "CTO should fire them", you fail this question.

[steventhedev]

In the case of a truly bad idea, it is the duty of the CTO/VP Eng/Team lead to give the employee the time to explore the idea/discuss it and realize why it's a bad idea. The employee should grow as a result of the experience, and become more valuable in the future.

On the off chance they don't learn, and the situation repeats itself, it may be prudent to refuse such requests.

That having been said, the worst situation is when the boss agrees that it needs to get done, but can't find where to sneak it into the schedule. It's effectively saying that you don't value the happiness of your employees and can't schedule/push hard enough.

[angersock]

If the CTO doesn't respect the team ("they're mediocre"), that's a problem. CTO needs to accept the materials at hand, and build a framework for growing those employees and protecting them from their own ingenuity--if the "right way" of doing something is so much easier than the alternative, and its practice is explained and documented, then the rest should see to itself.

That conservative policy still leaves room for explaining why a given bad idea is bad, or for exploring that idea for like a workday or two so the employee can figure out why it's bad.

If after all this the CTO is still besieged by idiots, they should leave...either because they have failed their team, or because the team is deadset against succeeding.