Last week, I saw three different solutions to the same problem, created by three different people, with varying degrees of AI assistance to identify actions with the most impact.
Each one was developed independently of the others.
Each one had a different angle of approach.
Each one identified a different set of actions.
And these were only the solutions I saw. I know others are in flight, all coming in from different angles. The problem is big enough that we can tie them all together and make it look like we meant to do it. But that’s serendipity, not planning.
As someone who champions alignment, this sort of thing drives me nuts. Yet it’s exactly what we’re asking folks to do as they learn how to apply AI to daily tasks: Find a problem and spin up solutions / prototypes / proofs of concept / pilots / experiments to see how AI can make it easier.
This, however, is where many teams stop. They’ve got a bunch of working prototypes, people are using them for personal efficiency, and … wait for it …
The org isn’t seeing the exponential progress it expected from AI.
Unfinished business
AI is and isn’t your typical change. No one’s really sure yet what The Future looks like, and so the natural inclination is to focus on short-term tool adoption — the part everyone knows — while leaving the long-term strategy unfinished.
What then happens is: 1. No formal training because learning objectives aren’t clear enough to create a curriculum, or because it changes so quickly no one can keep up. 2. Vague and slightly menacing outcomes around efficiency. 3. Mandates to experiment like mad with AI, alongside weird incentives like tokenmaxxing.
This leads to folks sprinkling AI on top of how they already work, rather than remapping for AI-native workflows and then building prototypes. The sprinkle approach is OK for learning and seeing what’s possible, but leaders can’t expect miraculous efficiencies from it.
Then, once everyone’s using the tools, no one takes the time to reconcile the various solutions to figure out which one works best — not simply works — before scaling it out across the team. There’s a variant here in which the first prototype a leader sees gets the nod for scale-out because hey! it’s cool! and not necessarily because it’s the right choice.
Here’s where I trot out the G word. Governance. Which is a close cousin of the B word. (No, not that one!) Bureaucracy. No one likes either of them.
But the throw-spaghetti-at-the-wall method will only get you so far. You need a systematic framework for making decisions about AI, staying aligned on the ultimate objectives, and keeping people accountable for follow-through.
This isn’t groundbreaking stuff. It’s the same as any change management effort and, for that matter, any strategic initiative. What’s different is that the speed and magnitude of change with AI is WAY beyond what teams normally experience. No one’s got the luxury of workshopping out a nice and neat 18-month roadmap, or creating binders full of artifacts, or running every little decision past 6 layers of leadership, or spending weeks on wordsmithing just the right message.
And so … they don’t do any of it. Maybe they even dismantle the existing systems for the sake of moving faster. Which works. And results in 10 different solutions running in parallel and, sometimes, at cross-purposes. Solving one challenge creates another.
System instructions … for people and agents
The governance we use with human systems is the same pattern we use to govern AI systems. So, if the human system isn’t working or isn’t there, how are we making sure agents and automations are doing what they’re meant to do without going rogue?
Certain guardrails like access controls can be built into the technical layer, just like human permissions models. But once a tool is accessed, you’ve still got to know what the heck to do, and not do, with it. With agents, we call that “system instructions.”
These are the standing rules that govern an agent or LLM tool while it’s working. (See a much more extensive explanation from Google.) They pre-load so you don’t have to repeat yourself or reinvent your prompts. Kinda like the team wiki that you point a new employee to when they’re onboarding.
Here’s what you might put in system instructions for AI, and what they map to in terms of human conventions:
- RACI -> What the AI’s role is
- Strategic vision and outcomes -> What’s the AI’s objective?
- Goals and KPIs -> What does good look like?
- Resources and priorities -> What are the constraints?
- Decision paths -> When should the AI ask for direction?
- Status checkpoints -> Regularly evaluating how your AI is performing against your instructions
So, let’s say we’re building the governance model — the system instructions — that will steer your AI rollout. Rather than trying to manage All The Things on your team, the model should be specific to the change you’re trying to drive with AI, whether that’s productivity, scalability, or pure reinvention of work. The more specific you can be, the easier it is to define the other pieces of the model.
Identify a single point of contact, not a committee, to run it, and preferably someone who can give it adequate time and attention. This is like the “orchestrator” agent that might be guiding sub-agents in your AI system. Your human orchestrator doesn’t need to be an AI expert and, arguably, it might be better if they’re not. They’re more likely to focus on the business improvements than the shiny new toy.
Huge caveat for the project management aficionados out there. This isn’t an excuse to go full-bore on artifacts and logs and status reports and process maps. Just like with agents, information overload will slow down the system and deter progress. Keep this as lightweight as possible, enlist managers to help enforce the guardrails, and put it in a location where it can be easily referenced. A team knowledge base would be an excellent choice.
Not your average strategic program
“But, Cindy,” you say. “We already have all that, and it’s not getting us to the glorious human-AI future.”
To which I’d ask back: “Are you running this the same as you’ve always done with big initiatives? Is it lumped in with everything else as a one-liner on your portfolio review?”
Because therein lies the rub. The legacy methods were designed for the pre-AI world. I can’t stress this enough: Keep the pieces that work, and remove or reinvent the parts that will bog it down. When you define decision paths, for example, you’ll create thresholds of autonomy and impact rather than approval chains. Low-impact decisions are a Just Do It, accepting the risk of mistakes. High-impact decisions need more scrutiny. Then make sure you also clearly define what low- and high-impact look like. The more data you can include, the better.
This is why my team ended up with multiple solutions for the same problem. Company culture puts a premium on ownership and speed, and so governance doesn’t always kick in until it’s time to see what’s working and reconcile. YMMV, though. It requires a healthy tolerance for chaos and doesn’t work for every team.
That said, we have indeed reached the time to reconcile, and lightweight system instructions are now in flight. We might end up applying the same instructions to agents that eventually take over the recurring portions of work.
Which will be a win for reinvention.
All opinions here are my own. All text is my own, too, including the em dashes. I welcome constructive comments and discussion on LinkedIn and Bluesky.
Leave a Reply