Summary
My leverage in AI/ML implementation comes from problem framing, data strategy, domain physics, and the economics of the operating point. Roughly 70% of the value in an industrial ML project sits in these areas. Coding skill exists to let me audit the remaining 30% credibly, not to let me perform it.
This is a deliberate allocation of finite attention, not a limitation I am managing around. The sections below define where I draw the line, why, and what would tell me I have drawn it in the wrong place.
Where this position comes from
I have spent the last ten years using engineering and managerial skills to lead the development of materials, products and services for circular and sustainable development. Those years were built on technical foundations laid at the start of my career, foundations that have been adapted to each new challenge, while serving as scaffolding onto which new skills are added.
The intention with machine learning is the same. I start from what I know: managing product and technology development. Coding is not a foundational skill for that journey, and treating it as one would be a misallocation of the time I have.
The capability specification
Vague commitments to "understanding technology" are unfalsifiable and therefore useless. The following is specific enough to be tested against.
| Level | Capability |
|---|---|
| Do unaided | Load, clean and explore a dataset. Run and retrain an existing model on new data. Produce and interpret a validation result. Manipulate structured data (CSV, spreadsheets) without assistance. Identify the key parameters, inputs and outputs of code someone else has written. |
| Review, not write | Another person's analysis pipeline. Specifically: spot data leakage, challenge an inappropriate train/test split, demand variance across folds rather than a mean, and recognise a metric that flatters an imbalanced problem. Interrogate whether model behaviour is consistent with known physics. |
| Never own | Production code. Deployment infrastructure. Anything a manufacturing line depends on to run. |
The third row is the one most easily got wrong, and it deserves its own argument.
Why "never own" is about resilience, not speed
The usual justification for a technical leader limiting their coding involvement is that they would otherwise become a bottleneck. That is true but it understates the case, because it frames the problem as one of throughput.
The stronger argument is organisational resilience. If I am the person who understands the deployed model, the organisation has a single point of failure wearing a CTO badge. Models outlive the people who build them. A system whose logic lives in one person's head, particularly a person whose diary is committed elsewhere, is not a deployed capability; it is a liability with a dashboard.
My job is to ensure that models are owned, documented, monitored and maintainable by a team. Writing them myself would directly undermine that. The cap on my own involvement is therefore a design decision about the organisation, not a concession about my ability.
On low-code and no-code tooling
Low-code tools are frequently offered as a reason that technical leaders no longer need to understand modelling. I think this gets the implication backwards.
These tools remove the coding. They do not remove the judgement, and the judgement is where projects fail. A no-code platform will train a working defect classifier in an afternoon. It will not tell you whether the training set represents normal variation across shifts, lots and seasons; where to set the decision threshold given the relative cost of a customer escape versus a false scrap; whether inference latency fits the line's cycle time; or what happens to accuracy when a lamp ages and illumination drops 15%.
The proliferation of low-code tooling lowers the barrier to producing models and raises the value of being able to evaluate them. It increases, rather than reduces, the return on the review capability specified above. That is an argument for the position taken in this document, provided the position is stated as competence in evaluation rather than as delegation of understanding.
What this implies for hiring
If I deliberately cap my own code fluency, my first hires must close the gap I have chosen not to close myself. That gap is most often misdiagnosed.
Hire the data engineer before the data scientist. Most organisations do the reverse, then pay a specialist salary to build data pipelines badly for eighteen months while the modelling work they were hired for waits on data that never arrives in a usable state. The binding constraint in nearly every industrial ML programme is data availability, integrity and traceability, not algorithm selection.
Sequence:
- Data engineer — pipelines, historian and LIMS integration, data quality, versioning
- Domain-embedded analyst or data scientist — modelling, working alongside process and materials engineers rather than in a separate function
- ML engineer — only once something is ready to deploy, monitor and maintain
Existing process and materials engineers are not passive stakeholders in this. They are the plausibility check on every model built, and their judgement about whether a model's logic matches known physics is a capability that cannot be bought in.
What would tell me I am wrong
This position is falsifiable in both directions, and I intend to test it against these conditions rather than defend it.
- The line is set too low if: I find myself unable to challenge a data scientist's methodology in review; I accept a result because I cannot construct an objection rather than because I have failed to find one; I cannot tell the difference between a model that works and a model that has memorised its test set.
- The line is set too high if: I am writing code that another person depends on; I am the reason a piece of analysis cannot be reproduced or handed over; my involvement in implementation detail is delaying decisions only I can make.
Both failure modes are observable. I will assess against them at the end of my journey and annually thereafter.
Position
My role is to identify the right problems, secure the data required to address them, assemble and direct the team, set the standards by which models are judged, and decide the operating points on which their value depends.
None of that requires fluency in writing code. All of it requires enough fluency to read it, question it, and know when the answer I am being given does not hold up.