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.