The COO Doesn't Need to Code. But They Need to Understand What Code Changes

The point of technical literacy for a senior operator is not to build the thing. It is to ask the question the vendor was hoping you wouldn't.

The point of technical literacy for a senior operator is not to build the thing. It is to ask the question the vendor was hoping you wouldn't.

A senior operator does not need to become an engineer. But when I learned enough to understand what code could actually do, the questions I could ask a vendor changed — and so did the answers I would accept.

There is a false choice at the centre of most conversations about technical skills and senior operators. On one side, the claim that leaders should stay strategic and leave the technology to specialists. On the other, the fear that executives must reinvent themselves as engineers or be left behind. Both are wrong, and the space between them is where the actual skill lives: enough technical literacy to change the quality of the questions you ask, without any ambition to do the building yourself. This matters more in Jersey than the false choice admits, because the Jersey AI Playbook names skills development as the most consistently cited priority across every major stakeholder group — Digital Jersey, Jersey Finance, the JFSC, the IoD and the Government of Jersey — and warns that the cost of delayed investment in skills exceeds the cost of the investment itself. The question is not whether senior operators need to build capability. It is which capability, and how far.

I can speak to this directly. When I set out to learn some Python, the goal was never to become a developer. It was to stop being dependent on other people to tell me what was possible — to be able to interrogate a proposal, prototype an idea, and know when an answer was evasive. The change was not that I could suddenly build production systems. It was that I could no longer be comfortably misled.

Literacy changes the questions, not the job

The value of technical literacy for a senior operator is almost entirely upstream of implementation. It is not in writing the code. It is in knowing what code can and cannot do, so that the questions you ask a vendor, a developer, or your own team are grounded rather than deferential. Before I understood data structures and APIs, my challenge to a technology proposal was necessarily shallow — I could ask whether something was possible, but I could not assess whether the answer I received was honest, complete, or self-serving.

The pattern I return to is that literacy converts a passive buyer into an active challenger. An operator who understands, at a working level, how data is structured, how systems talk to each other, and what automation can genuinely remove is an operator who can tell the difference between a real constraint and a vendor's convenient one. That is not an engineering skill. It is a judgement skill that happens to require a small amount of technical grounding — and it is worth far more to a firm than the ability to write the code itself.

Technical literacy for a COO is not about doing the work. It is about no longer being unable to evaluate the work — which is a different capability entirely, and a more important one at that level.

What changed, concretely

The abstract claim is easy to make, so here is the concrete version. Learning enough to work with data directly meant I could build a cleansing tool rather than specifying one and waiting. It meant I could reason about how systems should exchange data — where a connector fit, where a transformation layer was better, where re-keying had quietly become the default — instead of accepting whatever architecture was presented. It meant I could design the shape of a management-information capability, because I understood what the underlying data would and would not support.

Crucially, it also meant knowing exactly where my competence ended. The same literacy that let me prototype and challenge also let me recognise, precisely, when a specialist developer, a product expert or a technical architect was genuinely required — and to brief them well when they were. That is the correct senior boundary: enough fluency to challenge and design, enough self-awareness to hand off implementation. The danger is not the executive who learns too little. It is the one who learns a little and mistakes it for enough to build on.

The new technical minimum for senior operators

If literacy is the goal rather than engineering, the useful question is: literacy in what, exactly? A small number of areas do most of the work, because they are the areas where a lack of grounding leaves a senior operator unable to challenge or design. But naming the areas is not enough — the point is to locate yourself honestly within each, because the gap between not being able to challenge a claim and being able to is precisely the gap that a vendor exploits. Table 1 is a self-assessment: for each area, decide which column describes you today, and treat every left-column answer as a specific, closeable development target rather than a permanent limitation.

Table 1 — The senior operator's literacy self-assessment: locate yourself, then close the gap

None of the right-hand column requires the ability to build. Every entry is a question — and a question, unlike an engineering skill, can be acquired in weeks rather than years. In Jersey this is not a solitary undertaking, either: the island has an unusually joined-up professional-development infrastructure — Digital Jersey, Jersey Finance and the sector's CPD bodies all run AI and data programmes — which means a senior operator setting out to close these gaps is not starting from nothing, but stepping onto a path the jurisdiction has deliberately built.

This is augmentation, not reinvention

What this describes is the augmentation thesis applied to a career rather than a task. The point of AI and technical literacy for a senior leader is not to replace what they already are — two decades of operating judgement do not become obsolete because a new tool arrived. The point is to extend that judgement into territory where it was previously blind. An experienced operator with technical literacy is not a worse engineer than a real one. They are a far better operator than they were before, because their existing judgement now reaches further.

This matters for Jersey specifically, where the scarce capability is not raw technical skill but the ability to translate between business operations, technology, governance and implementation. The island's firms do not primarily need more engineers; they need more operators who can hold a credible conversation with the engineers, the vendors and the regulator at once. That translation capability is exactly what a modest, deliberate investment in technical literacy produces — and it is the difference between a leader who directs transformation and one who merely approves it. The COO of a regulated firm does not need to code. They do need to understand what code changes, because that understanding is now the price of asking the questions the role depends on.

The last time a vendor told your firm that something wasn't possible, could you tell whether that was a real constraint or a convenient one — or did you have to take their word for it?

Next: why transformation is a sequencing problem before it is a technology problem — Transformation Is a Sequencing Problem Before It Is a Technology Problem.

Sources: Government of Jersey et al., Jersey AI Playbook (2026) — skills development as the most consistently cited priority across stakeholder groups; JFSC, Guidance on the use of AI in Jersey's financial services sector (2026) — Principle 1 (sufficient people with the required skills and capabilities to apply human oversight); AI Strategy in Jersey FS, Series 1 Part 4 (workforce capability).

Professional disclaimer: The views expressed are my own and are shared for general informational purposes. This content is intentionally non-confidential and does not include proprietary, client-specific, or employer-sensitive information. It is not legal, regulatory, investment, or professional advice; readers should seek appropriate advice for their circumstances.

Financial services leader (20+ years) | Lean Six Sigma Green Belt | London School of Economics (LSE) AI Leadership Accelerator

A version of this article was first published on LinkedIn as part of the Sequence body of work. This is the canonical version.

The views expressed are the author's own and shared for general information. This content is intentionally non-confidential and does not include proprietary, client-specific or employer-sensitive information. It is not legal, regulatory, investment or professional advice. © 2026 Paul Soares. Sequence is the trading name of Sequence Advisory Limited (in formation) · hello@sequenceadvisory.com