You don't know all the ways your team is using AI


You don't know all the ways your team is using AI.

What do you do when your team finds better tools than the ones you approved?

The standard response to unauthorized technology use is to shut it down. I’d argue that’s the wrong first move.

Sometimes it's willful; someone knows the policy and works around it anyway. More often, it's not. They didn't realize the risk, didn't know a policy existed, or just needed to get something done. Either way, instead of asking "how do we stop this," ask: "Why is this happening, and did it work?"

This is shadow IT, and it’s not a new problem. As long as people have had access to software, they have had access to tools they could install without permission. What's changed is the friction to entry has nearly disappeared. SaaS tools require nothing more than an email address. AI tools are useful immediately and often free to start. In fact, SaaS vendors deliberately target individuals precisely because it works; get one person hooked and the tool worms its way into the enterprise.

And critically, the sensitivity of what ends up inside these tools is increasing fast. Consider these examples, happening inside organizations every day:

  • Someone uses Fireflies or Otter to record a meeting and now that conversation, including amy sensitive personnel discussions or unreleased strategy, is transcribed and stored on a server nobody vetted.
  • A developer uses Cursor or GitHub Copilot on a personal account and pastes proprietary code into it daily.
  • A team member builds a n8n automation that pulls from the CRM and sends data somewhere else. They solved a problem, but also built an unsanctioned data pipeline that IT has no visibility into.

What worries executives most is the data, not the tool. Free tiers in particular often mean the vendor can train on whatever gets typed in, with no clear way to know where it ends up.

These are valid risks, but the control-first response misses something.

If five people are using five different tools because the approved options aren't cutting it, that's useful information. Shutting it down makes the workarounds more invisible.

What if you treated shadow IT as a diagnostic instead? What were they trying to do that the official tools couldn't? Did it work? Should the organization be evaluating this more broadly?

A control framework says: here's the approved list, everything else is prohibited. An enabling framework doesn’t abandon the rules, but it explains the thinking behind them: here's how we think about technology, here's what matters to us, here's what to consider before you adopt something new. And when someone finds something that works, here's how we evaluate it together.

Your organization already knows how to do this. Your culture has values that shape how people behave every day. You didn't hand everyone a rulebook, you built something people internalized. Technology governance can work the same way. Instead of a policy that tries to anticipate every scenario, you build a set of technology mindsets. There are still rules, but people follow them because they understand what the organization is doing.

What those mindsets look like depends on your culture and your risk profile. A high-autonomy, high-experimentation company needs different technology norms than a process-focused one. The goal is a team that knows how to think about technology decisions, and share good information when they find it.

Assume people on your team are already using tools you don’t know about.

Some don't realize there's a policy or haven't thought through the risk, while others know and did it anyway.

Treat them differently. For the first group, give them clarity in the form of a framework they can understand and a system for bringing what they’ve found into the open.

I guarantee you’ll learn something in the process.

Talk soon,

Josh

​Josh Hulst: Technology Strategy & Advisor for Business Leaders | Co-Founder and Partner at Michigan Software Labs

551 Settlers Dr, Suite 200, Ada, MI 49301

These Strategy Signals are meant to be shared. If you know someone who would benefit, invite them to subscribe on my website or view the web version of this email.

​
​Unsubscribe | Preferences

Strategy Signals

Strategy Signals is a monthly newsletter for leadership teams who know technology should be driving growth, but aren’t seeing it happen yet. Each issue breaks down the structural reasons progress feels slower than it should and how to change that.

Read more from Strategy Signals

On time, on budget, and still behind. Most executive teams are measuring whether technology gets delivered, not whether it moves the business forward. Organizations often measure technology by activity. How many tickets are closed? How many tools are deployed? How many projects are delivered on time? Yet, none of these metrics answer whether technology is changing what your business is capable of doing. They measure activity, not capacity. Take project delivery, for example. A project...

STRATEGY SIGNALS By Josh Hulst, Michigan Software Labs Does your technology work for you, or against you? If you ask most leadership teams to describe their technology, they'll walk you through a list of tools, such as the CRM they implemented three years ago or an ERP that they inherited from an acquisition. It might be an accurate list, but it's not really the answer I'm looking for. Knowing which tools you have is not the same as knowing what they can support together. For instance, can...

STRATEGY SIGNALS BY JOSH HULST You’re asking the wrong question about AI You're getting this from a new email address. Nothing has changed except where it comes from. What should we do with AI? It sounds like a responsible starting point. It feels like you're taking the technology seriously by exploring your options. But in my experience, this question produces a specific kind of response: searching for tools, a pilot or two, or a list of pain points to automate. The issue is that this...