For the people who answer for it
Your team is already building with AI. What has it changed?
Most leads can name what their people built and not what it moved. The difference isn’t more reporting. It’s giving that work one place to land, and writing down what each change is expected to do before it ships, so there’s something to settle against later.
Where your team’s AI work probably stands right now
You can't say what it changed
Your people have assistants and are getting value out of them. If someone asked you what that changed about how the work runs, you would be reasoning from anecdotes.
Nobody holds the list of what's been built
People across your team are building with AI already: a classifier in a spreadsheet, a prototype in a coding tool, a prompt someone pastes in every Monday. They sit in different accounts, none of them knows about the others, and nobody holds the list.
Every quarter, someone asks what it returned
Somebody above you asks what the investment returned. The honest answer today is a list of things that were built, which is an answer about activity.
None of that is a failure of management. It’s what happens when the work changes faster than anyone writes down what it was supposed to do.
The work your people already did doesn’t have to stay scattered
The answer to people building things on their own isn’t to stop them. It’s to give what they build somewhere to land, where it can be found, governed and counted.
Everything in one place, so you can see what you have
The things your people built land in the same workspace as everything else, with a name, an owner and a date. Two teams solving the same problem twice becomes visible, which is usually the first saving.
Built from the same picture of the work
A tool built from one person's view of a process inherits that view, and it's why so many of them are almost right. When the map of how the work actually runs is shared, the next thing starts from the business rather than from one desk.
Inside your permissions, not beside them
Anything reaching your real systems does it with the permissions you set, and anything that would change something comes back as a proposal first. That's the difference between an experiment you tolerate and one you can let near a customer.
Promoted rather than rebuilt
A prototype that works doesn't have to be thrown out to become real. zv1, our assistant, can drive the tools your people prototyped in, so the thing that proved the point gets picked up, held to a bar, and kept.
What your team does differently
Three habits, none of which require the people doing the work to change the tools they already use.
- 01
Start from how the work runs today
Before anything changes, your team maps the work as it actually happens: the steps, who owns them, which systems they pass through, and where it hurts. That map is the baseline everything later gets compared against, and it's usually the first time the whole shape of the work is written down anywhere.
- 02
Write down what you expect before it ships
Whoever is making a change records what they expect it to move, by how much, and by when. It takes a few minutes and it happens before the work lands, which is the only time the answer can't be edited to fit the result.
- 03
Read the record at the end of the quarter
Each expectation settles against what actually happened. You get what was expected, what came of it, and how often your team's expectations turn out to be right — which is a number that improves as a team learns to read its own work.
What you can say at the end of the quarter
What changed, with the evidence attached
Not a list of what got built. The specific claims your team made in advance, and what happened to each one.
What to fund next
The map shows where the work still hurts, and the record shows which kinds of change have worked for your team so far.
Where a claim didn't hold
An expectation that missed is the cheapest thing on the page, and it's the one that makes the rest believable.
What you’re probably wondering
- Does this score my people?
- No, and it can't. Expectations settle for the workspace, never per person — there is no view that ranks your team against each other, by design. The record is about which changes worked, not who made them.
- My people are building with tools we never bought. Is this about shutting that down?
- No. People reaching for these tools on their own is the signal you want, and the ones doing it are usually the ones who understand the work best. What's missing is somewhere for what they make to land, so it can be found, reviewed and counted rather than living in one person's account.
- What if an expectation turns out to be wrong?
- That's the useful case. A team whose expectations are always right isn't learning anything, and a quarter where two claims out of nine held is a real finding about where to spend next.
- Do my people have to change how they work?
- They keep the assistants and tools they already use. What's new is that a change worth reporting gets a sentence written about it before it ships.
- How long before there's anything to report?
- The map is useful in the first week because it's the first complete picture of how the work runs. Expectations need a measurement window to settle, so the first real read is a quarter in.
- Is this a dashboard?
- No. A dashboard shows numbers moving; it can't tell you whether anyone predicted the movement or what they did about it. The record holds the claim, the evidence and the outcome together.
What would you want to be able to say in ninety days?
If the answer is more specific than “we shipped a lot,” the thing standing between you and it is a habit your team can start this week. That’s usually a short conversation.