The technology works. The organization is busy, the data is messy, and nobody knows who has to approve what.
So I manage the absorption, not the technology. My job is to remove what stands in the way.
Every week spent on preparation before launch saves a month of recovering from a bad first impression.
Most companies buy the tool and start the rollout the same week. Then they get stuck, and they blame the tool.
Four things to sort out first. Ideally before signing. If the contract is already signed, then immediately.
These tools index what you point them at, faithfully. Point one at ten years of abandoned projects and outdated documents, and it will surface all of it, confidently. Users try it twice, get bad answers, and decide the AI is bad. It isn't. The data is. That judgment forms in week one, and it is expensive to undo.
A constraint you find in month two is a blocker. The same constraint found during evaluation is just scoping. Start by naming your one absolute limit in writing. The one I have seen work best is that customer data never enters the platform. That single sentence resolves dozens of later arguments faster than any policy document.
"Native connector" is a spectrum, not a yes or no. What matters is how many customers are already running that specific connector at your size, with your login system. Ask for that number. Ask to speak to a customer whose setup went badly. Then test your two hardest integrations in your own environment before you sign.
My cleanest integration, with a motivated team and no surprises, took thirteen weeks. Plan on a quarter per meaningful integration and be pleasantly surprised.
Security review is not what slows AI down. It is how you get to do more.
The thing I got wrong first: I tried to shorten the process by asking security to approve whole categories at once. It was rejected, and rightly. You cannot speed up a review by asking for less review.
What worked was realizing the reviewers were not blocking us. They were waiting on facts nobody was gathering. Their questions were always practical. Can a user turn off a required confirmation? Whose account does the action run under? Does the log record it correctly?
So I stopped sending requests and started sending evidence. Tests run in our own system, with screenshots. One success, one cancellation. Written confirmation from the vendor. Reviews that had been stuck started moving.
Two things that help. Ask for access for a small group of named people rather than everyone, because a small group is easier to say yes to and gives you proof for the bigger ask later. And run the parts you can test yourself in parallel with the parts only the vendor can answer, because most of the delay is one person waiting on the other.
One thing worth knowing early: some reviews stall because facts are missing, and some stall because people genuinely disagree about how much risk is acceptable. Evidence fixes the first kind. Nothing fixes the second kind except a decision from someone senior. Telling them apart in week one saves months.
Enthusiasm is free. Effort is expensive.
Programs built on the belief that interest turns into action fail quietly, and they look healthy the whole time.
Sign-ups, attendance, and logins describe an audience. Demos given, workflows changed, and tools people built describe a program. Change what you measure and behavior follows.
I leave the client running it themselves: the weekly rhythm, the evidence pattern for security, the record of vendor commitments, and a measurement system that tells them the truth early enough to act on.
At a consumer tech company, adoption of an enterprise AI search platform went from 23% of employees to 87%, and held steady there.
It was not a spike. It rose steadily, and it rose each time we unlocked another connection and taught another group how to use the platform and build their own tools.
That is the part most people miss. Adoption was not limited by how convinced people were. It was limited by how useful the tool was to them yet. Every approval we cleared made it useful to another part of the company, and that part adopted.
Which means the governance work and the adoption work are the same work.
I map what you have bought, what is actually connected, and what is stuck. I talk directly with your security and legal reviewers. You get a written picture of where the real blockers are, which is usually not where people think.
I run the clearing work. Integration testing, security evidence packages, the weekly rhythm with your teams, and the measurement system that tells you whether any of it is landing.
Your team owns it. The rhythm, the evidence pattern, the vendor commitments in writing, and a measure of adoption that reflects use rather than sign-ups.
No overhead, no long-term commitment.
