Does a CTO need to know how to code?

Times have changed. Until rel­a­tive­ly recent­ly, every decent CTO, CIO or CISO (insert C‑suite tech role of your choice) would have ‘done the knowl­edge’ and learned to hard code at some form of col­lege.

Under­stand­ing the rudi­men­ta­ry prin­ci­ples and gov­ern­ing pre­cepts that denote the core math­e­mat­i­cal mod­els, sys­tems and process­es that make soft­ware engi­neer­ing what it is, was always regard­ed as bread and but­ter for any tech­nol­o­gy man­ag­er. But that was then, and this is now.

Today we live in a world where so-called low-code and no-code plat­forms work along­side soft­ware accel­er­a­tors and AI-fuelled automa­tion tools that can take much of the repet­i­tive grunt work out of soft­ware sys­tems devel­op­ment.

We now also enjoy guid­ance from new cul­tur­al approach­es such as DevOps (a port­man­teau join­ing devel­op­ers and oper­a­tions staff), cre­at­ing more har­mo­nious work­flows. It’s worth ask­ing whether the CTO of tomor­row real­ly needs to know their JavaScript from their Java-roast caramel lat­te.

In the real world, it’s main­ly those CTOs at star­tups and small­er oper­a­tions who still spend any sig­nif­i­cant amount of time cod­ing. In many cas­es, the ven­ture itself is their brain­child, so it’s nat­ur­al for them to still be get­ting their hands dirty with the prod­uct or IT ser­vice.

“As an organ­i­sa­tion grows there is often a more iden­ti­fi­able dif­fer­ence between pro­duc­tion-qual­i­ty code which is good enough to run a busi­ness on reli­ably, ver­sus one that is per­haps more exper­i­men­tal or is at pro­to­type-lev­el,” says Priyan­ka Shar­ma, exec­u­tive direc­tor at the Cloud Native Com­put­ing Foun­da­tion.

“A CTO’s role changes at that point from a work­flow where they are cod­ing them­selves, to a new posi­tion where they are run­ning an engi­neer­ing organ­i­sa­tion at scale,” Shar­ma explains. “Through­out this pro­gres­sion, under­stand­ing the soft­ware devel­op­ment process and hav­ing empa­thy for its nuances and chal­lenges is essen­tial to a CTO’s suc­cess.”

From her exten­sive expe­ri­ence of work­ing with enter­prise plat­form com­pa­nies – many of which have expe­ri­enced extreme­ly rapid peri­ods of adop­tion and growth – Shar­ma says that a CTO who is not able to at least be ‘walked through’ code by an engi­neer may risk los­ing cred­i­bil­i­ty in the longer term.

“What all this means is that, regard­less of a company’s stage of evo­lu­tion or growth, the CTO must have a tech­ni­cal back­ground. But this doesn’t mean they need to come from a con­ven­tion­al com­put­er sci­ence edu­ca­tion. Some of the best tech­nol­o­gists in the cloud-native world are self-taught, and some even come from clas­sics and art back­grounds. Any­one can learn to be a tech­nol­o­gist today,” she says.

Technology’s con­tin­u­al evo­lu­tion means that CTOs must keep more than just a hand in. For exam­ple, one of this year’s hottest IT indus­try trends is Infra­struc­ture-as-Code, the move to pro­vide low­er sys­tem IT resources as soft­ware-defined cloud ser­vices. A CTO would be well advised to keep up with the engi­neer­ing pre­cepts that under­pin high­ly tech­ni­cal con­cepts such as abstract­ed load-bal­ancer func­tions and all the asso­ci­at­ed plat­form mechan­ics.

At the very least, this aware­ness could make lunchtime cafe­te­ria dis­cus­sions less painful. At best, it means the busi­ness can steer its IT func­tion with a cap­tain who knows where the gauges are in the engine room. The CTO may not always know how to cre­ate the right fuel mix­ture, but they will know which fur­nace is doing what.

Of course, there are coun­ter­ar­gu­ments. Many think the CTO’s role should evolve to become a kind of over­see­ing evan­ge­list for best prac­tice and pro­gres­sive work method­olo­gies. In a world where soft­ware engi­neer­ing is increas­ing­ly pre-pack­aged, some say the mod­ern CTO is no longer a fin­gers-on-key­board job and they should resign them­selves to being strate­gic archi­tects not stone­ma­sons.

“Being a CTO is hard. The role demands rock-sol­id tech­nol­o­gy skills along­side strat­e­gy and peo­ple skills,” says Dr Hol­ly Cum­mins, senior prin­ci­pal soft­ware engi­neer at cloud ser­vices provider Red Hat. “That’s a lot to fit in one head, so some­thing has to get pushed out. Usu­al­ly what goes is a focus on low-lev­el details. Code is increas­ing­ly one of those details.”

Cum­mins says that while the CTO may not be writ­ing or review­ing actu­al lines of code these days, they should be ask­ing high­er-lev­el ques­tions that focus not just on the qual­i­ty of the code and work, but also of the team behind it.

For exam­ple, how con­fi­dent are we that this works? How do we test it? How much can we auto­mate? How long does it take us to get from a fea­ture request to pro­duc­tion? What are the trade-offs in this solu­tion? Are engi­neers work­ing in our code­base hap­py and ener­gised? How does our stack affect our abil­i­ty to recruit tal­ent?

“Some of an organisation’s code will be arti­sanal and impor­tant, but oth­er ele­ments will be com­modi­tised and gen­er­at­ed from AI cod­ing tools like GitHub’s CoPi­lot or copied and past­ed from knowl­edge-shar­ing plat­forms like Stack­Over­flow,” says Cum­mins. “The key to know­ing whether code should be reviewed at any lev­el by a CTO is ask­ing the right ques­tions first.”

Of course, the shift to cloud and automa­tion affects how a swathe of mod­ern soft­ware appli­ca­tion devel­op­ment is car­ried out today. We live in a world where soft­ware pro­gram­mers use an increas­ing amount of automa­tion and code accel­er­a­tion tech­nolo­gies to per­form their jobs faster. There is a direct impli­ca­tion for the C‑suite.

“In a very real sense, the role of the CTO in so many mod­ern appli­ca­tion deploy­ment envi­ron­ments is mov­ing from a posi­tion of raw mate­ri­als mak­er and cre­ator to one of intel­li­gent orches­tra­tor,” says Prakash Vyas, head of port­fo­lio mar­ket­ing at mod­ern enter­prise appli­ca­tion plat­form com­pa­ny Out­Sys­tems.

As we enter an era with soft­ware tools designed to make tasks sim­pler, faster and more accu­rate, Vyas says CTOs need to look at the big pic­ture. This must ensure the soft­ware plat­forms their busi­ness uses offer the pow­er to per­son­alise, mod­i­fy and extend a giv­en set of enter­prise appli­ca­tions based on what can be sig­nif­i­cant­ly dis­rup­tive forces, as we are all now aware.

“Does that mean CTOs need to just man­age and orches­trate and nev­er code again? Even from my point of view as a low-code purist, I would say gen­er­al­ly no,” says Vyas. “We don’t want CTOs or new­bie pro­gram­mers hav­ing to do all the heavy-lift­ing tasks if an appli­ca­tion or enter­prise IT ser­vice needs some seri­ous refac­tor­ing and rebuild­ing, but we do need all stake­hold­ers in the tech func­tion to know where the spark plugs go.”

So, does the mod­ern CTO still need to know how to code? The answer appears to be yes, but they prob­a­bly shouldn’t be head down at the key­board lead­ing the code cre­ation process on the first day of a project.

Nobody wants an over-sea­soned foot­ball play­er on the pitch when they real­ly should be a mem­ber of the coach­ing and man­age­ment staff by now. It’s the same for CTOs. They need to know where the goals are, how to build team for­ma­tion and when to send the sub­sti­tutes on. They should even know how to kick the ball and how to deal with an unruly tack­le. Just don’t ever let them take a penal­ty.