There is a lot of good content and information in here... but... hoooooo boy... are there some major inaccuracies, overly broad generalizations, and really bad assumptions too.
For example, a CTO is a *leader* and a *manager* and while they should be technical and have a technical background, I absolutely do not expect them to have a strong or current working knowledge of hands on stuff. It takes someone years to become a competent developer, or data scientist, or security engineer, or whatever, right? Guess what, it takes *just as long* to become a competent manager too. It's a skill like everything else. Every day that CTO candidate is spending messing with ML models is a day they aren't learning to do a good job at being a CTO... managing people, making decisions, being a *leader*. Are you hiring a CTO or are you hiring a chief data scientist? Not the same job.
At *ton* of companies, directors have virtually no control over budgetary matters, never mind using them to make technical decisions. Your statements that "almost all companies" do this is just false. I can tell you that at virtually no company I have ever worked at was this true. That said, for the kind of role you are talking about (which is also not a universally correct view of the Director+ roles out there... not even close), that kind of background is critical! But to say that someone is a pretender without this experience requires an extremely myopic view of things.
Only in the largest of companies does someone below the VP or even CEO/COO level negotiate a contract. I have been at Fortune 500's where only about 10, 20 people (outside of sales/marketing) could sign off on something bigger than buying the team lunch or traveling to a client site. In fact, in my current position, where I am regularly part of $1m+ deals, it is very clear that very few of the people involved on the client side have much experience at all in vendor selection, and only then it is at very large companies.
Finally, I feel fairly certain from reading this that you are speaking from the viewpoint of a company building product (you talk about CACs for example), and building internal use stuff is so radically different in soooo many ways. For example, internal projects often prefer strong definitions of "done" rather than Agile methodologies for a number of reasons - some valid, some not-so-valid - and much of the lessons you discuss here don't apply so well in Waterfall or Agilefall places. Does that mean that you should bring them into an Agile style org? Not unless you are sure they will adapt and fit in without issue. But you would reject them out of hand.
Much of what you are saying here is basically "never hire someone unless they look like the person who left" kind of thinking. And unfortunately, unlike, say, data scientist or software developer, there isn't a real training system or path for management, other than MBA programs (which don't impress me for a technical manager). For a technical manager, you need someone who came up through the ranks, then made the jump to management and when you do that jump, there is only on-the-job-learning (not even training...). You stumble and fall - a LOT - until you figure it out. Most management candidates are going to have some big gaps in their skill sets as a result. You seem to be expecting a very unicorn-ish candidate, and maybe in your job market enough of them exist (even then, you interviewed 35 people just to hire a single director, which tells me that your pre-interview pipeline was likely 100+... and I have to wonder what the screening was like that you went through 35 people who got through screening to find a single person to hire?), but in a ton of other job markets or niches or industries, there just isn't that person. For example, in my mid-sized city, there are maybe MAYBE a few dozen people with my level of experience running a development organization in professional services. If any of them need to hire, they don't have many options! In my small slice of the industry, there is literally no one on the continent of North America with my depth of knowledge, there are around ten folks in Europe with my specific skill set (we are a small group and we all talk to each other and know each other). Not that I am irreplaceable (no one is!), but if my employer wanted to fill my shoes with someone like me, they would either need to spend a fortune bringing someone from overseas, or they would need to accept a compromise candidate without my specific blend of technical skills in a narrow niche development tool and my experience managing people.
That's just a sampling of the deep problems in this piece.
Like I said... lots of good ideas and information here, and in many ways I would write something similar if I didn't keep my Medium hyper-focused on a very specific technical niche. But you really need to be careful in translating your narrow experiences into broad "thou shalts", "all companies", etc. style statements across the entire industry. Context is very important! And you didn't even introduce your context, which makes it even harder to judge what is applicable and what isn't.
J.Ja
