Corporate term: “Toxic White Knight Syndrome”

Posted on by Mark Myers Leave a comment

Definition

Toxic White Knight Syndrome is a behavioural pattern in which an individual becomes so enamoured with “riding to the rescue” of a situation that their intervention ultimately creates friction, resentment and inefficiency. Rather than enabling progress, the self appointed saviour can intensify conflict, undermine those already doing the work, and obstruct practical solutions.

Explanation

A more personal definition than what I might usually offer, but it reflects a recurring dynamic in many professional environments.

Much of my own work comes through recommendation. When I have previously helped fix things, people have passed my name on, and I am then brought in to help resolve a new problem. However, one crucial principle is to avoid presenting yourself as a white knight. Doing so risks alienating the people already embedded in the situation, often working tirelessly and under significant pressure.

In practice, a white knight is rarely helpful. You should be judged on results, not heroics. When entering a struggling environment, your role is not to posture as a rescuer but to act as someone who takes the blame and gives a bit of breathing space so that other people can get the work done.

In many cases, when I am asked to “fix” a failing area, the real issue is not a lack of effort or competence. There are almost always capable people on site who are already working their guts out. The difficulty is that they are so occupied with resolving operational challenges that they have little time to communicate progress, constraints or delays to stakeholders. More often than not, the root cause is a breakdown in communication.

The solution, therefore, is not dramatic intervention. It is to surface and clarify existing efforts, highlight measurable progress, support the removal of bottlenecks, and ensure that stakeholders understand what is being done and why. Quiet admin achieves far more than theatrical rescue.

Departments can also suffer from a collective form of white knight syndrome. This is particularly common in audit, compliance or oversight functions, especially where performance is measured by identifying faults. When recognition and advancement are linked to exposing failures, a culture can develop in which individuals seek out errors in order to claim victory. The “I found the problem; therefore, I fixed it” narrative, often delivered through an impressive presentation, can be rewarded even when it breeds resentment and discourages collaboration.

Such cycles produce little more than defensiveness and internal competition. Everyone wants to be seen as the saviour. Few want to do the unglamorous work that sustains long term improvement.

Breaking this pattern requires a calm, steady, process-driven action plan far more than reactive heroics. Listen carefully to both stakeholders and the people doing the work; acknowledge their concerns and find solutions; document actions; and convert effort into clear deliverables. Strip away the drama. and make progress visible.

Ultimately, toxic white knight syndrome thrives on attention and recognition. It fades in environments where steady results, collective effort and transparent communication are valued above individual grandstanding.

Disclaimer: As always these posts are not aimed at anyone client or employer and are just my personal observations over a lifetime of dealing with both management and frontline associates.

Stripping AI Back to Basics

Posted on by Mark Myers Leave a comment

The more I dig down to the coding roots of artificial intelligence, the more I see how it’s portrayed badly. The sheer complexity of its variations is often what makes much of the media coverage and commentary fluffy and difficult to make sense of. Things are either totally absent from the conversation or massively overstated.

On one side, we hear that AI will fix the entire world, usually from those investing in it. On the other that, it will destroy the world, often from those who fear it will damage their livelihoods. What is frequently missing is a discussion about the practical realities. 1

One of the most useful ideas I have taken from the course I am currently working through is this: 

A large language model is essentially the average of the internet at a given point in time, based on the data available to it. It is a snapshot of that collective content. As a result, it tends to produce the average of what it has seen.

This helps explain why very senior managers and decision-makers in specialist fields often find it so impressive.

Imagine you are a high-ranking director in a marketing company. You own the business, but you do not personally carry out day-to-day marketing work. You write a piece of marketing copy and ask AI to improve it or turn it into a banner. You receive a result that is noticeably better than your original draft. But because actually writing marketing copy is not your core discipline (you are a people and finance manager), the output feels great.

However, what you have received is not brilliance. It is the average of what the model can produce based on its training data. If ‘average’ is all you need, and you need it consistently, that can be perfectly adequate, and AI is perfect for you.

Now organisations can improve results by feeding AI more relevant information. Take insurance as an example. If you want AI to act as a claims handler and assess whether claims are fraudulent, an off-the-shelf model will initially reflect the broad average of internet knowledge. But if you provide it with your historical claims data, including cases that subject matter experts have identified as fraudulent and the reasoning behind those decisions, performance improves.

Even then, it will only ever reflect the average of what your company has historically done. That is the key point.

There is a great deal of discussion about AI learning. In reality, AI models learn from human-generated data. They can extrapolate faster and at a greater scale than people, but they do not possess judgement in the human sense. They are bound by patterns in the data they have been given.

It is excellent where you want a consistent, nearly repeatable, broadly competent output. It reduces peaks and troughs. It gives you a solid baseline answer time and time again.

If you want true excellence in quality, AI on its own will not deliver that. It can enhance your experts by giving them a strong starting point rather than a blank page. Your specialists still need to review, refine and apply judgement.

Note: I have not suddenly become an AI expert; I am just elbows deep in the very serious “end-to-end AI engineering” by Swirl AI. I would recommend it to anyone that wants to get past the glossy rubbish about AI.

  1. Not the environmental ones; we all know they are a nightmare.[↩]

Solid Security Is Still Relevant in the Era of AI

Posted on by Mark Myers Leave a comment

As I learn more about proper AI and dig down into its components, the more the old fundamentals seem to hold firm. One of the things that has become increasingly clear is how you should apply security and access controls when working with AI systems. A common mistake is giving an AI access to data it should never see.

AI interacts with the world through what are called tools. These are simply a new posh term for abstraction layers. A tool might be a snippet of SQL, access to a dataset, a link to an external service, or almost anything else the AI can use to answer your query. The AI is designed to choose the most appropriate tool, but the security boundaries must be built into the tools themselves.

For example, if you have a tool that queries a SQL server, the data that the AI agent can access should be restricted at the tool level, not at the AI agent level itself. You would not rely on the AI to write a query that says, get all the data about hamsters but ignore the data about rats. If the two datasets have different security requirements, the tool should only have access to the hamster data in the first place.

AI actions are not hard and fast. They are probabilistic rather than deterministic, which means you cannot rely on a large language model to consistently make the correct security decision for you. Traditional security principles still apply, especially least-privilege access and strong boundary control.

In the era of AI, the technology may be new, but the security fundamentals remain exactly the same.

Note: I have not suddenly become an AI expert; I am just elbows deep in the very serious “end-to-end AI engineering” by Swirl AI. I would recommend it to anyone that wants to get past the glossy rubbish about AI.

A Year in Review, 2025.

Posted on by Mark Myers Leave a comment

This year has possibly been the most complex soft skill learning year I have ever had.

A lot of what I deliver for clients is highly technical, which is both a joy to learn and relatively easy, and because I have spent my entire life playing keep-up with technology, it’s familiar ground.

This year, though, has brought a great many eye-opening lessons in areas that were far outside the usual. Everything from lots more finance work to extensive vendor negotiation has landed on my plate.

Normally I am brought in to fix problems caused by existing failings rather than set things up, but this year included complex, near-legal discussions on statements of work and costings. There was also a huge amount of cross-departmental paperwork aimed at understanding how large scale projects function inside giant multinationals, something of a black hole and easily as complicated as any technical delivery.

In addition to these finance areas, there have been a great many true soft skill lessons. I have had the privilege of working closely with people managing real accessibility challenges and have seen firsthand how they often work three or four times as hard as the rest of us simply to get through the working day. While we should agree that everyone should have equal opportunity regardless of disability, actually working alongside people facing these barriers has been eye-opening. They consistently put in more effort and represent extraordinary value to any corporation. It’s been a humbling experience all round but very rewarding.

The technical side has continued to grow at pace. I have had to pick up a lot of serious AI knowledge, so much so that in the coming year I am taking external courses to formalise it. There is such an overwhelming amount of fluff being pushed on AI’s supposed value that you reach the point where you must actually code solutions to really see how things work. It is good to get back to that and cut through the marketing bullshit. There has also been a strong swing towards Azure in my day-to-day work rather than AWS, purely due to the current client environment. The reality is that the three major cloud providers all move so quickly that you have to run to simply keep up.

Looping back from cloud to finance, there has been a lot of joined up learning. Everyone uses cloud services now, but many still fail to notice that day-to-day cloud costs are often higher than on-premise solutions. Nor does being in the cloud guarantee decent technical redundancy. Even highly skilled teams overlook painfully obvious risks. My favourite example this year was discovering a client relying on Azure private endpoints for multi-region disaster recovery, without realising that a full regional outage removes private endpoints entirely, meaning their multi-region DR would not work. At scale, cloud architecture is still not a mature discipline.

Next year has already made it clear that it will require a different set of expertise to 2025. Many major corporations are moving back towards pre-Covid behaviours, and while that shift was not obvious during the early days of the new world of supposed permanent remote working, it is now becoming very real.

Neither my partner nor I ever truly believed that everything would remain fully remote or that corporate life would permanently become looser and more relaxed. Because of that, we leaned further into central London. With the majority of clients now wanting people back on site, this has turned out to be a genuine advantage. It means I can be present whenever clients need me, suited and booted, and delivering what they require where they require it.

From a delivery perspective, it looks like security will once again occupy a significant part of my working life this year. This ties directly back to the last major wave of cloud adoption. Most organisations have now gone through their last big push to cloud services. Many no longer have any data centres at all, with leases expiring and on-premise estates being fully retired. A huge number of features and platforms have been moved over in a relatively short space of time.

Now, however, the costs are arriving. With that comes a level of wrangling that would not normally have taken place when teams were more rigidly siloed. Finance, security, architecture and delivery are all battling around the same conversations, often for the first time.

Working through this will require a mishmash of technical expertise and soft skills. There are many very clever people involved, all with strong opinions. Navigating those views, whether from finance, security, or pure functional practicality, is going to be a real roll-your-sleeves-up kind of challenge.

All in all, 2025 was real brain work and 2026 looks even harder