Software quality is too important to be left to your CTO (or the art of shooting yourself in the foot)
Fellow CEOs, let’s lay it out:
-
You run a company that sells software or relies heavily on it;
-
You notice or suspect quality issues (bugs, sharp increases in timelines or costs, a wave of resignations);
-
And above all, your expertise isn’t in IT.
Naturally, you talk it over with your CTO and try to get to the bottom of it. If there are bugs, it means there are gaps in the application testing. You think a technical coach (“Craft” coach) might be able to help. Unless it’s an agility issue, in which case you suggest they bring in an agility coach. In any case, you decide to allocate additional funding to the tech team, hoping for a return on investment soon 🤞
Congratulations—you’ve just shot yourself in the foot, because you’ve ruled out addressing 70% of the causes of poor software quality right from the start.
Why?
-
Because Agility is a functional issue before it is a technical one: most bugs stem from the fact that the functional design was rushed—if it was done at all. Most of the money thrown away is due to having happily worked for 12 months on unverified assumptions (tunnel vision).
-
Because Agility is a corporate issue: an “agile” IT team operating like a Gallic village within a non-agile company simply won’t work. If strategic decisions are made by a committee that meets once a month, it’s doomed—the friction between that team and the rest of the company will be too great.
-
Because the problem is most often organizational: treating IT as a cost center is shooting yourself in the foot, again; setting up an Acceptance Testing team to handle testing your IT assets is shooting yourself in the foot; setting up a DevOps team is a contradiction in terms and is yet another way of shooting yourself in the foot. I could give countless more examples, but there haven’t been enough feet left for a long time…
-
Because IT is all about people, and sometimes the CTO himself or herself is the one who needs to be addressed. You’ll agree with me that a consultant working under the CTO’s direction isn’t really incentivized to contradict him or her, even though their ethics would dictate otherwise.
So, yes, there are always technical issues; there are always things to improve and refine. But development itself is rarely the heart of the matter. Also, if the consultant wants the freedom to address the root causes of the problems, it is essential that they receive their mandate from the company’s CEO—not from the CTO.
This, in fact, is the mistake that all “technical” coaches—and even “agile” coaches—make: they focus on the means rather than the end goal, which is software quality.