Best of luck from someone who's been there! With hindsight you'll be able to draw lessons for self improvement, and also realize just how much really was the fault of your environment, with nothing you could have done differently. Just take some time for yourself and learn what you can, and what to avoid in the future.

The company itself is great. All of the feedback I receive is very respectful and understanding, it still just eats at me though. We're even working on a plan to address some of the tech debt/complexity in 2022.

I think my self-doubt is just being on a podium at work teamed up with being burnt out. Maybe an extended vacation is really what I need to do.

100% adding a +1 here that this sounds like the right thing to do to start.

> it still just eats at me though

To me, this stands out. I think it's important to answer the "why" here at some point, whether that be before/during/after an extended break. Some potential things to investigate:

- Maybe the company is respectful, but the environment is still too critical / focused on bettering code constantly rather than focusing on product.

- Maybe there's too much focus on code quality over product generally, to the point that it's not helpful.

- Maybe it's not actually as respectful and understanding as you originally thought.

- Maybe the way it's delivered works for others but you need a different format and can communicate that need to others.

- Maybe the feedback coming from people below you (reading into "on a podium") is different than from peers and you're internalizing it.

Whatever it is, I hope a break helps you reset and gives you space to figure it out!

Although my management and business skills were continuing to improve (and, I think, got to be quite strong), the loss of my technical competence did bother me. I ended up leaving and now I'm working as a CTO but with no team - more of an individual contributor, at a senior level in the company. I write code every day and over the past year my technical skills have mostly returned, and I've gotten to learn all sorts of exciting new stuff.

With that said, one of the biggest things I've learned is that, once you know how to write software, it's not that hard to get back into it. Learning Typescript has been straightforward. VS Code is a joy to use, but hey, Xcode was pretty great too. If having strong technical skills is important to you, then you have to change your focus and get back into it. But know that you can do this any time you want. On the other hand, if you value the skills of people management, reporting to a board, managing investments, etc., those are things that are hard AND valuable.

At the end of the day it's just about choices, you can't be great at everything. Good luck!

This is the sad truth at way too many orgs, even YC funded ones. Several times I have come in as a "highly respected CTO", and the things I end up doing that work are simply the same things the previous CTO was trying to do, but he/she wasn't able to get buy-in because of lack of respect from the non-technical parts of the org. Aggregating respect unfortunately goes a very long way.

1) Curate your resume and experience for years so that people will take your opinion very seriously (whether you deserve it or not)

2) When you know something is going to fail, call it out in advance with stakeholders and do whatever you can to pump the breaks and/or change course. If you have a lot of respect, you can use this to force an uncomfortable decision that someone without much respect might not have been able to push through.

3) Be VERY insistent in pushing your proposed mitigations when you know something is going to fail and know what will fix it. If you're sure, stake your career on it.

4) When people don't listen, and things fail because they didn't listen, in yearly review / feedback type things say "if only I had pushed harder for X, then Y might have been prevented" which is a nice way of saying "should have listened to me". Eventually everyone will just listen to you in the first place.

5) If you see the writing on the wall and no one is listening to you, exit while conditions are still favorable (I never actually do this, but I probably should).

6) When you are wrong, take responsibility, but only for the parts that are actually your fault. In reality the surface area of any one person's portion of blame in most situations is quite small anyway. Most decisions in orgs can be traced back to at least 4 people.

7) Make accurate predictions of failure if we don't take X course. When these come to fruition, you called it, when they don't, you still come off as very prepared for anything.

At the department level. Split them by probing for rifts between departments. Prioritize one group's project over another. Use department lack progress as dirt on that side's leadership. Get leader replaced and bring friendly face. Now both sides are friendly and open to better policies.

As a manager pretending to be CTO let them do what they want or you will be seen as the problem. Look for power shifts between departments and ally with the correct side. If your company wanted a strong CTO they would have hired or promoted someone. If you want to be in a position to be a strong CTO make powerful friends or get promoted and gather experience and win some awards.

This can happen when the software group is seen as incapable, unresponsive, or even just slower than "business speed". I'd suggest talking to the individuals and their leadership (separately) to learn more about why they adopted X without talking to your department. You may well uncover missing or broken lines of communication, entrenched negative expectations ("it takes a month to get a simple DB query run, why would anything else be faster?"), and/or find processes so onerous that everyone tries to avoid them.

I think the "sense that you can change things", for which positivity is required, is the single most valuable asset that a company/team/whatever can have.

I think moving away makes more sense personally.

I'm in a non IT position right now and everybody is so stuck in the swamp everything is a 'no'. It now devolved into neverending politics. Mail fights and delays. A weird kind of bore and burn out.

Heh, the job I just left had a team like this.

I'd bring up ideas _for discussion_ all the time, at the very least to make my team members reconsider how we handle certain things. Even if my idea weren't the accepted one, we really had good reasons to improve our status quo. Yet just like what happened for you, when I'd call out some issue or situation the response from the team was that I misunderstood something or was crazy or etc. It gave me a lot of self-doubt, but I'd also bring up the issues to a senior engineer and he'd agree that usually my topics were worthy of at least some discussion since they had the potential to become improvements.

Those that didn't have to work for it sit back and enjoy the paycheck while getting by with the minimum amount of work. To everyone involved work can just be a free payday, if the product fails they'll move elsewhere. Or if the product is too big to fail it's guaranteed anyways. Actual engineers are a rarity, and these companies don't like them because they point out how management has been milking the project.