A Reddit answer is a type of reply to a question that does not address the issue directly and instead suggests that the original problem should have been avoided by taking a different approach entirely. It often appears in online forums and communities (hence why it is named after the Reddit website), where the responder proposes an alternative path rather than engaging with the question asked.
Explanation
Reddit answers typically arise when someone asks for practical help, only to be told that they should have made a different choice at an earlier stage. e.g., a question about fixing a Windows 11 feature might receive a reply recommending the use of Linux. Although such responses may reflect personal preferences or enthusiasm for a particular technology, they offer little assistance to the person seeking a specific solution. As a result, Reddit answers are seen as unhelpful diversions that overlook the actual problem someone is trying to resolve.
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.
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.
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.
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
I have mentioned it before, but there is something that I like to call the golden hour in any multinational organisation. This is a particular time during the day when you can get the three major corporate time zones, 1 all on a meeting at the same time.
It is normally somewhere between 1:30 and 3:30 UK time. You get an awful lot of large-scale broadcast meetings during this window because it is the only period where everybody is technically available. What this really means, however, is that a lot of important things that people should be paying attention to are all happening at once.
At most clients over the last decade I have seen the same pattern. You will have multiple repeat meetings that you really do need to attend in conflict with lots of other ones of equal importance, plus lots of individual team standups for projects that are cross-region. You would think people would handle this sensibly. Do not book a meeting when people are not available. But a lot of the time the big meetings are aggregate meetings. For example, you might have a weekly meeting where all projects review cloud costs, or where all projects are invited to work through delivery timelines, outages, or similar topics. They pick the time where everybody could theoretically attend because there are fifty, sixty, or more people on the call. In reality, there is never a chance they could all attend, so the meeting is booked in the slot where, in theory, they could.
The inevitable result is that people miss things. Yes, there will be follow-up communications, but the crucial detail you actually need may be buried in a single PowerPoint slide. In a PowerPoint deck of fifty, sixty or seventy slides, attached to an already crowded inbox, you are going to miss things. When enough major communications happen in this way, multiple people miss the same information.
Unfortunately, this is how you end up with something going wrong and the inevitable question is asked, ‘Why was I not informed?’ The answer is usually that it was in an email somewhere.
This is simply a warning note. You either need to protect this time window so that only one or two major calls are scheduled into it, or you need to challenge the approach and ask for communications to be split into regional time zones. As a PM or manager, this is your danger zone. You have to watch it constantly and, stressful as it feels, try to track all the individual updates that might affect your delivery when they arrive as general blasts during this period.
