Times have changed. Until relatively recently, every decent CTO, CIO or CISO (insert C-suite tech role of your choice) would have ‘done the knowledge’ and learned to hard code at some form of college.
Understanding the rudimentary principles and governing precepts that denote the core mathematical models, systems and processes that make software engineering what it is, was always regarded as bread and butter for any technology manager. But that was then, and this is now.
Today we live in a world where so-called low-code and no-code platforms work alongside software accelerators and AI-fuelled automation tools that can take much of the repetitive grunt work out of software systems development.
We now also enjoy guidance from new cultural approaches such as DevOps (a portmanteau joining developers and operations staff), creating more harmonious workflows. It’s worth asking whether the CTO of tomorrow really needs to know their JavaScript from their Java-roast caramel latte.
In the real world, it’s mainly those CTOs at startups and smaller operations who still spend any significant amount of time coding. In many cases, the venture itself is their brainchild, so it’s natural for them to still be getting their hands dirty with the product or IT service.
“As an organisation grows there is often a more identifiable difference between production-quality code which is good enough to run a business on reliably, versus one that is perhaps more experimental or is at prototype-level,” says Priyanka Sharma, executive director at the Cloud Native Computing Foundation.
Being a CTO is hard. The role demands rock-solid technology skills alongside strategy and people skills. That’s a lot to fit in one head
“A CTO’s role changes at that point from a workflow where they are coding themselves, to a new position where they are running an engineering organisation at scale,” Sharma explains. “Throughout this progression, understanding the software development process and having empathy for its nuances and challenges is essential to a CTO’s success.”
From her extensive experience of working with enterprise platform companies – many of which have experienced extremely rapid periods of adoption and growth – Sharma says that a CTO who is not able to at least be ‘walked through’ code by an engineer may risk losing credibility in the longer term.
“What all this means is that, regardless of a company’s stage of evolution or growth, the CTO must have a technical background. But this doesn’t mean they need to come from a conventional computer science education. Some of the best technologists in the cloud-native world are self-taught, and some even come from classics and art backgrounds. Anyone can learn to be a technologist today,” she says.
Technology’s continual evolution means that CTOs must keep more than just a hand in. For example, one of this year’s hottest IT industry trends is Infrastructure-as-Code, the move to provide lower system IT resources as software-defined cloud services. A CTO would be well advised to keep up with the engineering precepts that underpin highly technical concepts such as abstracted load-balancer functions and all the associated platform mechanics.
At the very least, this awareness could make lunchtime cafeteria discussions less painful. At best, it means the business can steer its IT function with a captain who knows where the gauges are in the engine room. The CTO may not always know how to create the right fuel mixture, but they will know which furnace is doing what.
Of course, there are counterarguments. Many think the CTO’s role should evolve to become a kind of overseeing evangelist for best practice and progressive work methodologies. In a world where software engineering is increasingly pre-packaged, some say the modern CTO is no longer a fingers-on-keyboard job and they should resign themselves to being strategic architects not stonemasons.
“Being a CTO is hard. The role demands rock-solid technology skills alongside strategy and people skills,” says Dr Holly Cummins, senior principal software engineer at cloud services provider Red Hat. “That’s a lot to fit in one head, so something has to get pushed out. Usually what goes is a focus on low-level details. Code is increasingly one of those details.”
Cummins says that while the CTO may not be writing or reviewing actual lines of code these days, they should be asking higher-level questions that focus not just on the quality of the code and work, but also of the team behind it.
For example, how confident are we that this works? How do we test it? How much can we automate? How long does it take us to get from a feature request to production? What are the trade-offs in this solution? Are engineers working in our codebase happy and energised? How does our stack affect our ability to recruit talent?
“Some of an organisation’s code will be artisanal and important, but other elements will be commoditised and generated from AI coding tools like GitHub’s CoPilot or copied and pasted from knowledge-sharing platforms like StackOverflow,” says Cummins. “The key to knowing whether code should be reviewed at any level by a CTO is asking the right questions first.”
The CTO must have a technical background. But this does not mean they need to come from a conventional computer science education
Of course, the shift to cloud and automation affects how a swathe of modern software application development is carried out today. We live in a world where software programmers use an increasing amount of automation and code acceleration technologies to perform their jobs faster. There is a direct implication for the C-suite.
“In a very real sense, the role of the CTO in so many modern application deployment environments is moving from a position of raw materials maker and creator to one of intelligent orchestrator,” says Prakash Vyas, head of portfolio marketing at modern enterprise application platform company OutSystems.
As we enter an era with software tools designed to make tasks simpler, faster and more accurate, Vyas says CTOs need to look at the big picture. This must ensure the software platforms their business uses offer the power to personalise, modify and extend a given set of enterprise applications based on what can be significantly disruptive forces, as we are all now aware.
“Does that mean CTOs need to just manage and orchestrate and never code again? Even from my point of view as a low-code purist, I would say generally no,” says Vyas. “We don’t want CTOs or newbie programmers having to do all the heavy-lifting tasks if an application or enterprise IT service needs some serious refactoring and rebuilding, but we do need all stakeholders in the tech function to know where the spark plugs go.”
So, does the modern CTO still need to know how to code? The answer appears to be yes, but they probably shouldn’t be head down at the keyboard leading the code creation process on the first day of a project.
Nobody wants an over-seasoned football player on the pitch when they really should be a member of the coaching and management staff by now. It’s the same for CTOs. They need to know where the goals are, how to build team formation and when to send the substitutes on. They should even know how to kick the ball and how to deal with an unruly tackle. Just don’t ever let them take a penalty.
Times have changed. Until relatively recently, every decent CTO, CIO or CISO (insert C-suite tech role of your choice) would have ‘done the knowledge’ and learned to hard code at some form of college.
Understanding the rudimentary principles and governing precepts that denote the core mathematical models, systems and processes that make software engineering what it is, was always regarded as bread and butter for any technology manager. But that was then, and this is now.
Today we live in a world where so-called low-code and no-code platforms work alongside software accelerators and AI-fuelled automation tools that can take much of the repetitive grunt work out of software systems development.
