What I'm about to say may be considered harsh, but I promise I don't mean it to be.
Quit. Just leave. Go back to coding. It's obvious you don't enjoy management, there's no shame in admitting that. Rather than inflict your misery on the rest of the team, get back to your wheelhouse where you can be happy, your team can be happy, and ultimately your company (current or future) can be happy.
I have worked in a job where the CTO (my boss) was in your exact position (in fact, if it weren't for your style of writing - English was very obviously his third or fourth language - I would almost bet money that you were him, your stories are that eerily similar) and it was a miserable experience. $CTO was an otherwise brilliant coder who was on his first cto-gig outside of 'team leader'. Outside of work, he was a great guy - warm, personable, funny. At work, he resented not being able to code in many different ways, often with the team bearing the brunt of his misery. He'd often make decisions for others to implement, then second (or third) guess himself days or weeks later, insist we throw out all the work, and start again. He'd often be irritable, make rash decisions, have temper flare-ups, ask for feedback then get upset when he got it, etc. It was a bad scene for all involved, but the dude was a walking personification of the Peter Principle. He would have been infinitely happier remaining a coder, and his team (myself included) would have been infinitely happier with a CTO comfortable in a leadership position.
Thank you for this, it's the way my mind has been leaning but it's good to hear. I realize my original post makes it sound like I had no idea what being a senior manager might involve which is just not true. I understand a lot of fire fighting and dealing with problems is par for the course I just didn't know if I'd enjoy doing that or not. How are you supposed to know until you try? :)
I also felt like I'd have way more control than I currently do. Perhaps that is a problem with me and if I simply took control and treated it like my own business I could change things enough to suit me more. But is that a good decision for the business? I'm not so sure. What's the point in changing things so much that the business suffers?
Anyway, your points about your previous boss really resonate with me right now. I'm finding myself increasingly frustrated and dreading meetings because I feel that frustration is coming across to the rest of the team.
The fire-fighting thing sticks out to me a bit, in part because it's caused me pain in the past and in part because you keep mentioning it. I might venture a guess that one of the underlying issues that's really getting to you is not the lack of actually writing code, per se, but that you have always had environments where you can get lost in deep focus or flow, and now your brain is being actively rewired to support continual rapid context switching. This is uncomfortable and unfamiliar and your brain is rebelling against this new environment.
I've never had a CTO title, but I've been in many similar positions.
In case you decide to stick it out for a while, I would suggest several easily implemented opportunities immediately:
(1) Establish an #engineering-support channel in Slack and a Triage calendar in Google Calendar. Put your team members on a rotating schedule to triage any engineering fires that the business has.
The Calendar should pipe into the Slack channel at 9 am every day. For a few weeks, send an "@channel please remember $engineer is your point of contact for today." By then the rest of the business should get the idea. Instruct your team that you trust them to decide which issues need to be addressed immediately and which ones need to go into the queue, but if they have any questions they can escalate to you. Also explain you understand that context switches are expensive, and you are totally okay if this causes a productivity hit on their given triage day.
It doesn't mean you won't be interrupted with real fires, but it does keep the less urgent ones from creating a context switch for you. Include yourself in the schedule, and you can send the message to your team "we're all in this together" instead of "hey I'm too good for this nonsense."
(2) The Business guys will respect your calendar, and if they don't, you have leverage to call them out on it because The Calendar is sacred in the business world. Block out 2 or 3 hour chunks throughout your week to work on hard problems. You drive a lot more value this way than with the fire fighting, anyway.
(3) The Calendar also works for time with your family. Daughter's Ballerina Recital? Block out 4pm-8pm on your calendar as soon as your hear about it—"Blocked—At Home"—and again, leverage if somebody wants to interrupt you with a fire.
(4) Train everyone on how to add each others' calendar to their own calendar view; this seems obvious to engineering, but less engineering-minded people may not know they can do that.
Before you quit, you should consider using your willingness to quit as leverage to try to improve the situation. This is not an easy thing to do, but if it succeeds it can pay enormous dividends down the line, and you have little to lose by trying it first. Contact me privately if you'd like more info or coaching on this. (My qualifications: I've been CTO of two semi-dysfunctional startups.)
A manager should set the course, provide the means and assist in navigating the rough patches, but they shouldn't be at the helm shouting instructions at the people climbing the sails. A manager who tries to take control typically leads to frustration for everyone involved.
Here's the problem with that reasoning. As OP implies she has enjoyed leading/managing within her own companies. Before my company was acquired it was thrilling to perform these duties even though it was more grueling. So it's not necessarily a matter of not being cut out for that kind of work.
You know, maybe it makes me sound bad but I do enjoy leadership on a smaller scale and where I am ultimately in control. I know one-man bands don't get very far (usually) and some people management is expected even in your own business.
I guess my point here is that yes, you're right I have enjoyed leadership previously and thought the step up would be similar but it's not.
I read it more as the OP had their own company where they were in charge of making decisions AND executing them, and there's no real indication of managing employees. I suspect they enjoyed the execution. If they don't enjoy dealing with people's crap and putting out fires, senior management of any reasonably large group is probably not for them - and that's absolutely okay.
Right, I wonder if this person ever understood what the job of CTO is. Yes it's "dealing with everyone's crap", it's a management position. Yes you haven't written code in months, it is a management position.
Quit. Just leave. Go back to coding. It's obvious you don't enjoy management, there's no shame in admitting that. Rather than inflict your misery on the rest of the team, get back to your wheelhouse where you can be happy, your team can be happy, and ultimately your company (current or future) can be happy.
I have worked in a job where the CTO (my boss) was in your exact position (in fact, if it weren't for your style of writing - English was very obviously his third or fourth language - I would almost bet money that you were him, your stories are that eerily similar) and it was a miserable experience. $CTO was an otherwise brilliant coder who was on his first cto-gig outside of 'team leader'. Outside of work, he was a great guy - warm, personable, funny. At work, he resented not being able to code in many different ways, often with the team bearing the brunt of his misery. He'd often make decisions for others to implement, then second (or third) guess himself days or weeks later, insist we throw out all the work, and start again. He'd often be irritable, make rash decisions, have temper flare-ups, ask for feedback then get upset when he got it, etc. It was a bad scene for all involved, but the dude was a walking personification of the Peter Principle. He would have been infinitely happier remaining a coder, and his team (myself included) would have been infinitely happier with a CTO comfortable in a leadership position.