As CTO, you probably don't have the time and space, structurally, to be a good developer. You have things to do that aren't a single project or feature! So of course other developers will be better at "being a developer" than you, by some measures.

I've seen two successful models of CTO that are "good developers:"

1. Knows the core tech of the company really well. There's some small bit of tech at your company that's legit an enabler of your growth. You should probably know it better than anybody. Maybe it's moved or changed or grown in the last 8 years, and you've lost touch a bit? It seems reasonable to carve out time to build something on your own, in the same space, using the new stuff. You probably have a better sense of what's important to get right than anybody else, so building a personal project with that tech on company time _is_ actually a great use of time.

2. Knows the system dependencies better than anybody else. This particularly applies if you have reliability woes or other systematic issues. You have a great position to ask other teams to educate you. Get a couple good devs from each team in a room, drop your ego, and have them teach you what they know in their domain. Do this across a bunch of teams. Some folks might find this irritating, but most folks will like the time to show off their work and share their worries.

Everybody is constrained by where they spend their time. If you want to go back to being a great IC ... you need a different job. Which it might be time for! But you can be technically great as a CTO, and I'm sure I've missed some other ways you can do it in the context of you "day job."