> Where can you find time to create this demo? You'll want buy-in from your supervisor (if they're a good one hopefully they'll encourage you!) Otherwise (to steal a line from Hunter S. Thompson), I hate to advocate nights and weekends, but they've always worked for me. (I do understand this isn't how it works for everyone...)
Having to work nights and weekends to build a working prototype to get in-house buy-in on new functionality makes little sense to me. If your team cannot work together well enough to agree on new features without them being built first then perhaps the issue isn't feature adoption.
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.
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.
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.
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.
