The balance that is corporate standards

Posted on by Mark Myers Leave a comment

Security in any corporation is a long, drawn out balancing act. On one side, you have the security teams, who quite reasonably want to prevent anything unpleasant from happening to the company. They aim for a least-privilege model, where individuals have only the access required to do their job and nothing more.

On the other side, you have developers and users trying to get stuff done. They want flexibility, the freedom to build, test and promote as fast as possible. Their focus is on outcomes, whether that is generating revenue, delivering features, or improving performance.

Taken to extremes, neither approach works.

If you enforce only the bare minimum access across the board, you cripple progress. Teams slow down, and the company begins to feel rigid and bureaucratic. On the other side, leaving everything open in the name of speed is simply inviting trouble, particularly in a world where security threats are constant and evolving. The long term risks of that approach are difficult to nail down but often expensive to recover from.

So there has to be balance. In theory, this is where corporate standards come in. A need is justified from a business perspective, weighed against security and legal requirements, and a standard is formed that reflects that compromise.

In practice, however, the phrase “corporate standards” often is just used to justify an arbitrary standard.

To someone trying to deliver something new, it can sound like a closed door. It can imply that decisions have already been made, that they should not be questioned, and that the reasoning behind them is either unavailable or not open for discussion. When that happens, people do what people always do. They work around it.

Developers, in particular, tend to be driven and resourceful. If they are blocked without explanation, they will look for alternative routes to deliver what they are being paid for. That is how shadow IT appears, not through malice, but through frustration and a desire to deliver.

At the same time, it is not realistic to expose every detail behind a corporate standard. Some of those decisions are based on known vulnerabilities, internal limitations, or security considerations that should not be widely shared.

This is where a more pragmatic approach helps.

When denying a request or limiting access, it is often worth providing a brief, sensible explanation. Not a full breakdown of every risk, but enough context to show that the decision is considered and grounded in real constraints.

This does a few useful things. It treats the other party as a professional rather than an obstacle. It demonstrates that the standard is understood, not just followed blindly. And importantly, it gives people something to work with.

With even a small amount of context, a developer or business owner can frame a proper justification for change. They can ask for something specific rather than excessive. In many cases, they will request far less access than they initially thought they needed, simply because they understand the boundaries they are working with.

Corporate standards should not be a brick wall. They should be a guide that reflects the current balance between risk and progress. And like any balance, they need to be visible enough for people to work with, even if not every detail can be shared.

Get that right, and you deliver to the business without weakening security. Get it wrong, and people will find their own way around it anyway.

Corporate term: “Reddit Answer”

Posted on by Mark Myers Leave a comment

Definition

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.

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.

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