This series exists to help you build that confidence one practical step at a time.

I’ve said many times that data is the starting point of AI. Universities treat it as foundational, most AI courses open with it, and nearly every real-world AI project begins with understanding the data before doing anything else. You’ll see why quickly. Without understanding your data, everything that follows becomes guesswork.

Over the coming weeks, we’ll work through practical exercises that mirror real AI engineering work: data exploration, feature creation, model behaviour, evaluation techniques, notebook workflows, and more. But before we ever talk about models, we have to start where every real AI project starts: with the data.

To do this properly, we’re going to anchor this edition in the CRISP-DM process, the same structured framework used by data scientists and AI teams across the industry.

The Cross Industry Standard Process for Data Mining was developed by a consortium of companies involved in Data Mining (Chapman et al, https://www.scirp.org/reference/referencespapers?referenceid=1592779). Most people use some variation of this model, but it is foundational in that sense, and everyone agrees on the first three steps.

CRISP-DM lists the first three stages of any data or AI project as:

1. Business Understanding

2. Data Understanding

3. Data Preparation

Those first two steps occur before any technical work begins. We’ll cover business understanding, then move into more hands-on data understanding before moving into data preparation. Data preparation can be an exhaustive topic, so we’ll dig deeper into it as part of The Build series of articles.

To make this as realistic as possible, we’ll work with a synthetic yet life-like CSV dataset containing IT service desk records. This dataset is sufficiently large and diverse to support a range of practical applications. Over time, we’ll take this same dataset through the entire CRISP-DM lifecycle: exploration, preparation, modelling, evaluation, and deployment.

The data was generated with AI, so any similarity to real people, events, or that one time your service desk melted down on a Friday afternoon is purely coincidental.

For now, we’ll cover the importance of business understanding before taking the very first practical step: load the data, explore it, and understand what story it’s trying to tell.

Don’t worry if Jupyter, Python, or pandas are new to you. Everything will be explained clearly, and you’ll be able to follow along without any prior experience.

Business Understanding: CRISP-DM Step 1

Before touching a single line of code, we need to understand why we’re looking at this data and what problem we are trying to solve. CRISP DM starts with Business Understanding for a simple reason: without a clear purpose, even the most elegant analysis becomes meaningless.

We’re grounding this first Build in a familiar domain, the IT service desk. Because service desks are ubiquitous across most organisations, their data provides a realistic, relatable environment for learning core AI and data concepts.

This step focuses on connecting data to the real work of IT leadership. Service desk data reflects:

• User friction and productivity loss

• Operational bottlenecks

• System reliability

• Team workload and skills distribution

• Service quality and customer experience

• Potential risks brewing beneath the surface

In short, this dataset represents the day-to-day operational heartbeat of IT. And as an IT or AI tech leader, you likely already have a strong intuitive sense of this landscape. That’s useful, but it won’t always hold in other business domains. In finance, logistics, marketing, HR, procurement, or CX, you may not instinctively understand why specific data exists or what influences it.

That’s why Business Understanding matters. When you’re in an unfamiliar domain, your first step is always to speak with people who live that process daily. Their knowledge shapes the questions you ask and prevents you from misinterpreting the data.

For service desk data, typical leadership questions include:

• Where are we seeing the most operational friction?

• Which teams are under pressure and why?

• Are we meeting service expectations?

• What problems are emerging that we haven’t spotted yet?

• Which areas or departments consistently generate the most demand?

These questions provide direction and help us stay anchored as we move deeper into the technical stages of CRISP-DM.

Data Understanding: CRISP-DM Step 2

With a clear purpose established, we move into Data Understanding, the stage where we begin exploring what the dataset contains. This isn’t about fixing anything yet. It’s about becoming familiar with the raw material.

Think of this as the reconnaissance phase. You’re not drawing conclusions; you’re building intuition.

At this stage, leaders and analysts should be asking themselves:

• What kinds of data do we have? Dates, categories, text, numbers?

• Is the dataset complete? Are there missing values or inconsistent fields?

• How is the data distributed? Are some categories dominant? Are some rarely used?

• What early patterns stand out? Do some departments log far more tickets? Are specific priorities overused?

• Does anything look unusual or suspicious? Strange timestamps, oddly frequent categories, or priority patterns that don’t match real-world experience.

Data Understanding is about seeing the data as it really is, not how we expect or want it to be. This step helps you:

• Spot problems early (inconsistencies, missing values, odd behaviour).

• Identify which parts of the dataset will matter most later.

• Develop a mental model of what the analysis or AI model may reveal.

• Avoid costly mistakes in interpretation.

By clarifying the terrain, we set ourselves up for the next stage: Data Preparation, where we begin shaping and refining the dataset to make it meaningful, reliable, and ready for deeper exploration.

Now that we’ve grounded ourselves conceptually, we can move on to the practical exploration of the dataset.

Downloadable Resources

To follow along, you will need:

• service_desk_dataset.csv, the full synthetic dataset

• the_build_001.ipynb, notebook with exploration steps

Step 1. Introducing the Dataset

Here is the dataset we’ll use throughout The Build series. It contains thousands of synthetic service desk tickets designed to resemble real organisational data. This version has been deliberately created with richness, imperfections, and inconsistencies, because real-world data is rarely clean. These imperfections provide ample opportunities for data cleansing, transformation, simplification, and feature engineering.

Below is a summary of all dataset columns to help you quickly understand what each feature represents and how it will be used throughout this series.

Ticket Metadata

ticket_id
Unique identifier for each ticket.

opened_datetime
Timestamp when the ticket was created.

closed_datetime
Timestamp when the ticket was resolved (may be missing).

sla_target_hours
Allowed resolution time based on ticket priority.

reopened
Indicates whether the ticket was reopened after closure.

User and Department Information

user_department
Department of the user, including intentional spelling mistakes and variations.

user_role
User’s role or seniority (Employee, Manager, Director, Executive, Contractor).

customer_type
Whether the user is Internal or External.

location
Office or region. Includes duplicates such as Manchester and Manchester Office.

Ticket Classification

priority
Importance of the ticket (Low, Medium, High, Critical).

urgency_level
Secondary urgency measure (Low, Medium, High, Severe).

issue_severity
Severity rating (1 - Critical, 2 - High, etc.).

category
Issue type (Password reset, VPN problem, Application error, etc.).

system_affected
Business or technical system impacted (Email, CRM, HR System, etc.).

device_type
Device involved (Laptop, Desktop, Mobile, Tablet, Virtual Machine).

Operational Handling

assigned_team
Team responsible for handling the issue.

channel
Method used to raise the ticket (Email, Phone, Portal, Chat).

ticket_source
Additional source detail (Walk-in, Monitoring Alert, Self-Service).

follow_up_required
Indicates whether further action is needed after closure.

resolution_notes
Short summary of the resolution outcome.

Text Content

ticket_description
Free-text description of the issue. Useful for natural language processing.

Asset and System Metadata

asset_id
Identifier for the affected device or system component.

Step 2. Installing Jupyter

Before we jump into installation, it’s worth explaining what Jupyter is and why it’s widely used in both business and academic settings.

What is Jupyter?

Jupyter is an interactive environment that lets you write and run code in small, manageable blocks called cells. Each cell can contain Python code, text, visuals, tables, or charts. Instead of writing a complete program and running it all at once, Jupyter lets you iterate step by step, see results immediately, and experiment quickly.

Think of it as a digital lab notebook for data work.

Why is Jupyter so popular?

Jupyter has become the default tool for:

• Data science: Analysts, engineers, and AI practitioners use it to explore data, test ideas, and build models.

• Machine learning experimentation: Most model prototypes start life in a Jupyter notebook because it’s fast to iterate.

• Business analytics: Dashboards, reports, and exploratory analysis often begin in Jupyter before being handed off to BI tools.

• Academia and research: Universities use Jupyter to teach programming, statistics, AI, and scientific computing because it’s beginner-friendly and powerful.

• Reproducibility and collaboration: A notebook shows not only the final output but also every step required to get there. This makes work easy to review, share, and explain.

Why are we using Jupyter in The Build?

Because it is:

• Beginner-friendly – you can run one cell at a time.

• Immediate – you see results instantly.

• Flexible – perfect for combining explanations, code, and outputs.

• Industry standard – if you learn Jupyter, you’re learning in the same environment as data scientists and AI engineers.

You don’t need prior experience. By the end of this series, you’ll be comfortable running Python, exploring data, and building your own workflows inside a notebook.

We can now discuss how to install it.

Installing Jupyter

Before we load any data, you’ll need a working Jupyter environment. The easiest and most common way to get Jupyter running on your machine is through Anaconda, which packages Python, Jupyter Notebook, and many useful scientific libraries into a single installer.

Rather than walk through the installation step by step for each operating system (Windows, macOS, and Linux), the most reliable approach is to follow Anaconda’s official guides. These guides are regularly updated and tailored to your specific OS.

You can find them here:

Official Anaconda Installation Guides
https://www.anaconda.com/download

Choose your operating system, follow the steps, and once installed, you’ll be able to launch Jupyter Notebook directly from the Anaconda Navigator.

Once Jupyter is installed and running, we can begin working with the dataset.

Step 3. Load the Data in Jupyter

Let’s start to get our hands dirty. The key here is not to panic if Jupyter is new to you. It is simple to learn, and we will keep this first session deliberately light. You are encouraged to experiment, break things, and re-run cells. That is often the best way to learn.

Open a Jupyter Notebook and run the following by clicking inside the cell and pressing Ctrl+Enter if you’re using Windows (or the equivalent key combination for your operating system):

What this does

• import pandas as pd - loads the pandas library, which gives us powerful tools for working with tabular data.

• df = pd.read_csv(”service_desk_dataset.csv”) - reads the CSV file into a DataFrame called df.

• df.head() - displays the first five rows, allowing you to visually confirm that the data has loaded correctly.

How to interpret the output

You should see a small preview of your dataset, with column names across the top and a few rows below. This is your first chance to spot:

• Obvious errors

• Strange or unexpected values

• Missing timestamps

• Odd-looking departments, locations, or categories

Please don’t worry about fixing anything yet. At this stage, we are simply getting familiar with the shape and feel of the data.

Step 4. Explore the Data

Understanding your dataset means asking the simplest possible questions first. In this step, we are not trying to build models or produce polished reports. We are just trying to understand what we are dealing with.

How big is it?

What this does

Returns a tuple in the form (rows, columns).

How to interpret it

If you see (1500, 25), it means 1,500 records and 25 features. This tells you:

• There is enough data to see patterns.

• There are plenty of features to work with.

• Cleansing and preparation will matter.

What types of data does it contain?

What this does

Shows each column, its data type, and how many non-null values it contains.

How to interpret it

This is one of the most critical early commands. You can quickly see:

• Which columns have missing values

• Which columns are stored as text when they might represent dates or numbers

• Whether any fields look suspicious (for example, a column that is almost entirely empty)

This is often where data quality issues first reveal themselves.

What do the numbers look like?

What this does

Produces summary statistics for numeric columns: count, mean, standard deviation, minimum, maximum, and common percentiles.

How to interpret it

Look for:

• Very large spreads between minimum and maximum values

• Unusual averages

• SLA targets or numeric fields that do not look realistic

This gives you a sense of whether the numbers in your dataset behave as you would expect.

What are the most common categories?

What this does

Shows the most common values in the category column.

How to interpret it

This helps you understand:

• The types of issues users most frequently report

• Where operational pressure may be highest

• Which categories might be worth simplifying or grouping later

This kind of simple frequency analysis is often enough to start useful leadership conversations.

This is the heart of the Data Understanding stage in CRISP-DM: examining the data as it is, not as you assume it should be. No cleaning yet. No assumptions. No transformations. You are simply learning what you have.

Step 5. Early Observations

When you explore a new dataset, you should start forming observations such as:

• Are specific departments logging far more tickets?

• Are priorities evenly distributed or skewed?

• Are some categories extremely rare or extremely common?

• Are there fields that look incomplete or inconsistent?

• Do timestamps look valid and complete?

These aren’t conclusions, only early impressions. But they matter because they guide the next CRISP DM stage: data preparation.

Next week’s Build will take this dataset further by preparing and simplifying the features so we can begin extracting insights.

Downloadable Resources

To follow along, you will need:

• service_desk_dataset.csv, the full synthetic dataset

• the_build_001.ipynb, notebook with exploration steps

Many AI projects fail not because the model is poor, but because the data was never appropriately understood in the first place. CRISP-DM prioritises data understanding over preparation, modelling, or experimentation. Everything that happens later, the insights, the predictions, the automation, even the storytelling, depends on the quality of thinking you apply here.

If you can understand the data, you can understand the problem. Once you understand the problem, every decision downstream becomes clearer. You know what to clean. You know what to transform. You know which features matter. You know which questions are worth answering. Without that foundation, even the best tools and algorithms will struggle to deliver value.

This first edition of The Build may feel gentle, but it sets the tone for everything that follows. You’ve taken the same first steps as data scientists, analysts, and AI engineers on real projects: grounding the work in a business context, exploring raw data, and forming early intuition about what’s happening beneath the surface.

That intuition doesn’t just make you better at working with AI; it makes you better at leading the people who work with AI.

Strong leadership in AI isn’t about out-coding your data scientists or being the technical expert in every conversation. It’s about understanding enough of the process to:

• Ask sharper, more relevant questions.

• Challenge assumptions with confidence.

• Spot risks earlier.

• Understand what “good” looks like in analysis and modelling.

• Provide clearer direction to business analysts and data scientists.

• Build trust by speaking their language without overwhelming them with detail.

When you understand the early stages of CRISP DM, especially Business Understanding and Data Understanding, you see the world through the same lens your analysts and data scientists do. You appreciate the complexity they manage, the constraints they navigate, and the thinking behind their recommendations. This builds stronger collaboration, sharper decision-making, and far more effective leadership.

Next week, we move into Data Preparation, the stage where the dataset stops being something you look at and becomes something you shape. We’ll clean the data, engineer useful features, simplify complexity, and prepare the foundation for more advanced techniques in future Builds.

This is where the raw material starts turning into something powerful.

The early years mattered. They gave me the technical depth to understand how systems fit together and the practical experience to deliver projects that grew from minor fixes to major rollouts. They also forced me to develop the skill of taking something deeply technical and explaining it clearly to people who don’t live and breathe IT and networks. Critical in developing the nuance for leadership.

Backgrounds like ours create credible strategic thinkers because we understand the technology intimately and can articulate the concepts that matter.

But AI has disrupted that entire progression. It arrived fast, it arrived hard, and crucially, it arrived after most IT leaders had already made their way up the ladder. There was no “junior AI engineer” phase to grow through. No years of hands-on modelling, data wrangling or algorithmic debugging to draw on. And yet we’re now being asked to make high-impact strategic decisions about technologies we never had the chance to learn from the ground up.

My goal here is to give IT leaders a practical, non-academic bridge into the technical foundations of AI: the concepts you genuinely need to understand to think strategically, communicate confidently and lead effectively in a world shaped by intelligent systems.

In this article, we’ll cover the following:

1. Why Technical AI Literacy Matters for Strategic Thinkers

2. Data Quality and Availability

3. Algorithmic Behaviour and Limitations

4. Python Literacy and Technical Fluency

5. Model Performance Over Time

6. Organisational Readiness and Change

7. Ethics, Governance and Accountability

8. Cost, Compute and Scaling Decisions

1. Why Technical AI Literacy Matters for Strategic Thinkers

Many IT leaders find themselves in a strange position. They’re experienced, credible, and technically seasoned, but when it comes to AI, they’re missing the foundational knowledge that enables strategic thinking. Without that literacy:

• Conversations with vendors can feel lopsided.

• Internal discussions become abstract.

• Risk assessments lose precision.

Decision-making slows, confidence slips, and influence weakens.

Most IT teams today are also operating leaner than ever. Years of cost-cutting and efficiency drives have created environments where engineering capacity is tight, specialist roles are rare, and AI expertise is often entirely absent. Even competent teams struggle to take on deep data work or machine learning operations when they’re already stretched keeping the lights on.

Hiring externally can help fill those gaps, but it won’t remove the need for technical understanding at the leadership level. You can bring in data scientists, ML engineers or AI architects, but if you can’t evaluate their proposals, challenge their assumptions or steer their priorities, you’re not leading the capability. You’re depending on it.

Modern AI teams need leaders who understand enough to guide, question, and support them. Without that literacy, even the best hires will struggle to deliver meaningful impact.

This is where the requirement for authentic leadership emerges. You can’t lead what you don’t understand, and you certainly can’t influence what you can’t explain. Strategic influence depends on one thing above all else: the ability to clearly articulate why a technology matters and how it works at a functional level.

• If you can’t explain a concept, you can’t evaluate it.

• If you can’t evaluate it, you can’t guide a strategy.

• If you can’t guide a strategy, you lose authority in the room.

AI magnifies this because so much of it sounds too good to be true, and alongside industry thought leaders confusing the picture with doomsday scenarios and workforce replacement, taking the lead and projecting confidence is hard work. Leaders who lack technical grounding end up relying on vendors, consultants, or enthusiastic internal teams to “explain” things, leaving you constantly feeling on the back foot.

AI strategy requires a different type of intelligence

Traditional IT strategy was built on clear, tangible components, infrastructure, applications, budgets and risk. These were domains you could map, measure, and diagram, often with predictable cause-and-effect.

AI strategy breaks that mould entirely. Instead of neat architectural layers, you’re dealing with moving parts that influence each other in ways that aren’t always obvious. It lives at the intersection of:

• Data quality and availability

• Algorithmic behaviour and limitations

• Python literacy and technical fluency

• Model performance over time

• Organisational readiness and change

• Ethics, governance and accountability

• Cost, compute and scaling decisions

These aren’t topics you can delegate blindly. You can’t treat AI as a black box handled by a specialist team or an external partner. To lead effectively, you need enough technical understanding to see how these pieces fit together, where the constraints are and which trade-offs actually matter. IT leaders who can do that shape the strategy. IT leaders who can’t will end up reacting to it.

Credibility comes from fluency, not code

Here’s the good news:

You don’t need to become a data scientist.
You don’t need to write machine learning models.
You don’t need to memorise equations.

But you do need fluency.

You need to understand the concepts behind the buzzwords. You need to be able to challenge assumptions, ask the right questions and see where the risks hide.

When you understand AI at a technical-but-leader-friendly level, everything becomes easier:

• Vendor conversations shift from sales-led to strategic.

• Project planning becomes realistic and outcome-focused.

• Governance discussions become grounded instead of speculative.

• The board sees you as the authority rather than the messenger.

2. Data Quality and Availability

Before leaders can understand algorithms, tooling or architecture, they must start with the element that shapes every AI outcome: data. AI systems don’t learn from strategy decks, vendor demos or organisational ambition. They learn from data, the patterns within it, the gaps between it, and the reliability of how it’s collected and maintained.

If the data is weak, the AI will be weak. If the data is inconsistent, the AI will be erratic. Nothing in the stack compensates for poor data. This is why data quality and availability sit at the top of the technical literacy ladder.

When I began my Master’s in AI, this fact hit me almost immediately. In our first foundational Data Science module, the message was unmistakable: models aren’t intelligent, they’re obedient. They learn exactly what the data teaches them, no more, no less. Every project, no matter how advanced, started with days of cleaning, validating and reshaping data before anyone even mentioned algorithms. It was a humbling reminder that the glamorous part, the modelling, is only as good as the groundwork beneath it.

And that’s the blind spot for many organisations. They assume data issues are minor, technical nuisances, the kind of thing an engineer can “tidy up later”. But AI exposes everything: the messy fields, the legacy migrations, the half-completed records, the conflicting definitions. What humans quietly compensate for, AI faithfully amplifies.

Take a straightforward example. A customer dataset where a client appears under three slightly different spellings across two systems. A human recognises they’re the same person. An AI model doesn’t. It treats them as three individuals, distorting churn predictions, customer value scoring, and personalised recommendations, all because of one governance issue ignored for years.

The same applies to operational processes. If ticket categories are inconsistently logged, an AI assistant trained to help your service desk won’t magically repair the inconsistencies. It will confidently produce incorrect classifications due to the chaos it inherited. The issue wasn’t the model. It was the data.

Leaders don’t need to write ETL (Extract, Transform, Load) pipelines or design schemas, but they do need to understand the signals of good data. They need to be able to ask:

• Where does this dataset come from?

• Who owns its quality?

• How clean and consistent is it, really?

• Is the lineage understood?

• Can we trust this for automated decisions?

This isn’t technical trivia. These questions determine whether an AI initiative succeeds or quietly unravels.

Data isn’t static either. It decays as processes shift, behaviours evolve and systems age. That means data quality cannot be treated as a project with a beginning and an end. It must be treated as infrastructure, continuously monitored, maintained, and governed.

Good AI begins long before a model is trained. It starts with data that is accurate, consistent, complete and available. Leaders who understand this don’t just build better AI; they prevent entire categories of failure before they occur.

3. Algorithmic Behaviour and Limitations

Algorithms were another reality check early in my Master’s. Before the course, I assumed algorithms were the clever bit, the secret sauce that made AI powerful. The first few weeks completely dismantled that idea. Algorithms aren’t intelligent. They don’t reason, interpret or understand. They pattern, match, faithfully and rigidly, even when the pattern no longer makes any sense.

This is where many leaders misjudge them. Humans use context, intuition and lived experience. Algorithms use maths. They don’t understand meaning, intent or tone; they reflect statistical relationships in their training data. Two people can read the same customer email and instantly understand the underlying frustration, sarcasm or urgency. A model might classify the same message as positive because it spotted a single upbeat word.

One exercise during the module drove this home. We trained a classifier on an imbalanced dataset, and the model ended up predicting the majority class almost every time. On paper, its accuracy looked impressive. In practice, it was useless. It wasn’t broken; it was doing precisely what the data had taught it. That lesson matters for leadership: AI isn’t just capable of being wrong, it can be confidently wrong in ways a human would never be.

Real systems behave the same way. A customer support classifier might latch onto misleading keywords and repeat the mistake indefinitely. A forecasting model might miss a market shift because it has no concept of external forces. A fraud model might flag legitimate behaviour simply because it has never seen it before. These aren’t failures of intelligence; they are failures of interpretation. The algorithm is doing precisely what it learned.

Once you understand this, your approach to leadership shifts. You stop assuming models “understand” and start asking the questions that matter: what data shaped this behaviour, where are the blind spots, what scenarios will break it, and where must humans remain in control? Your role is to define boundaries, validate behaviour, and anticipate failure modes.

Algorithms are powerful tools, but they are tools. They cannot question their assumptions, recognise nuance or self-correct their worldview. Only people can do that. Leaders who understand this avoid being blindsided by unexpected behaviour, vendor hype or inflated expectations. Instead, they create the conditions for algorithms to succeed safely and predictably.

Good AI leadership isn’t about writing models. It’s about understanding how they behave, when they fail, and how to guide the teams responsible for keeping them honest.

4. Python Literacy and Technical Fluency

Another foundational module in my Master’s was Python programming. Not because the course was trying to turn us all into software engineers, but because Python is the language of modern AI. It is the workshop where almost every model is designed, tested and deployed. It is also the language behind data pipelines, feature engineering, model evaluation, and the majority of research papers and practical examples in the field.

Before starting the programme, I had always seen Python as just another scripting tool. And it’s worth pausing here because earlier in this article, I said you don’t need to become a data scientist or write machine learning models. That still stands. Understanding Python isn’t about becoming hands-on or replacing your engineers; it’s about gaining the fluency to lead them well. You don’t learn Python to write production systems. You know just enough to see how AI actually works under the surface, so your leadership decisions are grounded in reality rather than assumption.

Before starting the programme, I had always seen Python as just another scripting tool, a general-purpose language sitting somewhere between DevOps automation and data analysis. Within weeks, it became clear why the entire AI ecosystem has settled around it. Python is powerful, readable and forgiving. It lets you move quickly, experiment freely and translate ideas into working prototypes without wrestling with the language itself.

That mattered for my learning. Understanding Python didn’t just make me more comfortable with the technical modules; it made the underlying AI concepts click into place. When you write a few lines of code to clean a dataset, build a regression, or test a neural network, the concepts stop being abstract. They become concrete. You see how the maths translates into behaviour. You see how small changes in data shape model performance. You see where things break. That level of familiarity changes everything.

And this is where Python becomes essential for IT leaders. Not because you need to code, but because understanding the ecosystem gives you fluency in the world your AI teams are operating in. Data scientists and machine learning engineers live in Python every day. They use it to prepare and clean data, build models, test features, integrate with APIs, deploy pipelines and automate workflows. If you want to lead those teams effectively, it helps to understand the tools they use, the constraints they face and the effort involved in what they’re building.

Even basic familiarity creates strategic advantages. You gain a clearer sense of what is easy, what is difficult, and what is genuinely complex. You understand why specific requests require days rather than hours, and why data issues slow teams down long before modelling even begins. This isn’t about interrogating your engineers or micromanaging workflows. It’s simply about having enough context to engage confidently and make decisions grounded in reality.

You don’t need to write Python, debug Python or build models in Python. But developing a working understanding of why it is used, how it fits into the workflow and what it enables gives leaders a bridge into the technical reality of AI. It strengthens your credibility and sharpens decision-making without drifting into doing the team’s job for them.

Good AI leadership isn’t about becoming a programmer. It’s about developing enough technical fluency to understand the landscape and make decisions with confidence.

5. Model Performance Over Time

One of the biggest surprises when I entered the world of AI wasn’t the complexity of the models, but how quickly they can drift. Earlier in my career, if a system worked on Monday, it would still work on Friday. With AI, the ground shifts beneath you.

When you deploy a model, you’re deploying a snapshot of the past, a frozen moment in the organisation’s behaviour, customer patterns or operational processes. But the world refuses to stay still. Trends change. Customer behaviour evolves. A process gets tweaked without anyone realising the impact. Within weeks, a previously accurate model can begin making flawed predictions and, unless someone is watching, those flaws scale silently.

Consider a manufacturing and distribution environment that begins using demand forecasting. Imagine a model trained on three years of stable ordering patterns across your warehouses. It performs well at launch, predicting stock levels, replenishment cycles and likely order volumes with impressive accuracy. Then a new product line is introduced, or a logistics partner changes schedules, or a raw material shortage forces different buying behaviour. Suddenly, the model is forecasting based on patterns that no longer exist. From the outside, the model appears unreliable. In reality, it is still doing exactly what it was trained to do; the world around it has changed.

I saw something similar firsthand in a recent internal project. A model built to route support tickets performed well at launch, but within a month, accuracy had noticeably declined. The reason? A team leader updated the category list without telling anyone. Humans adapted instantly. The model didn’t. It kept confidently routing tickets based on patterns that no longer existed.

This is where many organisations underestimate the ongoing work required to keep AI healthy. It’s not enough to train a model. You need:

• Monitoring that surfaces changes in behaviour.

• Ownership that doesn’t disappear after deployment.

• Retraining cycles tied to business rhythms.

• Alerts for drift before it becomes a failure.

Models don’t degrade because they break. They degrade because reality changes. Leadership is recognising that AI isn’t a “launch and forget” initiative. It’s a living system that needs the same care and attention as any critical service.

6. Organisational Readiness and Change

Across my IT career, the most significant blockers to progress have rarely been technical. They’ve been cultural. And AI exposes that truth faster than anything else I’ve ever implemented. You can have a well-designed model, clean data and sensible architecture, but if the organisation isn’t ready to absorb AI into its workflows, you have a tough time ahead of you.

The first time I tried to introduce an AI-supported workflow, the model wasn’t the issue. Trust was. People, in some cases, just rejected the technology; they were unsure what it meant for their jobs and became concerned about their judgment and accountability. I’ve seen this pattern repeat itself across service desks, warehouse operations, forecasting teams and commercial functions. When people don’t understand how the AI works or how its recommendations fit into their process, they default to caution or quiet resistance.

In a manufacturing and distribution environment, this becomes even more visible. Imagine an optimisation model that suggests a new picking sequence in a warehouse. The maths might be flawless, but if experienced operators don’t understand why the model recommends a change or if it conflicts with years of taking a different route, they will ignore it. Or imagine an order management system designed to automatically read customer purchase orders from emails and raise them inside your ERP. If the sales or admin teams don’t trust the model to extract quantities or product codes correctly, or if nobody knows who is responsible for correcting misreads, the automation becomes a source of anxiety rather than efficiency. The model might work most days flawlessly, but a single misinterpreted line item can undermine confidence across the whole team.

Organisational readiness isn’t about asking whether the technology is mature enough. It’s about asking whether the people, processes and culture around it are prepared. That means:

• People understand what the AI does and doesn’t do.

• Teams know where human judgment is essential.

• Ownership is defined and not left to “whoever picks it up”.

• Existing processes are updated to provide AI recommendations a place to land.

• Failure modes are discussed openly so people know what to expect.

One of the most effective changes I made didn’t involve workshops or formal training sessions. It was much simpler. I involved the people who would be using the model right from the beginning. Instead of building something in isolation and unveiling it at the end, the teams helped shape how it worked while it was being developed. They reviewed early outputs, questioned assumptions, highlighted edge cases, and pointed out where the model didn’t reflect reality on the ground. Because they were part of the creation process, trust formed naturally. And once trust was formed, adoption wasn’t something we had to push; it happened on its own.

AI doesn’t remove human involvement. It reshapes it. Organisational readiness is about preparing people for that shift, so AI becomes a force multiplier rather than an unwelcome disruption.

7. Ethics, Governance and Accountability

Governance is one of those topics that rarely gets the attention it deserves at the start of an AI initiative. When a model is new, and its outputs look impressive, it’s easy to get caught up in the possibilities and assume the risks are theoretical or far removed from day-to-day operations. But in practice, governance is often where AI either becomes a responsible, trusted capability or a painful lesson.

My first real exposure to the risks came during a Master’s assignment where we assessed a seemingly high-performing model. At first glance, the accuracy looked outstanding. But a deeper review revealed that it had learned patterns that disproportionately affected a specific group in the dataset. The numbers were impressive; the consequences would not have been. That experience reshaped my entire view of AI governance. It stopped being an academic concept and became a real responsibility.

Let’s consider a distribution environment, as previously discussed, the risks play out differently but with equal weight. Imagine an automated system scoring supplier performance. If the model quietly learns biases in historical data, perhaps favouring large suppliers simply because their volumes smooth out anomalies, procurement teams could make decisions that unfairly penalise smaller manufacturers. Or consider an AI model triaging inbound customer queries. If it consistently misclassifies issues from a specific region due to subtle linguistic patterns, customers in that region may receive slower or poorer service without anyone noticing.

These aren’t theoretical problems; they are real risks that emerge whenever AI is deployed at scale without proper oversight.

Good governance means digging beneath the surface:

• How was the model trained, and what data shaped its behaviour?

• What assumptions does it rely on?

• Where are the blind spots or edge cases?

• How confident should we be in its decisions, and under what circumstances?

• What does “good” look like, and who decides?

Accountability must be unambiguous. Someone in the organisation must be able to say, “I understand how this works, and I stand behind it.” That responsibility cannot be outsourced to vendors, consultants or even technical teams. Governance is a leadership discipline.

And governance isn’t about slowing progress or creating bureaucracy. Done well, it builds trust with customers, regulators, and the teams who rely on AI to do their jobs. Clear governance frameworks encourage adoption, reduce fear and provide the confidence needed to scale AI responsibly.

When leaders treat governance as part of their strategic remit rather than a procedural hurdle, AI becomes not just influential but trustworthy.

8. Cost, Compute and Scaling Decisions

One of the easiest mistakes to make with AI is assuming the cost sits in the model itself. You build a prototype, it sprints on a laptop, and you think, “Great, this won’t be expensive.” Then you try to scale it, and that is when reality arrives.

I often take the opportunity to explore the difference between training a model on my laptop and running one in production. The gap is usually quite extraordinary. A simple classification model performed well on small datasets, but when we fed it enterprise-scale data, the compute requirements jumped dramatically. Storage, networking, GPU cycles, inference time, and pipeline orchestration all became real constraints. It was the first time I fully appreciated that AI isn’t just software. It is infrastructure.

I’ve seen the same pattern play out in industry. A team builds a proof of concept in a controlled environment, it performs well, and everyone feels confident. Then the project hits production, cloud spend spikes, and inference takes longer than expected, and the team suddenly realises they’ve designed something robust but not sustainable.

In any organisation operating at scale, these challenges become even more pronounced. Models that support critical operations, whether they are forecasting demand, prioritising workloads, analysing customer behaviour or optimising internal processes, often require:

• Frequent retraining as new data arrives.

• Large volumes of historical data stored and accessible at speed.

• Real-time or near-real-time inference depending on the use case.

• Robust pipelines that can cope with large data movements and operational spikes.

This is where technical literacy really matters for IT leaders. Not because you need to architect the system yourself, but because you have to judge whether the proposed approach is appropriate. A technically sound model may still be the wrong choice operationally.

I remember evaluating an optimisation solution that promised exceptional accuracy. The model was impressive, but the computational cost of running it at the frequency the business required would have wiped out any benefit it generated. When we stepped back, a simpler and far cheaper model delivered the same business outcome. The value wasn’t in the model’s power; it was in choosing the right tool for the job.

Good AI leadership is not about choosing the most advanced architecture. It is about balancing accuracy, cost, speed and practicality. Leaders who understand these trade-offs avoid spiralling cloud bills, frustrated engineering teams and AI solutions that collapse under operational pressure.

AI is changing the shape and expectations of IT leadership, but it isn’t doing it by replacing the skills we already have. It’s doing it by stretching them. The days when you could lead purely through experience, instinct or broad technical understanding are fading. Today, credibility comes from fluency, from seeing how the moving parts connect, and from understanding enough of the mechanics to lead with clarity rather than caution.

What this journey shows is that none of these concepts, data, algorithms, Python, performance, people, governance, or cost exist in isolation. They form a connected foundation, a new kind of technical literacy that gives leaders the confidence to engage rather than delegate, to question rather than accept, and to shape AI outcomes rather than be shaped by them.

The good news is that you don’t need to become an expert in any of it. You don’t need to write code, train models or architect pipelines. You need to understand the terrain well enough to navigate it. Enough to make informed decisions. Enough to challenge assumptions. Enough to give direction instead of taking it.

AI will become a defining part of how organisations operate. The leaders who thrive will be the ones who choose to step toward it, not away from it. Those who build literacy early will become the steadying hand their teams look to when the noise grows louder.

You already have the foundation. The experience. The leadership instincts. This is simply the next step, the one that makes you credible in an era shaped not by systems alone, but by intelligence.

With every step you take toward AI literacy, you widen your influence and strengthen your leadership. The future is already shifting in your favour.

I’ve practically lost count of the times I’ve sat in front of peers, industry leaders, interviewers, merger and acquisition teams, private equity, and a whole host of business leaders, managers and CEOs who have all asked me for the same thing.

“We want you to deliver AI.”

I’m positive that IT leaders across the globe are consistently hearing the same request, and many of us are working hard to suppress a blank stare while desperately piecing together the right words to sound visionary, strategic, and in control. Interviewers expect something plausible and innovative. Executives want a clear roadmap. The business demands tangible value. And yet, that’s often difficult to produce for three main reasons:

1. Business leaders often ask for “AI” without a clear definition of what outcome they expect.

2. IT leaders are still defining what “delivering AI” looks like in practice.

3. Strategic alignment is unclear; many teams struggle to turn ambition into a practical, value‑driven plan.

Sometimes, it’s a blend of all three, resulting in awkward conversations and the occasional tactical side-step to avoid eager CEOs while managing the very real frustrations of modern tech leadership. I’ve seen talented IT leaders get it completely, hopelessly wrong, not out of incompetence (occasionally out of incompetence), but out of the pressure to sound certain, and be certain, in an uncertain space.

So where does that leave today’s IT leader in the age of AI? When everyone around you is looking for you to understand, looking to you for all the answers, how do we move forward confidently as IT leaders? How do we effectively leverage the AI landscape and deliver on its promises? Creating the workplace of the future is not all as clear as we’d like it to be.

In this article I want to cover some of these concepts, this will help set some of the foundations for future writings, but will also clarify some of our immediate challenges as IT tech leaders. Today we’ll cover:

1. The IT Leader’s New Frontier, an introduction to how AI is reshaping the identity and expectations of IT leadership.

2. The Shift From Ownership to Orchestration, a look at why modern IT leaders must guide ecosystems rather than own every system.

3. The New Skillset of the IT Leader, a breakdown of the evolving capabilities needed to lead confidently in the AI era.

4. Building the Foundations Before the Tools, a reminder that without solid data, process, and governance foundations, AI will fail before it begins.

5. The Danger of AI Theatre, an honest look at superficial AI initiatives that create noise instead of value.

6. AI as Cultural Transformation, an exploration of how mindset, trust, and behaviour determine AI success more than tooling.

7. The Critical Role of Problem Definition, a dive into why defining the right problem matters more than choosing the right model.

8. Aligning AI with Real Business Value, a look at tying AI initiatives to meaningful, measurable outcomes.

9. Moving from Firefighting to Foresight, exploring how AI elevates IT from reactive support to proactive strategic leadership.

10. Why “I Don’t Know” is a Leadership Superpower, a reflection on how honesty and curiosity build stronger, more credible leadership.

1. The IT Leader’s New Frontier

AI is transforming IT from a business support function into a proactive engine of business productivity and intelligence. But the tools alone don’t define success; the people who use them do. The new IT frontier is about orchestrating humans and machines toward shared goals. It’s about empathy in automation and foresight in data. It is not about purchasing an AI licence and hoping it magically transforms the organisation. It’s not about panic‑buying every tool with an AI sticker on the box. It’s not swapping out mature, reliable systems for overpriced “AI‑powered” equivalents that introduce more complexity than value. Simply put, tool shopping is not a strategy. Buying licences is not a transformation. Real AI adoption requires clarity, capability building, problem definition and a deliberate plan that connects technology to meaningful outcomes. A simple fact that is incredibly lost on most, myself included, when the AI revolution started building momentum.

We’ll cover some of this in greater depth, but in short, the role of the IT leader will change rapidly over the next few years, perhaps even the next months, what with this rapid rate of change. It’s fascinating to be part of the next technical revolution, and current and future IT leaders will be the ones leading the charge and guiding others and businesses to help them succeed.

2. The Shift From Ownership to Orchestration

Critical to this success will be the shift from ownership to orchestration, foundational in fact. The cloud has quietly rewritten the rules of IT, and AI has made that shift impossible to ignore. Most modern AI capability lives in the cloud, built on infrastructure, models, and compute power that no individual organisation could realistically own. This means IT leaders now operate in an environment where the majority of the technology stack sits outside their walls.

Instead of owning systems end‑to‑end, IT now orchestrates an ecosystem of cloud services, vendors, APIs, automations, and data flows. The role has evolved from builder to conductor, from controlling every component to designing how the components work together.

This shift is driven by reality:

• Vendors now innovate faster than internal teams can track.

• Data flows across dozens of platforms, not a single controlled environment.

• Business teams adopt tools independently, forcing IT to guide rather than gatekeep.

• AI services are consumed rather than installed.

Ownership required certainty. Orchestration requires curiosity, clarity, influence, and systems thinking. The shift has been happening for a while, but those of us still holding onto infrastructure ownership will need to learn to start letting go. It’s no longer about controlling and holding everything tightly but about ensuring we can manage hybrid environments, ensure everything works together and then ultimately prepare for a shift to a fully cloud-managed environment.

3. The New Skillset of the IT Leader

The modern IT leader’s skillset is shifting from technical mastery to strategic intelligence, the ability to understand how technology, data, people, and business goals intersect. You could argue and say this is what a lot of IT leaders do, particularly those holding a CTO badge, but all IT leaders are feeling a shift as this responsibility starts to move further down the middle management chain. So, because of this shift, take note of the following:

Be adaptive and comfortable with change
An ability to embrace change and remain adaptive will be essential in the current and future AI workplace. This ties closely to the rapid pace of technological evolution. Adaptability keeps you relevant. AI itself is the new skill of the decade, not just its tools, but the underlying technologies that power it, particularly data science, automation, and modern programming practices. Comfort and understanding with these technologies will be critical.

Translating business needs into data opportunities
The most valuable leaders can articulate how data supports decisions, improves outcomes, and unlocks opportunities. They bring clarity where the business brings complexity, and help teams understand how AI can transform that clarity into capability.

Ethical awareness and human‑centred leadership
AI also introduces new risks, biases, and uncertainties, which have inevitably freaked many people out. Outlandish claims of AI stealing jobs and taking over the world by key public figures have left many feeling uneasy. This leaves it to us to set the tone by ensuring technology is deployed responsibly, transparently, and in service of people, not at their expense. A clear ethical framework will serve all leaders of course but the specifics of ethical AI carry a significant amount of weight at the moment. People are looking for clear, moral guidance. Human-centred AI is an important ethical perspective.

4. Building the Foundations Before the Tools

Some of my predecessors went straight to the tools in eager adoption of AI, but there is so much to consider operationally, so much so that without the groundwork covered, even those tools will be shaky at best. This creates immediate doubt culturally and professionally, so it’s best to get our AI ducks lined up before we start diving in.

Data quality and accessibility
AI for all the intelligence it delivers (or seems to deliver) is a result of having the right data. AI cannot compensate for missing, incorrect, or inconsistent data, and most businesses have a data landscape to be feared, at the very least, looked at sceptically. IT leaders must understand where their data lives, how clean it is, and how easily it can be accessed. Without this, every AI initiative becomes guesswork dressed up as progress.

Process clarity and standardisation
I’ve had the pleasure of working in a number of different industries, businesses of varying sizes and capabilities but this is always an area of struggle or at least refinement. In most cases, processes are undocumented, inconsistent, or vary wildly across teams and because of this, AI has nothing stable to latch onto. Clear processes create predictable patterns, which help the AI adapt and learn quickly. Not only that but clear process documentation will assist with the issues around problem definition which I describe later.

Integration and interoperability
Sadly, businesses are often a patchwork of legacy systems, modern apps, spreadsheets, and shadow IT. AI thrives in connected environments, and rarely do we have the ability to ensure systems can talk to each other, a prerequisite to business intelligence and AI. It’s often we find that any AI strategy worth the computer it’s typed on will require plans to out some if not all of these legacy platforms. Aging ERP, HR, and ropey telephony platforms are often some of the first targets.

Governance and security
An important consideration, without any doubt and often deployed by sales companies to drive fear into AI adopters. How often I’ve heard the story of a University inadvertently sharing payroll data to public LLM (Large Language Model) is unreal but it paints a clear warning. AI introduces new data flows, permissions, and compliance considerations. Without governance, leaders risk deploying solutions that expose data, breach regulations, and ultimately undermine the trust of AI. Do your homework, get this right, get an outside consultant if needed to plug this potential governance and security gap. Better safe than sorry.

Capability building and workforce readiness
Tools will not save a team that isn’t prepared to use them. Training, experimentation time, and skill‑building are essential. As IT leaders, we’re the voice to give people confidence, but ensuring that we’re fully prepared prior is critically the most important thing. If we’re not confident and clear in what we’re trying to deliver, our teams nor the business will follow suit. Get comfortable and clear on your strategy before you start shouting it from the office roof.

Why this matters
Most organisations want to jump straight to tools because tools feel like progress. But without these foundations, AI becomes slow, unpredictable, inaccurate, or politically unworkable. The smartest leaders know that the work no one sees is the work that makes everything else possible.

5. The Danger of AI Theatre

I may have accidentally raised the matter of incompetence earlier and this is what I was specifically referring to, AI Theatre. It’s the performance of progress without the substance of progress. It’s the organisational habit of running flashy pilots, producing polished slide decks, or name‑dropping AI models without ever delivering meaningful value.

A real example of this was the delivery of Microsoft Teams Transcription, long before the days of meeting summaries, auto-built task lists and emailing following up actions. Just a transcript. This AI breakthrough was touted as the next business breakthrough, every manager and business leader got pulled into meetings, was shown a flashy slide deck and then it was demonstrated.

Anyone familiar with early or even todays raw transcriptions will know how painful they are to read and decipher, on their own they deliver very little but the theatre in which it was presented built it up to be so much more, only to then watch the reputation of AI and the individuals involved come crashing down. This undoubtedly stalled AI adoption at the business.

They were trying to solve a problem that didn’t exist. It momentarily created the illusion of innovation while masking the absence of any meaningful strategy. The danger wasn’t just wasted money and time; it’s the erosion of trust in AI itself. When executives see pilots go nowhere, they start to believe the technology has no real impact, when in reality, it was never given the structure or sponsorship it needed. The IT leader’s role is to recognise when AI is being performed rather than implemented, and redirect effort toward problems that matter.

6. AI as Cultural Transformation

Tech adoption and particularly AI adoption, fail far more often because of people than because of technology. The tools are ready. The real question is whether the organisation is.

True AI transformation requires a shift in mindset: curiosity over caution, experimentation over perfection, and learning over defensiveness. Teams need psychological safety to try new approaches without fear of embarrassment, and all leaders (not just IT leadership) must create the conditions for that safety. Without it, AI becomes something people avoid rather than embrace.

Many organisations rush to deploy tooling because it feels like visible progress. But deploying a tool without preparing the culture almost guarantees resistance. People don’t reject AI because it’s complicated; they reject it because it threatens routines, comfort, identity, or control. Cultural readiness is what bridges that gap.

Business culture also doesn’t move at the speed of code or cloud innovation. It moves slowly, through trust, clarity, communication, and shared understanding. That’s why tech leaders must act as cultural translators, helping teams understand not just how AI works, but why it matters and what it enables.

Cultural transformation requires cross-functional partnership. HR, operations, finance, IT, and executive leadership all shape how people experience change. If even one of those functions drags its feet, adoption slows to a crawl.

The IT leader’s job isn’t to force AI onto the organisation. It’s to guide people through the uncertainty, build alignment, and create a culture where intelligence, human and machine, can thrive.

7. The Critical Role of Problem Definition

Problem definition is where most AI ambitions either take shape or fall apart, and in my experience, this is the bit everyone rushes past because it isn’t shiny, it isn’t fast, and it doesn’t feel like “AI adoption”. But this is exactly where the real work begins.

A clear problem definition is the single greatest predictor of whether an AI initiative will succeed. Most organisations begin with a solution in mind, “We need AI for forecasting”, “We need AI for stock control”, “We need AI to improve customer experience”, when in reality, these are outcomes, not problems.

When someone says “We need AI for forecasting”, what they really mean is “We don’t fully understand why our forecasting isn’t working”. When someone says “We need AI for stock control”, the real issue is “We don’t know where the friction is, who owns the data, or why the process keeps breaking”. That’s the level we need to get to.

The job of an IT leader isn’t to force AI into a business problem; it’s to keep asking why the problem exists in the first place. Sometimes AI is the answer. Sometimes it isn’t. And sometimes the hardest part is admitting that a broken process or a lack of data maturity is the real culprit, not the absence of a model.

This is also where honesty matters. Buying CoPilot or rolling out ChatGPT isn’t going to magically turn a business into an AI‑driven organisation. These tools can support intelligence, but they cannot create it from thin air. If we don’t understand the problem deeply, AI becomes a guessing game, and guessing is expensive.

Strong problem definition keeps us disciplined. It keeps us honest. And it ensures that when we do bring AI into the equation, it’s solving something real, measurable, and worth solving.

8. Aligning AI With Real Business Value

If there’s one thing AI has done brilliantly, it’s convince every business that “value” automatically appears the moment you plug in a model. We know better. AI only creates value when the problems are clear, the processes are stable, the people are ready, and the outcomes are measurable. Everything else is noise.

Aligning AI with real business value starts with a blunt question: What are we actually trying to improve? Not theoretically, not aspirationally, but in the day‑to‑day reality of the business.

Sometimes the answer is efficiency. Sometimes it’s accuracy. Sometimes it’s saving people from spending their lives in spreadsheets. Sometimes it’s unlocking insights that the business never had access to. Whatever the case, the value must be specific, visible, and understood.

One thing I’ve learned the hard way is that value isn’t created at the moment of adoption; it’s created at the moment of integration. When AI is woven tightly into the workflow, when it changes how decisions are made, when it nudges behaviour in better directions, that’s where the magic happens.

The challenge is that many organisations tie AI to value after the work is done, retrofitting benefits that don’t truly exist. As leaders, we have to resist that temptation. We define the value before the project starts, we track it as the work unfolds, and we validate it once deployed. That discipline stops AI from becoming theatre and keeps it anchored to outcomes that matter.

Most importantly, aligning AI with value isn’t about ROI spreadsheets or consultancy frameworks, it’s about asking whether the people using it feel supported, empowered, faster, clearer, or more capable than they did before. Real value is felt long before it’s measured.

When we get this right, AI stops being a science project and becomes what it should have been all along: a meaningful contributor to how the business thrives.

9. Moving From Firefighting to Foresight

If there’s one experience every IT leader shares, it’s living in constant firefighting mode. Tickets flying in, systems wobbling, users frustrated, and every day feeling like a sprint through an obstacle course. For years, this has been the default setting of IT, reactive, overloaded, heroic, and exhausted.

AI finally gives us a way out of that cycle.

The real promise of AI in IT isn’t automation for automation’s sake; it’s the shift from responding to anticipating. From waiting for something to break to knowing it’s going to break long before anyone else does. From juggling escalations to preventing them quietly in the background.

This is what foresight looks like:

• spotting patterns in performance data long before thresholds are crossed

• predicting user needs before they become pain points

• identifying bottlenecks in workflows before they slow the business down

• uncovering improvements that no human had the time or visibility to notice

And here’s the subtle but important part: foresight changes how IT is perceived. When you move from break–fix firefighting to strategic insight, you stop being the department that “fixes things” and start being the function that guides the future of the business.

AI won’t eliminate every fire, but it will shrink the forest. It gives leaders the fuel to move away from operational chaos and toward intentional, proactive strategy, the kind of strategy that not only improves uptime but also elevates IT into the realm of genuine business leadership.

Foresight is another area where the value of AI becomes visible, tangible, and deeply respected. It’s where IT stops reacting to the business and starts shaping it.

10. Why “I Don’t Know” Is a Leadership Superpower

There’s a strange pressure in tech leadership, this idea that the moment a new wave of innovation arrives, we’re supposed to become instant experts, fluent in every model, every acronym, every opportunity it presents. It’s nonsense, of course, but it’s amazing how quickly that pressure convinces smart people to bluff.

The truth is simple: the leaders who try to look certain are the ones who make the most damaging mistakes.

Saying “I don’t know” isn’t an admission of incompetence. It’s a statement of responsibility. It tells the room that you value accuracy over ego, progress over performance, truth over theatre. And in a landscape as fast-moving as AI, honesty is one of the most stabilising forces a team can have.

When you say “I don’t know yet, but I will”, you’re doing three powerful things:

• setting a realistic pace for the business

• creating space for learning and experimentation

• anchoring the organisation in evidence, not assumptions

People trust leaders who tell them the truth, especially when the truth is uncomfortable. Pretending to know everything in AI isn’t leadership; it’s gambling with the credibility of the entire tech function.

Real leadership is steady, grounded, and unafraid to acknowledge uncertainty. And ironically, the leaders most willing to say “I don’t know” are often the ones who end up knowing more than anyone else.

If you’ve made it this far, you’ll know that AI isn’t a magic switch, and it certainly isn’t a shortcut. It’s the next evolution of how we lead, how we think, and how we build organisations that are genuinely ready for the future. Not because we bought the right tool, but because we built the right foundations, asked the right questions, and led with honesty rather than bravado.

The role of the IT leader is shifting faster than any time in recent memory. We’re no longer the people who simply keep the lights on. We’re the translators, the orchestrators, the cultural shapers, the problem definers, and the steady hands guiding businesses through a landscape that changes by the week.

This isn’t easy work, but it is meaningful work. And if we approach AI with clarity, integrity, and a human‑centred mindset, we don’t just adopt new technologies, we elevate the entire organisation.

So take this as your reminder: you don’t need all the answers, you don’t need perfection, and you certainly don’t need to pretend. What you need is curiosity, courage, and the willingness to lead from a place of truth. The rest will follow.

This journey is only just beginning for all of us. And if we do it right, it’s a journey that will redefine what intelligent leadership looks like for the next decade and beyond.