A slightly odd, old-fashioned practice that I have always favoured as a long-term contractor is that favours, praise and rewards should be reserved for permanent members of staff, not contractors.
As a contractor, you receive your remuneration directly in the form of money, so you should not really need anything additional. Yes, public praise can be nice for your reputation and can help with securing future work, but I have found that it does not need to be displayed openly. Merely having a list of people for whom you have done excellent work and who remember that tends to be the best long-term reward. Public recognition further up the ranks is not really necessary.
Although this may sound like an odd, humble brag or slightly self-effacing view, it is one that has some basis in history. During and before the First World War, some military traditions treated medals and formal rewards as things intended primarily for career soldiers, where they could support rank, status and advancement. The thinking was that such honours were, in a sense, less useful when given to conscripted soldiers who would only be with the regiment for the duration of that conflict.
I have found that the same broad idea can help with contractor and permanent staff relations. Contractors should not really be receiving extra rewards, such as public praise or internal recognition, because they are already being rewarded through their rate and contract. That recognition is often better spent on permanent staff, for whom it can support morale, career development and a sense of belonging.
This is only a personal viewpoint, but it is one that has stood me in good stead.
I am currently sitting in that little used reception area that every giant corporate building seems to have for guests who are waiting for someone to come down and collect them. You know the sort of place: odd potted plants, huge chairs, and the sense that it has been designed to be used as little as possible.
The reason I am sitting here at the start of my working day is that I left my pass for this client on my desk at home because I am an idiot.
While sitting here, I assumed I could simply go to security, explain who I was, identify myself, get a temporary pass printed, and head upstairs to work. However, I was wrong. Those days no longer exist.
Autonomy by individuals, particularly in well-established service roles or roles seen as replaceable, has become massively limited, and it has become noticeably worse over time. Gone are the days when security guards would really know you. I normally know most of the security guards, cleaning staff, and the other support people who appear in the office at the same time as I do, which is usually about 6:30 in the morning. But they are all kept in very rigid boxes, because that makes them easy to replace with no impact on the smooth running of the building facilities.
And here is the nub of it: that also makes them easy to replace with non-humans.
I think this is one of the core and genuine worries about AI. Yes, there will always be things that require a human touch, and there will be things that robots have not yet mastered. But by allowing work to become so regimented, with such fixed boundaries around its deliverables and such an absence of adaptability, we have set ourselves up to be easily replaceable by AI and similar systems.
So if your job has very strict boundaries, very strict deliverables, and does not reward innovation or adaptability, then I think you are in the area of humanity that should be most worried about being replaced. That does not matter whether you are in the service industry, deeply technical, or anything else. If you cannot display humanity or any of its advantages during your working day, and if your work is bounded by strict borders with easily quantifiable inputs and outputs, then you are at real risk.
Historically, that risk meant being replaced by a cheaper human. I suspect that, eventually, it will mean being replaced by a cheaper non-human.
Let us step back and talk about General Electric, some 30 years ago, when the first major rounds of outsourcing were being done and call centre outsourcing was brand new. I started in a call centre doing help desk and support work, in an 800-person call centre in the middle of Leeds, Yorkshire. They were just beginning the first stages of outsourcing to India.
There was joking, of course, and there were practical issues. Postcodes were new to the country taking on the work, and they had to be explained. Training had to be done. Processes had to be documented. All that kind of thing, but it was still happening, and as a freshly hired person, I was worried that this was the beginning of the end when I had only just started, but a very clever person told me something that came back to me recently. Whether you can be replaced by another person, a piece of software, AI, or anything else comes down to a few simple things.
Can your work be wrapped in strict definitions?
Is it easy to encompass and define precisely?
When you do your job, do you simply deliver the average expected result?
That average delivery might not even be fully within your control. If there are exact SLAs to deliver against, and your job is simply to meet them, then you may already be in trouble. If the answer to these questions is yes, then you are at serious risk of being outsourced. Back then, that meant outsourcing to India. Today, it can mean outsourcing to AI, automation, or any number of other things.
So, how do we prevent it? Perhaps we do not. Perhaps the real answer is that we have to work with it.
Back then, I was told to make sure I was better than everybody else. Be value for money. Because regardless of what any company might say, value for money always matters. If you come in, do what you consider an ordinary day’s work, and nothing more, then you are at direct risk from AI. AI is, by definition, an average of what it has learned. If it uses the company’s internal data, it becomes the average of what that company has historically been able to do.
So if you are doing an average job, or even just a consistently good job within a tightly defined structure, you are at strong risk of being outsourced by something that can improve on average delivery. It can improve on cost, dependency, repeatability, and consistency.
The second question is whether your job is easily defined. The stricter and clearer the definition of what you actually do, the easier it is for AI to replace you. With traditional outsourcing, work had to be defined well enough for another person or team to take it on, but there would always be variance based on human understanding and interpretation. With AI, the better the definition, the easier the replacement becomes.
So now we know whether we can be replaced. The next question is how we adapt to the companies using AI to put that into practice.
I think the answer has to be defined at an individual level, rather than by industry or even job title. I strongly suspect that AI, just like outsourcing to cheaper countries, will eventually be able to do a large amount of non-physical, interaction-based, white-collar work. We are not going to win by pretending that will not happen. The Luddites did not stop progress by burning down machinery, and we will not stop this by simply objecting to it. Progress will march on.
So how do we deal with it?
We deal with it by using the default that AI provides as a stepping stone to become exceptional.
That is going to be hard in a number of areas, particularly where there is wholesale outsourcing or where there are hard definitions of what is absolutely correct. Copy editors are having a very difficult time at the moment, because their job is to make something complete and correct. If AI can do that, it is hard to go over and above to prove your value.
But for work that involves any form of soft skill, from customer service to facilities, management, consultancy, or technical delivery, we are going to have to produce better than average. That does not mean giving every hour of your life to various corporations. It means recognising that they will be able to supply the average through AI. You will have to remove the base part of the work and focus your effort on what AI produces, then improve it, shape it, and add value beyond it.
The main difference between historical outsourcing and AI outsourcing is the turnaround cycle. It is also about whether your improvements are learnt and absorbed by the AI.
For example, if your work was outsourced to another country, the comparison was whether you were better at the job than the outsourced team. As you learned and improved, you might have been able to stay ahead. They might have improved too, but there was still a human and organisational delay.
With AI, it may only be able to produce the best average result that all the data in your company can support. But it will constantly play catch up with you. That means you will have to keep re-referencing the baseline it produces. No longer will the question simply be, “Am I the best in the market?” The question will become, “Am I a meaningful percentage better than what the AI is already producing?”
That change will be particularly relevant to white-collar workers. I think they are especially vulnerable to this form of AI learning. But, ultimately, AI is here. The people with power see it as a way of producing better value for money with more consistency.
TLDR;
You are most at risk if you are an average worker doing an average day’s work, or if you are a white-collar worker whose output is easily defined and judged as either correct or incorrect. If there is softness in your delivery, use it. If your work requires judgement, adaptability, empathy, creativity, or context, keep developing those things.
Keep ahead of AI by using it as a starting point, rather than competing with it directly.
This post comes from watching two very different vendors, on two very different projects, handle a familiar situation. A project hits issues, the mood turns, and suddenly the vendor is no longer the most popular party in the room. What stood out was the contrast in how each vendor responded, and more importantly, how one of them managed to turn things around.
There are many times in delivery work where you can find yourself on the wrong side of client sentiment, and quite often it has very little to do with the quality of your work. Budgets change, and what was previously seen as good value suddenly looks expensive. Internal restructures happen, and contracts that once made sense are now resented. People move on, political dynamics shift, and you may have been brought in by someone who is no longer in favour.
Sometimes the issue is entirely external to your delivery. A change elsewhere in the organisation can make a project seem less relevant or less innovative. It is not your fault, but it is still your delivery, and that means you will feel the impact.
In these situations, the reason matters far less than the response. As a vendor or consultant, you are being paid to navigate this, whether it is fair or not. The question is how you handle it.
One option is to double down on delivery. That might mean absorbing additional cost, adding resources, or simply pushing harder to ensure the outcome lands well. In fixed price environments, some of this should already be accounted for, but there are times when you have to take a hit. Larger organisations often don’t opt for this type of response purely on short-term financial grounds, i.e., this year’s bonus. That is understandable, but it can be short sighted. Reputation has real value, and people have long memories. It is worth weighing the reputational cost before reacting defensively. In many cases, it is better to grit your teeth and deliver.
Secondly, do not get drawn into internal politics. As a vendor, your role is not to take sides. Stay focused on both the letter and the spirit of your delivery. Turning overly rigid or contractual in tone can be just as damaging as open frustration. Clients are looking for a quality service, not just a strict interpretation of a contract.
There will always be occasional clients who push too far, but they are the exception rather than the rule. In most cases, if you provide something they can confidently take up the chain and demonstrate as progress, you will remain in a good position.
Another practical point is resourcing. Some organisations respond to struggling projects by quietly rotating out strong people and replacing them with those who will simply maintain the status quo. This rarely helps. If anything, it reinforces decline. If a project is under pressure, it is worth putting strong people on it, or at least ensuring visible senior engagement. Even if the issue is largely political, visible commitment matters. It shows that you are taking the situation seriously.
Thirdly, look to the future. Even when a project is difficult, it helps to position it as a temporary setback rather than a defining failure. Talk about what can be improved next time and how you can work better together. That sense of continuity and investment can shift the tone of the relationship. If you demonstrate that you are thinking beyond the immediate problem, clients often respond in kind.
Finally, be careful in how you offer solutions or retrospective insight. When relationships become strained, it is very easy to slip into criticism. Phrases that imply fault or hindsight superiority will only escalate tension. It is far more effective to frame things collaboratively. i.e “If we had known this earlier, we would have approached it differently, and we can take that forward to the next project”. The aim is to reinforce that you are working together, not against each other.
In practice, much of this comes down to restraint. You will sometimes be blamed for things that are outside your control. That is part of the role. The vendors who handle it well are the ones who avoid becoming adversarial themselves, focus on delivery, and keep an eye on the longer term relationship.
Once the immediate tensions pass, and they usually do, those behaviours are what determine how well you work together going forward.
Although the title sounds cynical, this is not intended to be a cynical post. In my role across integration, security, and general problem solving in architectural and IT spaces, “that’s not my responsibility” or “that’s not our department” is one of the most common responses I hear. It is also, in many cases, a perfectly reasonable one.
So it is worth taking a moment to understand why this response exists, and then look at how to work through it in a practical and human way.
Why does this happen?
In my experience, this response is very rarely driven by malice or laziness. It is usually a rational reaction to long term consequences.
Taking responsibility for something in a corporate environment often means owning it indefinitely. Processes and systems can live for decades. What looks like a small favour today can turn into an ongoing obligation that requires budget, support, and accountability years down the line.
There are also risks. If something goes wrong, particularly where there are compliance or legal implications, the person or team that accepted responsibility may be held accountable. That is a serious consideration, especially if they were not involved in shaping the original solution.
The more complex or unclear an issue is, the more likely it is that ownership is undefined. At that point, it effectively becomes a hot potato. People are not avoiding work, they are avoiding inheriting long term risk without the ability to properly manage it.
So how do you get things done?
When you need something fixed or owned, and everyone is stepping back, there are a few practical approaches that tend to work. None are perfect, but each has its place.
1. Escalation
This is the blunt instrument. Sometimes you need to escalate to someone who sits across both areas and can make a decision.
It works, but it should be used sparingly. Overuse damages trust and can give you a reputation for frankly being a bit of a d*** or only caring about your side of any problem.
2. Providing budget or resource
This is often the most effective and least confrontational approach.
If a team is constrained by time or funding, removing that constraint changes the conversation entirely. Offering budget, a cost centre, or even additional resource can turn a “no” into “when do you want it”.
Clarity helps. “I can fund this, when can it be delivered?” is a very different discussion to “can you do this for me?”
3. Removing competing pressure
Sometimes the issue is not the work itself, but competing demands.
If you can help reduce noise around a team by handling or deflecting other requests, you create space for your work to be considered properly. It also demonstrates that you are contributing, not just demanding.
4. Taking responsibility yourself
This works more often than it should.
By formally taking ownership, even temporarily, you remove the long term risk for others. A simple, clear statement of responsibility can be enough to unblock progress, especially if it protects the other team from future audit or support obligations.
It is about giving people confidence that they are not inheriting unknown liabilities.
5. Formalising ownership
This is the most sustainable option, but also the slowest.
If responsibility is unclear, define it properly. Get agreement, document it, and ensure it is recognised at an organisational level. This allows teams to plan, budget, and defend their position in future.
It also creates a repeatable process. Once something has been formalised once, it becomes easier to apply the same approach again.
The most important part
Whichever route you take, there is one thing that matters more than anything else.
Clean up after yourself.
Do not leave behind unclear ownership, unmanaged risk, or hidden technical debt. Do not put someone in a position where they will be questioned months or years later without context or support.
Reputations in this space last a long time. People remember who made their lives easier and who made them harder. The industry is smaller than it appears, and those impressions carry forward.
Solve the problem, but leave things in a better state than you found them.
A delivery approach where just enough paperwork is produced to ensure the outcome is no longer your responsibility.
Explanation
A “Kafka” delivery is characterised by the creation of sufficient documentation to avoid genuine ownership of delivery. Rather than focusing on outcomes, effort is directed towards ensuring responsibility is diluted or transferred. The aim is to demonstrate that the work has been passed on appropriately, so that when issues arise, accountability sits elsewhere.
In practice, this results in multiple parties positioning themselves as intermediaries rather than owners. Work is handed off repeatedly, with each step supported by documentation designed to show that due process has been followed. The emphasis shifts from delivery to defensibility, where the primary concern is being able to evidence that it is not your fault, not your responsibility, and not within your remit.
Ultimately, this becomes an exercise in structured buck passing, supported by just enough paperwork to withstand scrutiny when accountability is questioned. The result is a delivery that appears active on paper, but lacks clear ownership and, often, meaningful progress.
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.
