CTO and developer separate into distinct roles as a company grows.
How big is this company?
Is it a small company with few developers where you hold the CTO title because you're a founding developer or the most senior developer? If so, you might be missing the reassurance that came from your previous life where you had a manager to check your work, peers to review it, and feedback from people who didn't report to you:
> When I look at a new feature I just think that I will make it shitty or get called out on not doing things the "right" way.
At a startup, the "right" way isn't necessarily the most textbook-perfect code. The right way is getting features shipped as soon as possible with the code being good enough to be understandable, stable, and maintainable. You need to be careful about spiraling into decision paralysis or drawn out refactor iterations and instead focus more on shipping features to users, focusing effort where it matters for the business, and avoiding unnecessary complication in search of perfection. Perfectionism will kill startups slowly.
If you're the CTO of a big company with many developers reporting to you, then it's time to start letting go of the developer responsibilities. Trying to manage the code too closely or trying to insert yourself into the development teams that you're supposed to be managing doesn't work at scale. Focus on the bigger picture: Driving objectives, mentoring developers, hiring, monitoring output, and other leadership roles. Don't let a desire to control the code interfere with your management duties.
The company is growing in all facets. We added 17 engineers this year when we previously had a total team of like 10.
You hit the nail on the head though, I got the role because I was the first engineer and employee at the company. In no way am I a great CTO, just lucky timing.
I'm actually stepping down as CTO and becoming a developer again because I am not a good manager, that I know for sure.
I think I need to be better about getting over perfectionism. I think I let it haunt me that everyone looks up to me with my title as if I should be the best when I am very much not. Thanks for the thoughts here, I really need to reflect on this some more.
I would similarly commend you for the awareness and bravery to step down, but I would offer two notes here:
> In no way am I a great CTO
> I am not a good manager
It sounds to me like one core thing you learned is that good developer != good manager != good CTO. With that said, all three skills are different, but improved in the same way. Practice and with focused attention. It sounds to me like you were still focused on development and never really gave yourself a chance to develop those management and CTO skills.
It may still be the right call to step down, but I would at least consider trying to shift your focus to the other skills instead of development, if a leadership role is of any interest to you long term. You could also step down to a manager role so you can focus on one of the two at a time. If the learning here is that you actually don't want to focus on those skills over development, then nevermind this for the most part :)
You likely know what is best for you, but let me offer the counter argument. Your company's dev resources are growing. You are questioning yourself as a developer. You probably know more about your company's stack than anyone. You are CTO.
I don't know what you want for your future, but many of us have transitioned from dev roles to management. If you are going to be an engineer long-term, then stepping down from CTO may make sense. However, if in the next 5-10 years you want to become "management" then you are going to have to learn how to manage people. You are going to develop less. Your team should be better at developing than you are.
If you eventually want to manage, you will have to learn the skills. So why not focus on getting better at CTO now? You'll be 5-10 years ahead of where you'd otherwise be. CTO roles don't come around every day.
When I first saw your post, my reaction was: CTO after only 4 years of work experience? I've been coding for 30 years now, working for 20, and only in the last 5-6 years have I felt capable of playing that role.
Kudos that you've taken that decision - it's a good one. You can take the time to really broaden your horizons. At which point I very much expect that you'll go back, but as someone who earned the respect, not someone who needs to demand it.
It sounds like if you were to stay on as CTO you should consider delegating some more of the management, not just the tech. Who in your team can step up to support you? A CTO with 20+ people should be doing low-touch development if at all.
No harm to step down or out for a bit and come back to it when you're ready if you're burned out. Rotating the management and developer duties might reduce your pressure if it makes you feel you've got more back up.
Consider pair programming if you're doubting yourself, maybe with both weaker and stronger developers to help benchmark your skills more accurately.
External training or mentorship might help you to get another perspective on your skillset.
Also consider whether there are any external factors such as your upstream management, clients, or the market that you are in that are stressing you out. It may be that the worries about development skills are symptoms of another issue.
As a senior team member, you should have a lot of scope to choose the work that you think is the best fit for you. Taking some time to think about this is part of being a manager, and as a senior developer your development skills are not something you need to worry about too much - you can bring these up quickly if you need to, and you probably don't need to right now. You've gone through a stage of worrying about what you can bring technically to the table, and that's not your focus right now, which feels uncomfortable. It's OK to follow the flow of your career and see what happens, you can reset down the line if needed.
That is a courageous choice as others have said. You are ultimately doing the right thing for yourself and others. There is possibly an opportunity in the transition if you are staying with the company to set yourself up with some dev work that will let you recover. Depending on circumstances, a passive handover puts you at risk of landing in an awkward spot.
That sounds like a good decision. I would greatly respect someone that I saw making this call, far more than if they tried to struggle through and did damage to their own careers or others. Best of luck to you.
>I'm actually stepping down as CTO and becoming a developer again because I am not a good manager, that I know for sure.
My suggestion is, DON'T.
Please see my other comment in this thread for some suggestions. Opportunities like this do not come often and it is a mistake to give up what you have achieved without a great deal of deliberate thought.
How big is this company?
Is it a small company with few developers where you hold the CTO title because you're a founding developer or the most senior developer? If so, you might be missing the reassurance that came from your previous life where you had a manager to check your work, peers to review it, and feedback from people who didn't report to you:
> When I look at a new feature I just think that I will make it shitty or get called out on not doing things the "right" way.
At a startup, the "right" way isn't necessarily the most textbook-perfect code. The right way is getting features shipped as soon as possible with the code being good enough to be understandable, stable, and maintainable. You need to be careful about spiraling into decision paralysis or drawn out refactor iterations and instead focus more on shipping features to users, focusing effort where it matters for the business, and avoiding unnecessary complication in search of perfection. Perfectionism will kill startups slowly.
If you're the CTO of a big company with many developers reporting to you, then it's time to start letting go of the developer responsibilities. Trying to manage the code too closely or trying to insert yourself into the development teams that you're supposed to be managing doesn't work at scale. Focus on the bigger picture: Driving objectives, mentoring developers, hiring, monitoring output, and other leadership roles. Don't let a desire to control the code interfere with your management duties.