> I had one job where there was a lot of technical debt, but my manager did not respect me and my colleagues had what was basically a "learned helplessness" attitude. So I'd go around trying really hard to make things better, but everyone responded to me like I was just crazy or naive or didn't know what I was talking about.
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.
Any tips or lessons learned on working with the non-technical folks? This is a struggle I am dealing with and am constantly trying to improve in. They want to do things their way, which might work okay but is inefficient and not in line with the technology goals of the company. Hard to wrangle them - they run off and do things without talking to me or the people in my department, not considering the plans technology has. I've been a CTO in the past and though I am not in that role now, we don't have a CTO and I am best suited so trying my best to fill in...
Unfortunately what has worked best in practice for me is:
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.
> They want to do things their way... Hard to wrangle them
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.
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.