What a CTO should know about tech

Part 1: Understanding what you're working with

This article was very kindly sponsored by Hermit Tech, who sent me some money so that I could have a month or two to look after my mental health and write a few posts that would be useful to them without stressing too much. They are very capable data engineers (and other kinds of engineers too, but as I understand it, they mostly focus on data), and both wise and good people besides that. If you have pressing needs in the data space, I unreservedly recommend them to you.

Much discussion has been dedicated over the last few decades to discussions of whether technical leaders (CTOs, CDOs and all that kind of executive crowd) need to be "technical" or not to hold the position. Now, from the get-go, I don't think this framing is particularly useful: after all, being "technical" or not is more about gender than anything, and it's just not a useful delineation. However, it seems fairer to discuss whether CTOs need technical knowledge at all or not, and if so, what kind of technical knowledge they need.

As to the question of how much and what technical knowledge might be desired in a leader of a technical field, I think we could do worse than look to military theory. Personally, I think that military theory, being the theory of organising and co-ordinating large groups of people towards a common end, has quite wide application in the societies we live in, but I know that I have to argue that directly. It is, however, inarguable that the military involves leadership of people with specific technical skills on a wide scale, often by people who do not themselves have those skills, and we could thus probably stand to learn from that.

My intention is, over the course of a few articles, to discuss what about technology a technical leader does or doesn't need to know, using Clausewitz and Jomini's writings on military theory as a framing device to discuss the nature of leadership in a field where expertise is of vital importance. There is much, in this framing, to be discussed, but in this case, I wish to discuss one of the more straightforward bodies of knowledge that a CTO might be able to acquire: that of understanding facts about the capabilities of teams and technologies. If you learn nothing else about strategy, tactics or operations, simply having this knowledge will go a long way towards making you more effective as a leader of a technical team.

The capabilities of teams and equipment

Clausewitz (and I don't think Jomini particularly disagrees with him on this point) stresses understanding the capabilities of various units and weapons systems. What this means is that while you don't need to know how a cannon was made, how to ride a horse or the fine details of sabre drill, you need to understand what a cavalry squadron can and can't do like the back of your hand. You need to understand which of your divisions are hardened veterans and which are more likely to break when faced with undue strain. You need to know the range of your muskets and your field artillery, the capabilities of different kinds of shot and how your different arms need to be supported.

Even if you don't know how to fire and load a cannon yourself, you need to know these things because you will be choosing the deployment and disposition of troops. Sufficient ignorance of these facts will lead to you making mistakes like charging cavalry into high-quality infantry in close order: while that might have worked in the 800s, doing the same thing in the 1800s would be an unmitigated disaster. Jomini goes so far at to say that a general charge of cavalry against infantry unsupported by artillery to break infantry squares open is basically never a good idea. Similarly, not understanding the effective range of artillery might lead to it being unable to effectively support other arms of the army or hopelessly exposed to enemy cavalry.

This goes beyond simply not making mistakes: you need to understand how to use each arm of the army to its best advantage in order to win. Understanding the use of light or heavy cavalry in assaults on enemy flanks or to silence enemy artillery requires a very strong understanding of what kind of cavalry you have and what it's good for, which will naturally dictate how you deploy it: a commander who doesn't understand this is going to trip himself up. Having a strong knowledge of the capabilities of your units also allows for flexibility in the face of unexpected events: at Wagram, for example, Napoleon massed all of his artillery in a grand battery directed at the right and centre of the enemy line, which is generally not a wise tactic but in this case was the correct call. Without an in-depth knowledge of what cannon can comfortably do, that approach may simply not have occurred to Napoleon.

There are no hard and fast rules as to how one might develop this knowledge or how it might be structured. Clausewitz tends to stress experience, flexibility and the intangible elements of this knowledge: war as art, while Jomini tends to stress the more scientific, doctrinal, by-the-book elements of learning. While I can't speak to which approach works better in actual military situations (from what I've seen, both can produce very effective generals and militaries), my view is that in technical leadership, clear doctrine and a more scientific approach, including quite detailed playbooks for certain situations, are a very good idea.

So, what does this mean for technical leaders? Obviously you're not usually trying to choose dispositions for your line infantry or attempting to turn a flank, so what kind of knowledge do you need to be good at your leadership role?

Knowing your technology

We can split this out into two sets of capabilities: the capabilities of technologies and the capabilities of teams. In the case of technologies, the key is understanding what each part of your and your competitors' tech stacks is for and what its strengths and weaknesses are both relative to other parts of the stack and relative to each other.

We can use front-end web frameworks as an example: React, Angular, Vue, Svelte and Astro are the big names you need to know here. You'll also need to know what HTML, CSS, JavaScript and TypeScript are, as they're the technologies that the above frameworks are built on top of. We'll run through a quick example analysis to demonstrate the kind of thinking and understanding that you need to be effective here.

First of all, you need to know what all of these things do. HTML is the core of the whole enterprise: when you load any page on the internet, whatever it is, you are rendering HTML in your browser. Whatever all of these technologies (and a bunch of others) are doing, they're going, sooner or later, to create or change HTML and send it to your browser. HTML, in this sense, is the decisive arm of front-end development: everything else that we do in web development on the front-end is to enable HTML to effectively communicate information to the users of a website. CSS is for styling: it controls how the browser renders the HTML that it's attached to, what it looks like and how it's laid out. This makes it something akin to integrated fire support in that it's vital to the proper functioning of a unit but can't operate independently of the unit it's attached to.

JavaScript can operate independently of HTML, and is a fully-fledged programming language in its own right. However, thanks to it being the only programming language (at least until recently) that web browsers will interpret, it is closely tied up with web technologies. In this sense, it's much like cavalry: not tied directly to an infantry unit and deployed separately from it, but not really of much use without the particular demands of late-Napoleonic warfare (without the rest of the Napoleonic package or web technology being what it is, there are better options and JavaScript or cavalry tends to get dropped). Its role in web development is to make the HTML respond to input or otherwise interactive, or to animate certain elements.

With that, we can now discuss the role of web frameworks as such, and there are a few kind of them to discuss. React, Angular, Vue and Svelte are what we call reactive frameworks: their primary goal is to bind data to presentation in a sensible way, so that when what we want to show the user changes the HTML updates naturally and without having to manually write all the JavaScript to do it. These are mostly useful when you have a highly interactive site with data that changes often (potentially even in real-time): something like an online store or a social media site are excellent examples of this, but for a lot of websites they're altogether too heavy, and they require a lot of support. Building a basic static website with React is somewhat akin to using a strategic bomber for tactical fire support where a couple of tube mortars would have provided more than enough fire to dislodge the enemy from a position: sure, it technically works, but you've just burnt a lot of fuel, wasted expensive munitions, and exposed expensive planes and pilots to needless risk. Things like Astro (and the Next and Nuxt metaframeworks) are, by contrast, more like website builders: their job is to handle page routing, organise the site that you've built and give development efforts some structure: if you've ever had the experience of trying to build a website with plain HTML, CSS and JavaScript, you know how messy that can get. These things can work in concert: Astro, for example, supports components written in React, Vue and Svelte in what they call an island architecture.

It's also important to know about the differences between these tools, which quickly gets messy. React, for example, very much takes a JavaScript-first approach to web development, with the expectation being that you write most things in JavaScript and have HTML and CSS embedded in the JavaScript where needed. I personally don't think this is a good approach, but it's one that's consistently been popular with people who prioritise programming over HTML and CSS (which are often seen as not 'real' programming languages). Vue and Svelte, by contrast, tend to expose the basic web technologies a lot more: someone who knows HTML and CSS but no JavaScript can contribute effectively to a Vue application, whereas they'd really struggle to do that with React. Similarly, with the website builders, Next and Nuxt lock you into a framework when you want reactivity (React and Vue respectively), while Astro is framework-agnostic.

The above is probably a minimum of what a CTO working in a company with a heavy front-end presence should know about front-end tools and their capabilities. Even if you aren't writing any code in any of these frameworks, you really do need to know all of this information to know what to deploy where. If you're in the habit of regularly deploying small websites with data that doesn't change often with React, for example, you're wasting an unbelievable amount of developer time and money, to say nothing of the sheer infrastructure costs of keeping a React website up compared to static HTML. Building and deploying something small with Astro over React is at least an order of magnitude faster and cheaper on basically any metric you care to look at. There are half-a-hundred other things like that that a leader needs to know to be effective.

This understanding also plays into long-term decisions about the support requirements of the tools chosen. Plain HTML and CSS, for example, has comparatively low support needs: almost anything can host them easily, there's no question of having to build them in a build step and with fewer moving parts, there's a much lower testing/QA burden on a static website than on a dynamic one. This means that a few web devs and a little experience with DevOps (you might not even need a full-time DevOps person) can keep a static website up and running with almost no sweat. If your website is a React Single-Page App, by contrast, you'll need to build your application regularly, which means a more involved DevOps process and thus more staff and compute resources needed. Hosting for an SPA is also more complex, which means more infrastructure burden and probably infrastructure engineers: in the worst instance, you might find yourself beholden to Kubernetes experts, which you might not really be able to afford.

Finally, understanding how these technologies interact with your current and potentially future teams depends heavily on understanding your tech. Despite React's many, many faults, for example, React developers are quite available, and with a high enough population, some of them are going to be quite good. If you have concerns about recruitment issues, then, React might be a good choice simply on grounds of talent availability even if the technology is less capable than it could be. Conversely, if you have available people who are good at HTML and CSS but can't write JavaScript, Vue might be an excellent choice of technology: it allows you to leverage existing talent and take some of the burden off your JavaScript developers, reducing pressure on them. You're also likely to get a better product at the end of it, as specialised HTML and CSS people are very good at what they do and are consistently going to outclass the vast majority of JavaScript people in their role. The military equivalent here is something akin to the question of light cavalry: the use of light cavalry is often somewhat marginal and you can strictly speaking do without it a lot of the time. It's also very much a support arm, useful for such tasks as scouting, reconnaissance and chasing down defeated enemies or covering a retreat rather than being in the line of battle. That said, if you're able to recruit high-quality light cavalry easily, you'd be stupid not to do it, as despite not being the decisive arm, it makes everything else work so much better. While you will often need to recruit or choose teams to meet your strategic teams, it often also makes sense to adjust how you build software to the strengths of the teams that you have or can easily get.

Knowing your people

Of course, it's going to be difficult to do this if you don't understand the teams that you have or that you could potentially recruit. The sense I get is unfortunately that technical leadership is often particularly bad at this: teams and business units are seen as being more or less interchangeable morasses of "tech person", that can thus be reorganised at will and placed under an endlessly rotating stream of leaders and still function. This is profoundly not how technical teams work.

Each technical team in a company is going to be more or less unique, having had different compositions with different experiences, different leadership and different preferences. Even in an idealised military where every unit is outwardly identical, there is far more variation that you might expect. Some regiments are going to make for poor line infantry but be excellent skirmishers; others are going to be unusually brave under fire. Some regiments are going to be veterans of mountain warfare, while others will have experience of fighting in forested or marshy terrain. Different regiments are going to have different cultural values and different attitudes. If you're going to make the best use of your teams, you need to understand what they're good at and then play to their strengths.

To work this out, you need to sit down with your teams and get to know them pretty damned well: you need to be able to understand what they're particularly good at, and the kinds of things that they're so good at that they can deliver them without thinking about it at all. Do you have a front-end team who's particularly good at slick designs? Maybe you have one that doesn't have the best designers but that's absolutely amazing at optimising load times? Do you have an infrastructure team that's usually good at handling containerised applications, or a data team that makes some particularly slick visualisations? You need to know this about almost every team in your company to be able to make use of them when formulating a strategy.

When doing this, it's also an excellent opportunity to look for gaps in your company's expertise. It's important to note that this might not always manifest as a gap as such, but rather as a weakness in an existing team. Napoleon, for instance, almost lost the battle of Eylau thanks to inadequate field artillery, and while he was clearly able to learn the lesson and massively expanded the amount of artillery he fielded, it would not be difficult for a less capable leader to simply decide that the infantry were bad. If a development team that seems broadly capable is demoralised and not shipping often or shipping good code, then, it might be that the team is incompetent or badly led, but it could also be time to consider building out a formal DevOps team. If you're seeing systemic failures of this kind, there is a good chance that there are missing technical arms that you're not attending to.

Morale is a key factor in technical work, to the extent that I could honestly take up an entire article just talking about it. The point to be noted, though, is that technical work is difficult and intellectually taxing and requires both considerable time to rest and considerable morale. If you do not think that your current project has any hope of succeeding, it is very difficult to motivate yourself to do anything at all. An awful lot of your underperforming teams might well just be demoralised by bad leadership and impossible demands. To fix this, the appropriate methods are a) taking the team temporarily off the front lines and giving them time to regroup, recover and learn new skills followed by b) giving them some small but important projects to do that they're almost guaranteed to actually succeed at.

The final factor of real importance is cohesion, or how well teams stick together. To work effectively, you need a team that trusts each other and that sticks together under pressure rather than coming apart. I have a lot more that I'll say about building cohesion elsewhere, but for now I'll simply note that the common practice of constantly rearranging and reorganising units has a lethal effect on cohesion. It's a thing that can make sense to do if your teams are already bad, but absent that condition, and if your teams are fairly effective, do not fuck things up by reorganising them for no good reason.

It's important to note that you can quite often use a team's strengths in one area to cover for weaknesses in others. If your technical teams aren't completely useless (if they are, I'm afraid there's little that can help), they're going to be good at something, however small, and in that case it makes sense to calibrate your strategy around that. If you have somewhat poor-quality infantry but excellent heavy cavalry and artillery, you will build a strategy that leverages the last two arms rather than the first: perhaps hammer one flank of the enemy army with concentrated artillery, followed by charging the heavy cavalry once the artillery has sufficiently disrupted the enemy formation and rolling up the line that way. Similarly, if you aren't very good at front-end development but have excellent data engineers, you might choose to build a minimal front-end using something like Django and get your database and data model to do as much work for you as you can. Of course, to make a call like that, you need to have a pretty in-depth understanding of both the technologies you're using and what your teams are capable of.

This is very doable

Writing it all out like that, it seems that to be an effective CTO you need to know quite a lot about both tech and your technical teams, even if you aren't on-tools yourself. And that's true! Leadership roles, if you want to be effective in them, demand a lot of you. But this is also very much something you are capable of learning. You don't need to know the fine details of syntax or even how a computer works: everything I've described here is fairly general knowledge about capabilities that anyone who's relatively smart can pick up.

To have become a CTO in the first instance, you have to have been fairly smart. Admittedly, I've met some real dumbasses in high positions, but even there, they at least have to know enough to play the part and read a balance sheet: even if it's unused, the capacity is there. If you're a CTO who's read this through all the way to the end, you absolutely have the capacity to learn what you need to about tech to be effective. This does take time, effort and quite a lot of reading: it's not an easy thing by any stretch of the imagination. It is, however, very much worth dedicating the time to. Your job as a CTO, after all, is to make decisions in an extremely complicated environment and under conditions of considerable uncertainty. Given that fact, it's really important that you understand clearly what tools and what teams you're working with: if you don't understand it, you will, sooner or later, crash out messily. And no-one wants that.

Jomini discusses in some depth how good generals can be chosen or made while working during the golden age of absolutist monarchy. This is actually a pretty good model for modern business administration, which runs on startlingly similar lines, such as a weird hybrid of merit, birth and being in with the in-crowd being required for advancement. In such circumstances, your choice of who ends up in officer positions and as a candidate for a general staff position becomes somewhat limited, so you have to make do with what you have. Jomini doesn't suggest elevating people with no military experience or education (in the case of high nobility) to the general staff, rather suggesting that recruitment take place from relatively high-ranking staff officers. Importantly, however, he suggests that candidates do not need to have experience in all three arms of the military of the time, and that decent officers with experience solely in infantry, cavalry or artillery could make good candidates for the general staff. While I'll comment later on what this says about choosing officers, for now, it's worth noting that while you probably need some technical or technical adjacent experience to be effective in a CTO role, you might need less than you think.

For cases like this, Jomini suggests attaching to a general an aide-de-camp or a staff officer whom the general trusts and will listen to. The idea here is to attach a trusted specialist who has strong knowledge of everything of importance, but who might not have the political or social skills to really lead effectively. In that circumstance, the general makes decisions and interfaces with other organisations (politicians, CEOs and so on and so forth), while the job of the aide-de-camp is to narrow down the whole wide play of probabilities and apply their knowledge of what everything and everyone can actually do to come up with some plausible plans for achieving strategic goals. They also advise the leader in cases where deep technical knowledge or expertise is needed. While this requires a high level of mutual trust between the leader and their advisers, I think a model like this might be sound for CTOs with less direct technical experience. In such a situation, having a highly experienced engineer who's good at communicating (at least to the CTO) and has a wide range of experience of different projects reporting in directly to the CTO and formulating strategy and making decisions for them would likely be a wise idea. Of course, you have to listen to your aide-de-camp, otherwise having that structure in place won't do you any good at all. One way or another, though, having this information ready-to-hand is an important part of being an effective technical leader.

We have, as a society, fetishised innovation and creative thinking at the expense of doing the hard work of reading books and memorising facts and information of late. I can kind of see how we got there, but I must admit, I have little sympathy for it. As I mentioned earlier in this article, it's remarkably hard to actually be creative, flexible, or any of the things we laud without knowing quite a lot: flexibility and adaptability requires a lot of raw material to work with. This means, for the purposes of leadership, that leaders have to know quite a lot of hard information. The good news is that I have full faith in our leaders to be able to do that, and with the will and effort, this is easily within the reach of any CTO who seriously tries to take this seriously.

Thank you all for your attention, and I will be back in the next few weeks with more things that a CTO should know about tech (I'm thinking of writing about friction next time).