The line about the company owning the licenses while the vendor owns the practical knowledge nails why so many AI tools end up half-used within a year. To answer your question directly, on my last team it was an intake assistant to sort inbound requests by urgency, everyone assumed that needed a dev ticket when it was really just a well-tested prompt with a handful of examples attached. Were employees more hesitant to try building something themselves, or more hesitant to admit the fancy vendor tool wasn't actually solving the problem?
Definitely! I was about to make the same comment. Esp. since AI is going to be our future. Like the Internet. Might as well build the capability and grow into it with it so no one is left scrambling to upskill when it's too late.
Thank you for this. Owning the licenses while the vendor owns the practical knowledge names something I keep seeing with operators who bought the tool and still cannot change it.
The most important distinction here is between buying access to AI and building the ability to use it well. Domain experts shouldn’t simply receive a finished tool at rollout. They should help define the workflow, test realistic failures, and improve the system over time. That builds judgment and adoption together.
I also appreciate the boundary you draw: employees should own the problem and remain involved in design (that's how you kickstart adoption!), while technical experts own architecture, security, and high-risk implementation.
Great point Anita! AI adoption is not primarily a software problem. It is a learning-system problem. If domain experts are handed a finished tool, they may comply but then fail to communicate when it is useful, when it is wrong, or how it should improve. But when they help shape the workflow, test it against real-world cases, and stay involved, the organization learns. The other payoff is significant buy-in from all parties.
I think that’s where misses often happen, employees are involved in the process, simply told to use a new tool. Great points! I can tell you’ve seen it and lived it
I like the idea that building capability is different from buying a tool, even if it takes longer upfront. The vendor knows the software, but your people know the work.
The line about the company owning the licenses while the vendor owns the practical knowledge nails why so many AI tools end up half-used within a year. To answer your question directly, on my last team it was an intake assistant to sort inbound requests by urgency, everyone assumed that needed a dev ticket when it was really just a well-tested prompt with a handful of examples attached. Were employees more hesitant to try building something themselves, or more hesitant to admit the fancy vendor tool wasn't actually solving the problem?
Great point! I think there is a lot of pressure to use the tools your company provides regardless of whether or not they work or solve anything
Renting always backfires, sooner or later.
Only upskilling your own people allows you to compound
Exactly! Mike, I would love to feature a new guest post from you sometime in September
What a great piece, thank you for sharing! 🩷🦩
yes! 🙌
Owning capability beats owning a license every single time.
100%
Definitely! I was about to make the same comment. Esp. since AI is going to be our future. Like the Internet. Might as well build the capability and grow into it with it so no one is left scrambling to upskill when it's too late.
Always Build! It's the only way you learn!
Thank you for this. Owning the licenses while the vendor owns the practical knowledge names something I keep seeing with operators who bought the tool and still cannot change it.
exactly! It’s the AI version of the vertical supply chain ownership
The most important distinction here is between buying access to AI and building the ability to use it well. Domain experts shouldn’t simply receive a finished tool at rollout. They should help define the workflow, test realistic failures, and improve the system over time. That builds judgment and adoption together.
I also appreciate the boundary you draw: employees should own the problem and remain involved in design (that's how you kickstart adoption!), while technical experts own architecture, security, and high-risk implementation.
Great point Anita! AI adoption is not primarily a software problem. It is a learning-system problem. If domain experts are handed a finished tool, they may comply but then fail to communicate when it is useful, when it is wrong, or how it should improve. But when they help shape the workflow, test it against real-world cases, and stay involved, the organization learns. The other payoff is significant buy-in from all parties.
I think that’s where misses often happen, employees are involved in the process, simply told to use a new tool. Great points! I can tell you’ve seen it and lived it
Both Anita and Derek
I like the idea that building capability is different from buying a tool, even if it takes longer upfront. The vendor knows the software, but your people know the work.