IMHO they ought to have a developer background. That doesn't mean they need to be an expert in DBMS design or whatever, but they should know enough to know when one of their reports is talking BS.

I once worked for a CTO who threw out all our Linux systems and replaced them with Solaris (early 2000s) because "Linux couldn't scale", at the behest of our database architect who was basically just trying to increase his own empire and budget. One of the stupidest and most costly decisions, that also demoralised the rest of the team.

My expectation as a lead-role in DevOps is that my CTO understands what I am saying, if I were to present a business case to him for evaluation or raise a concern with the company tool stack. Shortly put I want somebody with decision making powers to also have the knowledge to make those decisions. I don't need them to be able to implement any of the changes, but I need them to be able to know why the change needs to happen and what business value it does or does not give.