This is an insight that struck me recently, though it’s hardly new. In fact, anyone working in marketing or public relations will tell you the same: people, as individuals, are intelligent. People in groups, however, can behave in very odd ways.
So how does this play out in the corporate world? It often comes down to the gap between how small groups of experts expect people to react and how large organisations know people actually react.
Take something as simple as installing software. If you give a set of instructions to technical experts or developers, they’ll follow them making intuitive choices along the way. Rarely will anything need spelling out. The target audience will just handle it.
Now compare that with giving the same instructions to the general public. Suddenly you need to specify every click, every option, every screen. What feels like minutiae to an expert is essential detail to ensure success for the rest of humanity.
Now you have this understanding, you can explain it to your experts as they will often wonder why corporate infrastructure demands such exhaustive, step-by-step detail. To the expert, it feels pedantic, even pernickety and pointless. But for a corporate support team, responsible for thousands of people with widely varying levels of knowledge it is just dealing with a very broad baseline of humanity.
Because in that large, mixed pool of users, someone will get it wrong. Someone will click the wrong thing, misread the obvious, or inadvertently cause chaos. And if support hasn’t built in the safeguards, they’re the ones left cleaning up the mess.
So next time you find yourself rolling your eyes at “silly” questions from corporate support, remember: they’re not being awkward. They’re working to a broader baseline of understanding, one designed to prevent the inevitable finger-pointing blame game from happening
Now that we have all got over the initial flurry of being astounded by AI chatbots and their very human way of handling conversations, a lot of clients and companies are moving on to the serious, practical side of implementation. Everyone seems to want to fit AI into everything, and once you reach this stage, the excitement quickly gives way to the realisation that most of the challenges you face in getting it to work are the same old ones we have always faced with integration and software adoption.
To be honest, I personally find chatbots, while amazing, don’t quite beat the real thing. If you have ever worked in a company with helpful colleagues, it is impressive that a computer can do that job, but the function itself is not new. What is amazing is doing it at scale. Instead of asking ‘Janice in Finance’, you ask an AI, and an AI can answer thousands of people at once.
And here is where we hit the same old problem; even ‘Janice in Finance’ isn’t a divine miracle, so how does she do what she does, and how can we get AI to do the same?
The first issue is data. Have we given the AI all the data it needs? Have we given it access to live sources, or are we expecting miracles from a one-time data load? Have we structured the data in a way that makes sense? Just dumping it into a database without context or rules will not work. AI needs to know how information connects in order to make useful deductions. and while there are incredible tools that can help with this, when it comes to making assumptions, particularly financial or legal ones, the wrong connections or lack of context can quickly become very dangerous. This has been a problem since long before AI.
The second issue is workflow. Once you have gone past the novelty of “oh, this is a chatbot”, if it does not fit into the user’s normal workflow, they will not use it. Make sure that any new AI features work within existing processes. This not only helps adoption and avoids unsettling users, but failing to do so actually takes away some of AI’s advantages. For example, if you are assessing whether an insurance claim is potentially fraudulent, that used to be done using a set of complex but static rules which produced a percentage likelihood. AI can now perform that calculation far more accurately, but you do not need to change the interface at all. It simply improves what the user already sees, which is exactly how good AI should feel: an invisible improvement that makes the job easier without disrupting needlessly.
The third issue is adoption. Forcing new features onto people drives them mad, even if those features are shiny and fashionable. It makes users nervous, and they start to see change as a threat. There are thousands of books and experts on adoption because it is a very old game. My least favourite part is when senior leaders believe the technology will replace staff and start talking directly to business teams about “efficiency gains”. This immediately puts people on edge. AI already carries an overtone of job replacement, so pushing it from the top without the right tone can do real harm. It needs to feel like an aid, not a threat.
Finally, there is the way we introduce AI. Making a big song and dance about any new technology might be great for publicity, but it rarely impresses the people that do the work day to day. Pitching AI as something that makes people’s lives easier and helps them do their jobs better works far more effectively. It should be seen as a tool that helps teams perform better and, ideally, be rewarded for it. Declaring “AI is here, the world will never be the same” is exactly how you generate resistance and backlash. Features will be viewed as threats rather than improvements, and that helps no one.
In short, make sure any AI you introduce actually adds value rather than simply being “the new hotness”. Even though AI is a fundamentally transformative technology, from your users’ and business teams’ point of view it is still just another software adoption process. Use all the lessons you have learned over the years to make it as seamless as possible.
There’s a useful analogy I once heard from musicians about how orchestras really work. Officially, the conductor runs the show. They set the beat, they give the cues, and everyone’s eyes are on them. To the audience, it looks as though the conductor is firmly in control.
But orchestras have their own quiet safety net. If the conductor is incompetent, unreasonable, or simply fails to lead, the orchestra doesn’t fall apart. Instead, it starts following the lead of the “first trumpet” 1. The clever conductors will realise this, and self-aware ones take it as a sign: if the orchestra is following someone else, something has gone wrong in their leadership.
Most of the audience will never notice the shift. They’ll assume the conductor is still in charge. But the musicians know, and so do the more experienced listeners.
I think this is the best analogy I’ve ever come across for corporate projects. If you’re the project lead, the “conductor”, and you find that people are no longer coming to you with problems, or that you’re having to chase rather than being sought out for help, chances are you’ve already been quietly replaced by a “first trumpet”.
This isn’t a role that anyone really wants. It’s an extra burden on the person who has stepped up, often reluctantly, because the team still needs direction. The only real solutions are for the formal lead to:
Step aside.
Fix what’s going wrong,
Replace the “first trumpet”
If you suspect this has happened to you, the best thing you can do is find out who your team is actually following and ask them genuinely where you’ve gone wrong. They’ll usually tell you, because they don’t want your job; they’d much rather you were doing it properly.
Projects, like orchestras, need a conductor. The trick is to remain the one the team chooses to follow.
Update
I got some feedback on this from an old friend and it looks like the origin instrument suffered a little bit from Chinese whispers, and rather than “First Trumpet”, it should really be “Lead Violin”
“As a trumpeter, I would love to say this was true, but it’s really the Principal 1st Violin, who also has the title “Leader” for this very reason. Three reasons for that choice:1) the violinist is at the front where everyone can see them 2) it’s easier to follow their bow movements than it would be to follow any movements made with a trumpet 3) they are playing most of the time (unlike the trumpets) so there’s something to follow”
“I’ve certainly played in concerts where this happened… if you go back a few hundred years, conductors weren’t a thing, and orchestras were usually led by someone playing – often the harpsichord. Most jazz bands still run this way. I guess you don’t need to go back that far to find a dev team without a scrum master of whatever they’re called…”
For those of us working inside the corporate machine, the final quarter of the year is often dominated by budget planning for the next yeah. This is when large organisations decide which major projects will run, which teams will be involved, and crucially for me whether contractors such as I will be needed.
Typically, permanent staff are considered first. Then, if gaps remain, large consultancies are brought in. Only after that do opportunities filter down to individual contractors or smaller specialist consultancies. That’s where I fit in and find myself reflecting: am I genuinely worth my rate?
Market Rate vs Real Value
The obvious starting point is the market. Contractors usually pitch themselves against the “going rate” for their role, be it developer, architect, or project manager. A premium might be added for rare technical skills or specialist industry knowledge, but ultimately the rate is dictated by market forces.
However, I’ve always found it useful to go a step further: to retrospectively assess my contribution to a client over the past contract. Were they right to invest in me? Am I providing value worth the money they’ve paid? And importantly, should my rate or approach change next year? Ways to Measure Your Worth
1. Generating revenue
The simplest measure is whether you’ve directly made the client money. For most of us, that’s rare, we’re not in sales. More often, contractors work in support roles or on projects that enable revenue rather than directly generate it.
2. Saving money
This is where many of us can point to clear results. In my integration work, for example, I’ve seen countless occasions where vendors clash or timelines collide. Simply being there to intercept issues, keep projects on track, and prevent failed go-lives has saved clients significant sums.
There are also tangible savings in areas like regulatory compliance. If you’ve helped avoid a breach, spotted a costly error, or found a cheaper way to achieve the same outcome, then you’ve delivered measurable value.
3. Soft Value
Beyond the numbers lies the more nebulous question: what would have happened if I hadn’t been there?
Would the project have succeeded anyway? Or would it have collapsed, with all the associated costs?
Does the client notice when you’re away on holiday, or does everything run more smoothly?
If things improve without you, that’s a sobering sign. But if projects stumble in your absence, it underlines your contribution.
Being Honest with Yourself
I make it a habit to ask myself each month: am I worth what the client is paying me?
There have been times when, after a few months in a role, I’ve concluded I wasn’t adding enough value. In those cases, I’ve actively asked for additional responsibilities, seeking ways to make a bigger impact. Far from being risky, clients usually appreciate this attitude. It demonstrates self-awareness and commitment to their success.
Thinking Long-Term
Contracting isn’t just about filling today’s gap, it’s about building long-term relationships. I’ve returned to some clients three or four times over the years, precisely because they knew I delivered value for money. In a surprisingly small industry, reputation and repeat engagements matter more than many realise.
So as year-end approaches, take the time to reflect. Imagine your client asking: we’ve paid you all this money, what have you done for us? Was it worth it?
If the honest answer is “not enough”, then adjust. Upskill, take on additional responsibilities, or find ways to make yourself indispensable.
Because at the end of the day, being a contractor isn’t just about market rates, it’s about proving, time and again, that you make your client’s business better.
