The Tool You Didn't Choose
On Upskilling, Workarounds, and the Honest Question Nobody Asks
It starts with a rollout
At some point in almost every technology professional's career, a tool arrives that you did not ask for.
It comes with a training session, or a documentation link, or an enthusiastic message from someone in IT or leadership about how this is going to change the way we work. It comes with good intentions and a business case that made sense to someone, somewhere, at some level of the organisation.
And then you open it.
And it is harder than it looked.
Not broken. Not useless. Just not intuitive in the way the tools you have built muscle memory around are intuitive. The mental models you have developed over years of working with other platforms do not transfer cleanly. The thing you used to do in two clicks now takes five, in a different order, in a different place, with a different name.
You push through it. You watch the tutorial. You ask a colleague. You figure some of it out.
But there is a question sitting underneath all of that which most people do not say out loud.
The question nobody asks honestly
You are not the only one finding this difficult.
That is not a consolation. It is a data point worth taking seriously. Poor adoption results in wasted software investments, decreased productivity, and increased support burden. 79% of organisations face challenges in adopting new tools — and that number has been growing year on year. The gap between a system going live and a system being genuinely used is one of the most persistent and least discussed problems in technology.
But behind those statistics is a very human experience. The experience of being handed something complex, being expected to become proficient in it, and having to make a real decision about how to spend your time and energy.
The decision is this: do you go all in, or do you work with what you have?
Do you commit to learning the tool the way it was designed to be used, even when that means pushing through significant friction, relearning habits that were efficient in other systems, and accepting that your productivity will dip before it rises again?
Or do you learn enough of the tool to function, fill the gaps with approaches you understand and control, and maintain your effectiveness in the short term while the organisation figures out whether this rollout is actually going to stick?
Neither of these is obviously right. And the fact that most rollouts never surface this question explicitly is part of why adoption so often stalls.
The cost dimension that gets left out of the conversation
There is another layer that makes this more complicated.
Many enterprise tools carry cost implications at the feature level. Certain capabilities sit behind higher access tiers. Some actions trigger usage charges. Integrations that would make the tool genuinely useful require licences that not everyone has, or approvals that take longer than the deadline you are working to.
So the tool you have been given is not quite the tool that was demonstrated. It is a version of it, shaped by what the organisation was willing to spend, what level of access your role was assigned, and what the procurement team negotiated.
This is not unusual. Budget overruns from digital transformation impact 30% of businesses, and complexity of current environments is the top challenge, affecting 38% of organisations. The gap between the tool as it was sold and the tool as it is experienced by the person doing the actual work is real, and it is wider than most rollout plans account for.
What it means in practice is that the upskilling question is not just about effort and time. It is about upskilling into what, exactly? Into a full version of a tool that your access level does not give you? Into capabilities that carry a cost every time you use them? Into a workflow that works for the power users the tool was designed around, but does not quite fit the volume and type of work most people on your team are doing?
The divide at the centre of most rollouts
This is the real issue, and it deserves to be named clearly.
Most enterprise tools are adopted because they serve a specific use case well. A set of power users who need deep capability, who have the technical appetite to learn a complex system, and who will extract significant value from features that the majority of users will never touch.
The organisation sees that value, rightly, and invests. The tool gets rolled out broadly. And then the majority of users — the people doing the everyday work that the organisation actually runs on — are handed something that was not really designed for them.
92% of the C-suite are actively cultivating AI elite employees while 60% plan layoffs for non-adopters. That statistic is about AI specifically, but the dynamic it describes is not new. It is the same dynamic that plays out with every major tool rollout: a tiered reality where some people thrive with the new system and others spend their days managing the gap between what the tool does and what their job needs.
Studies show that 50 to 63% of CRM adoption initiatives fail, mainly due to process misalignment and poor usage, and not the technology itself. The tool is rarely the problem. The fit between the tool and the actual work is the problem.
So how do you proceed?
There is no universal answer to the upskill-or-supplement question, but there are some honest considerations worth working through.
What is the trajectory of this tool in your organisation? If it is genuinely going to become central to how work gets done, the cost of not learning it will compound over time. The friction now is real, but so is the risk of falling behind a system that the organisation is building around. In that case, the investment in full upskilling is probably worth the discomfort.
What does your actual work require? If the tool covers 60% of what you need and you have reliable ways to handle the other 40%, a pragmatic hybrid approach is not a failure of ambition. It is a sensible response to a real constraint. The goal is the work, not the tool.
Are your workarounds sustainable and visible? The danger with supplementing a tool with your own approaches is that it becomes invisible to the people who made the adoption decision. If your workaround works, nobody asks questions. The feedback that would help the organisation understand the gap in the tool never surfaces. That is worth being deliberate about.
Who else is in the same position? If you are finding the tool difficult, others almost certainly are too. The most useful thing you can do — for yourself and for the organisation — is to make that visible. Not as a complaint, but as a legitimate signal about fit. OpenAI's 2025 State of Enterprise AI report documents a 6x productivity gap between power users and average employees using the same tools. That gap does not close through individual effort alone. It closes through honest conversation about where the tool works and where it does not.
The question the organisation needs to ask
Most of this conversation happens at the individual level. Person by person, each working out their own relationship with a tool that was handed to them.
But the more important conversation is the one that organisations rarely have with enough honesty before the rollout.
Who is this tool actually for? Who will use it every day, for what tasks, with what level of technical comfort? What is the realistic upskilling path for the majority of users, not just the enthusiastic early adopters? What will people do when they hit the limits of their access tier, or when a feature they need carries a cost they were not told about?
Gartner predicts that 70% of large enterprises will adopt Digital Adoption Platforms by 2025, but many users still rely on outdated processes due to a lack of in-workflow support. Buying a platform to help people adopt a platform is a signal that something in the original adoption plan was incomplete.
The tools that genuinely transform how organisations work are not the ones with the most features. They are the ones where the distance between what the tool does and what the people need is small enough to close through reasonable effort. Everything else is an adoption programme waiting to fail.
A personal reflection
I have been in this position more than once. Handed something new, expected to get up to speed, navigating the gap between what the tool promised and what it delivered at my access level, in my context, for my actual work.
What I have learned is that the either-or framing — full adoption or workaround — is usually a false choice. The more useful question is: what does this tool do genuinely well, for my work, right now? Start there. Build fluency in those parts first. And be honest, with yourself and with the people around you, about where the gaps are.
Because the gaps are not a personal failing. They are information. And in most organisations, that information is exactly what is needed to make the next rollout go better than this one did.
Closing thought
The conversation about tool adoption is almost always framed as a change management problem. How do we get people to use the new system? How do we overcome resistance?
But resistance is rarely the real issue. The real issue is fit. And fit is a two-way problem.
It asks something of the person using the tool, yes. But it also asks something of the organisation that chose it. Were the right people in the room when the decision was made? Was the everyday user's experience part of the evaluation, or just the power user's? Was the cost of genuine upskilling factored in, honestly, alongside the licence fee?
Those are the harder questions. And they are the ones worth sitting with before the next rollout lands in someone's inbox with an enthusiastic subject line and a link to a tutorial they will watch once and never find again.
Have you been handed a tool that wasn't built for how you work? How did you navigate it?