Most of the conversations I have about AI in finance right now end up in the same place.

“Am I going to be replaced?”

“Is my job going to exist in five years?”

“What should I be doing now?”

Behind all of those is a more useful question.

Which behaviors are quietly turning people into force multipliers?

Three so far.

None of them have titles yet.

All of them compound.

I understand the anxiety behind the question.

I had my own version of it when I first started using AI seriously. The more I used it, the more obvious it became that the story was not as simple as “AI replaces work” or “AI saves time.”

Something else was happening.

The people getting the most value from AI were not just producing faster.

They were changing how the work moved.

That distinction matters.

A few months ago, if someone on the team had a complicated question before a leadership review, the workflow was familiar. Ask an analyst. Wait for the pull. Review the cut. Ask the follow-up. Wait again. Then bring the answer back into the next conversation.

Briefing, waiting, reviewing, going back.

That was just how the work moved.

Now I am seeing something different.

One of my leaders recently pulled the raw data herself, structured it with context, opened a shared project, and brought the team into the analysis live.

We were not reacting to a finished deck. We were working from the same data, same assumptions, same context, and same starting point.

The answer came faster.

But that was not the real change.

The real change was how the team worked.

That is what I mean by a force multiplier.

Not someone who personally gets faster.

Someone whose behavior makes the whole team better: better context, better questions, better workflows, better judgment.

The output improves because the operating system around the work improves.

That is what I think many finance leaders are still underestimating. AI is not just changing who can produce output faster. It is changing which behaviors create leverage for everyone else.

You can spot the three if you know what to look for.

1. The person who designs the workflow

This is the person who does not just use AI for their own output.

They set up the work so other people can use it too.

They build the context document. They organize the files. They write down the source rules. They create the prompt that can run again next month. They think about what someone else would need to know if they stepped into the workflow cold.

That sounds basic.

It is not.

Most people still use AI like a private productivity tool. They ask a question, get an answer, copy the output, and move on.

The Workflow Designer thinks differently.

They ask better questions before the work starts.

Could the team run this without me?

Could a new person understand the logic?

Could this work again next quarter?

Could we trust this if someone asked where the number came from?

That is the difference between a useful AI session and an operating model.

I have seen this show up in small ways. Someone figures out a better way to analyze a file and immediately writes down the process. Someone builds a recurring project instead of starting a new chat every time. Someone notices that the answer got better only after the business context was loaded, so they turn the context into a reusable asset.

That is the multiplier.

Not the prompt.

The setup.

The Workflow Designer makes the team’s analytical capacity bigger than any one person on it.

And this is the part I think leaders miss: this is not only an analyst behavior.

Some of the most valuable Workflow Designers will be senior leaders who practice this themselves.

The market still reads “workflow design” as something junior people do. I think the market is wrong about that.

In an AI-native finance team, designing the environment where the team thinks may become one of the highest-leverage things a finance leader does.

The deck used to be the work.

Increasingly, the project is the work.

Someone has to design it.

2. The person who questions whether the work should exist

This one is harder.

The Process Redesigner is not trying to make every process faster.

They are willing to ask whether the process should exist at all.

That sounds obvious until you are the person who owns the process.

Last year I watched one of my managers kill a weekly report the team had been running for years.

He did not automate it. He did not redesign the format. He did not build a better dashboard.

He asked who actually used it.

The answer was some version of: we have sent it for years because we always have.

So he stopped sending it.

Nobody noticed.

That afternoon — every week — went back into real analysis.

That stuck with me because the first instinct with AI is usually: how do we do this faster?

Useful question. But incomplete.

The better question is: why are we doing it this way in the first place?

A lot of finance work exists because of old constraints.

The system could not produce the right cut. The dashboard did not have the right view. The business asked for something once and nobody revisited it. The handoff existed because one person had access and another person had context.

Those constraints shaped the process.

Then the process became normal.

AI changes some of those constraints.

Not all of them. Not magically. Not without review.

But enough that leaders should be much more willing to reopen the question.

The Process Redesigner sees the old logic hiding inside the current process.

They ask the uncomfortable questions.

What is this for?

Who uses it?

What decision does it support?

What would break if we stopped?

Could AI make this better, or is AI just helping us preserve work we should delete?

This is why Process Redesigners can be uncomfortable to manage. They are not just improving the machine. They are questioning whether parts of the machine should still run.

That discomfort is the point.

A finance team does not become more valuable by automating every old process.

It becomes more valuable by knowing which work still deserves to exist.

That is a force multiplier too.

Not because it creates more output.

Because it gives the team back time for work that actually matters.

3. The person who keeps experimenting

Every team has someone who tries the new thing before anyone asks them to.

They test the new model. They build the small script. They take the annoying recurring task and see if they can make it lighter. They send a note that says, “I tried this, and it actually worked.”

Sometimes it is rough.

Sometimes it breaks.

Sometimes it is not ready for anyone else.

That is fine.

They are not the production system.

They are the R&D layer.

One of mine built a personal notifier that flags her when key data sources update. Nobody asked her to build it. It was not part of a transformation roadmap. She just had a recurring pain point and got curious.

Then she shared it.

Now a few people do not have to remember to refresh manually.

That is usually how this starts.

Small.

Personal.

Shared.

Then standard.

That is how force multipliers behave.

They do not just make themselves faster. They find something useful, test it, and bring it back to the team.

The Experimenter is not valuable because every experiment works.

They are valuable because they expand the team’s sense of what is possible.

They find the edge of the tools. They learn what fails. They bring back judgment the rest of the team can use.

That last part matters.

There is a difference between someone who is excited about AI and someone who is useful with AI.

The useful ones test. They compare outputs. They notice where the model gets lazy. They know when the answer sounds right but needs a second pass. They break things in low-risk places so the team does not break them in high-risk ones.

They are curious, but not careless.

That is what makes them valuable.

The three need each other

These behaviors work best together.

The Experimenter finds what is possible.

The Workflow Designer turns the useful experiments into something repeatable.

The Process Redesigner asks whether the work should exist before anyone spends time making it better.

Without the Experimenter, the team keeps improving the same old workflows.

Without the Workflow Designer, the team ends up with a graveyard of interesting one-off experiments.

Without the Process Redesigner, the team automates work that should have been questioned first.

The best AI-native finance teams will need all three.

Not necessarily as three separate people. Sometimes one person has two of the behaviors. Sometimes the leader has to model one because the team has not built the muscle yet.

But the behaviors matter.

They are the operating engine.

They are how individual AI usage turns into team leverage.

The honest version

Not everyone will make this shift at the same pace.

Some people built their careers in a world where the multiplier was technical execution: deep Excel models, complex reconciliations, dashboard mastery, knowing exactly how to get the answer out of the system when nobody else could.

That still matters.

But it is not the only multiplier anymore.

The value is moving upstream.

Toward people who can design the workflow, question the process, and experiment their way into better operating habits.

A few weeks ago I wrote that AI would not cause layoffs this year — but it would quietly reshape performance management on finance teams.

These three behaviors are what the separation is built on.

I have watched two people on similar tracks start to separate quickly once AI entered the work.

One turned a few one-off experiments into workflows the team could reuse.

The other kept doing the work the way she had always done it.

Neither person was lazy.

Neither was wrong.

But only one was compounding.

That is the part leaders need to see clearly.

This is not a character flaw. It is an environmental shift. The work changed. The baseline changed. The behaviors that create leverage changed.

And performance management will eventually catch up to that.

What this changes for leaders

The right leadership move is not telling everyone to “use AI more.”

That is too vague.

The better move is to look for the force multipliers.

Who is building workflows other people can use?

Who is questioning work that no longer deserves to exist?

Who is experimenting in a disciplined way and sharing what they learn?

Those are the people I would give more visibility.

Those are the people I would put on the messy, high-value projects.

Those are the people I would protect when they make the organization uncomfortable in the right way.

And the part I keep coming back to:

I would practice the behaviors myself.

The most underrated force multiplier is not always a junior analyst who knows the newest tool.

Sometimes it is a finance leader who stops delegating the entire AI learning curve and gets close enough to the work to understand how the operating model is changing.

Not because the leader needs to become the best analyst.

Because the leader has to know what kind of team they are building.

That is the real leadership move.

Find the people who make the work more repeatable.

Find the people who make the work more useful.

Find the people who make the work more honest.

Build around them.

And become one of them.

I tell my kids that practice makes us better. They roll their eyes when I say it. But it’s the truest thing I know about getting good at anything — and it turns out to be the truest thing I’ve learned about AI in finance, too.

A few months ago my team started using shared projects. Someone loads the CSV files. Someone writes the context document. The whole team works off the same dataset. Same framing. Same starting point.

It took us a few quarters of reps to figure out how to set those up properly.

This quarter, when we needed to answer a complex question for a leadership review, one of my leaders didn’t ask an analyst and wait a day. She pulled the raw data herself, built the project, and shared it with me and my boss.

We analyzed it together — live, in a working session. We formed hypotheses, tested them against the data, refined the story, and had a summary memo done in hours.

Not days. Hours.

What enabled that wasn’t the tool. The tool was the same one we’d had access to for a year.

What enabled it was the reps we’d built on creating shared projects, structuring them right, and learning what makes them useful.

Practice made us better.

That’s the thing nobody is putting a number on right now.

The conversation that actually predicts who wins

The conversation about AI in finance is still mostly about tools. Which model. Which interface. Which vendor.

The conversation that actually predicts who wins is about reps.

AI competence in finance isn’t tool literacy. It’s accumulating judgment about what to automate, what to review, what context the system needs, and which workflows are actually repeatable. That judgment only comes from running real workflows under real conditions, getting things wrong, and adjusting.

You can’t read your way to it. And the leaders waiting for AI to “become finance-ready” before they start are about to find that out.

The five reps that actually compound

Five categories of judgment that only show up after enough reps. If you can’t answer these in a sentence each, you’re not behind on tools — you’re behind on reps.

1. What to automate vs. what to keep manual. I learned this on a recurring revenue commentary I was sure I could automate. Three attempts in, I realized the value was in the friction — forcing someone to read every line was catching exceptions the model didn’t see. Not everything that can be automated should be. The reps teach you which workflows lose value when they’re automated and which gain.

2. What to review and what to trust. The first time I let an AI-drafted variance commentary go to the team without a full review, I caught an error on the second reading that would have been awkward in front of leadership. After that, I knew exactly which outputs need the careful pass and which can be checked at the summary level. The instinct came from getting it wrong once.

3. What context to give the system. The first version of my team’s context document was 80% wrong — not because the facts were wrong, but because the framing didn’t match how we talk about the business. The fifth version is what the team actually uses now. The teams that have written a real Finance Context Document run circles around the teams that haven’t.

4. Which workflows are actually repeatable. We tried for three quarters to standardize an AI-drafted board narrative. We finally accepted that each cycle was different enough that the workflow wasn’t going to compound — but the context document around it absolutely did. After enough reps, you stop forcing repeatability where it doesn’t exist and concentrate where it does.

5. Who on the team becomes a force multiplier. Not every team member becomes 10x more valuable with AI. Some do. I can usually tell which ones within the first hour of watching them work. The behaviors are visible if you know what to look for.

Why these can’t be back-filled

Each rep builds on the last. The second teaches you what the first was actually about. By the tenth, you’ve built a model of the work that doesn’t exist in any document or vendor presentation.

If you spend six months waiting for the tools to mature, and someone else’s team spent those six months running reps, the gap isn’t six months of tool knowledge. It’s six months of judgment that took 100+ iterations to build. You don’t close that by reading three articles and watching a vendor demo. You close it by running reps. And by then, the other team is twelve months ahead.

The reps aren’t really about you

Here’s the deeper version of why these reps compound: they’re not about you getting better with AI. They’re about learning how to set up your team for a fundamentally different way of working.

The old model of finance work was sequential. Someone ran the analysis. Built the deck. Presented it. The team reacted.

The new model is collective. Every person on the team works off the same context. The analysis happens together, live. Findings bounce between people in real time. The story gets built between you, not handed across.

That’s exactly what shared projects unlocked for my team. The reps weren’t just teaching us how to use AI better. They were teaching us how to work together differently.

Your job as a leader isn’t to become the smartest user of AI. It’s to build the conditions where your team works collectively in a way they couldn’t before.

Where to start this week

Pick one workflow. Not three, not five — one. Something you do every cycle that’s mostly language and synthesis. Don’t pick the most strategic workflow. Pick the boring one. That’s where the variables are simple enough that you’ll actually learn.

Run it. Write down what went wrong. Run it again next cycle. Write down what got better. Do that for three iterations.

At the end of three iterations, you’ll have something most finance leaders still don’t have: real first-hand judgment about what AI does well and where it breaks in your environment.

That’s not a tool decision. It’s the start of an operating model.

Practice made us better

The leaders pulling ahead right now aren’t smarter, better-tooled, or working with better data.

They have more reps.

You can’t read your way to the judgment that comes from running real work under real conditions.

You can only practice it.

I tell my kids practice makes us better. It’s also the truest thing about AI in finance.

The first rep is the hardest. Run it this quarter.

The moment I realized the workflow had changed was not when the QBR analysis finished two days early.

It was when a manager asked a question I had not thought to ask, against data I had already loaded, and we answered it inside the project.

The question was not complicated: was the variance really coming from the segment we were focused on, or was one customer cohort distorting the view?

No follow-up meeting. No new request. No “let me take that offline.”

Twenty minutes later we had the answer. Twenty minutes after that, we had the next three questions.

At first, I thought the gain was speed. It was not.

The deck — which had been the center of gravity for this process for years — was not where the work was happening anymore. The work was happening inside a shared project. That sounds like a small operational detail. I do not think it is.

We have seen this movie before

For years, documents moved by email. Slide_Deck_Final.pptx. Then Slide_Deck_Final_v2.pptx. Then Slide_Deck_Final_v2_AS_edits.pptx. Then the board deck came back as a 200-megabyte attachment because no one wanted to use SharePoint.

Then one day you opened a Google Doc with your VP, and you were both editing in real time. The document stopped being a baton you passed back and forth. It became the place where the thinking happened.

That shift did not just make documents faster. It changed how teams worked together.

AI projects are starting to do the same thing for analysis. The CSV used to be exported, pivoted, pasted into a deck, reviewed, questioned, re-pulled, re-pivoted, re-pasted, and re-reviewed. The deck was where the team reacted to the analysis — but only one person could really own the analysis at a time.

In a shared AI project, the data, the context, and the questions live in the same place. The team analyzes together, live, against the same source of truth.

Same shift, different artifact.

The deck stops being the work

For years, the deck was effectively the workflow. The analysis happened privately. The deck became the artifact everyone reacted to. Questions triggered more analysis. More analysis created more deck revisions. The deck was where the organization thought together.

But that was always a little backwards. The deck is a communication tool. It was never designed to be the operating system for analysis.

In a shared project, the working project becomes the place where the thinking happens. The deck becomes downstream communication. Once the analysis is collective, the speed of iteration changes completely. Questions do not wait for ownership transfers. Context does not need to be re-explained every time a new person joins the workflow. The team operates against the same assumptions, definitions, source rules, and working data in real time.

The result is not just efficiency. It is a different operating model.

What this looks like inside an earnings cycle

The earnings project we set up made this most obvious.

In the old workflow, an earnings question went like this: I asked my analyst to pull the data. The analyst sent it. My director reviewed it. We came back with a point of view two days later. Every step was a handoff. Every handoff was a wait.

In the new workflow, when a question came up, my team loaded the missing data into the project, and we worked the hypothesis together. Twenty minutes.

That happened over and over, across the earnings cycle. The data, the context, and the prior questions lived in one place. When the team needed to test a new angle, no one had to recreate the setup. We loaded what was missing and kept going.

The QBR scene was the live version of the same pattern. A question came up that the deck didn’t answer. Instead of taking it offline, we drilled into the regional cut live. In the room. Seconds, not days.

“Let me follow up” didn’t disappear. The follow-ups just got faster, and the answers got deeper, because the team was not starting over each time.

Not every question gets answered in the room. Some still need validation. Some still need source-system checks. Some still need a careful review layer. But the meeting no longer has to stop every time the team hits a new question.

The team is not just reviewing the analysis. The team is analyzing.

The bigger surprise

A few weeks after the first project started working, something more interesting happened.

The team began using it the way we already use AI with external information. They asked follow-up questions. Tested different cuts of the data. Looked for outliers. Built dashboard views. Pressure-tested what the reporting should actually show.

The AI project was not just helping us write about the numbers. It was helping us understand them faster. And some of the dashboards and reporting views that started inside the AI project later became part of the live environment.

That changed how I think about shared projects. The AI project was not the destination. It was the bridge between raw data and better reporting — a faster way to explore, analyze, prototype, and decide what was worth scaling.

Where shared projects break

Not every workflow needs this model.

The first shared project I set up was for a process that did not need collective analysis. The team did not have enough overlapping context for the setup overhead to matter. We spent time preparing the project, used it briefly, then reverted to the old sequential workflow because it was actually more efficient for that task.

Shared projects are not magic. They are most powerful when multiple people have useful analytical questions, iteration speed matters, and the workflow benefits from collective reasoning. QBRs. Forecast scenarios. Board prep. Strategic deep dives. Large variance investigations.

The other failure mode is missing context. Teams load the CSV. Everyone joins the project. Questions get asked. The answers come back generic, because the model does not understand the business definitions underneath the numbers. That usually creates the false impression that “AI was not very helpful.” In reality, the workflow was missing its operating context. The data was there. The context was not.

The leadership implication

The shift to shared projects is not primarily a tooling decision. It is an operating-model decision.

Someone has to structure the data, define the context, frame the first questions, and design the review layer. Someone has to create the working environment the team analyzes inside. Increasingly, that someone is a finance leader.

That is a different leadership job than reviewing the deck at the end. It means deciding what data belongs in the room, what context the model needs, which questions are worth exploring live, and which outputs need verification before anyone trusts them.

The old model emphasized reviewing finished work. The new model rewards leaders who design collective analytical environments — shared context, shared assumptions, shared workflows, shared operating logic.

The finance leader is not just reviewing the work anymore. They are designing the system the team thinks inside.

Where to start

If you want to try this on your team, the practical starting point is three things.

A clean working dataset. Not screenshots. Not dashboard exports. The model needs structured data it can compute against directly. For most finance teams, that means exporting a CSV from your source system — Snowflake, NetSuite, Workday, whatever holds the underlying records. If you don’t have a direct connection, a clean Power BI export or CSV pull works. The discipline is to load the data the model can actually work with, not a copy of the dashboard view.

A Finance Context Document. This is the artifact most teams skip, and the one that decides whether the shared project will work. It holds your definitions, fiscal calendar, source rules, business logic, KPI thresholds, and any context the model would need to interpret the numbers the way you do. Without it, the model gives generic answers to specific business questions. With it, the team gets answers in their own operational language.

A working file inside the project. This is where questions accumulate, assumptions get clarified, analysis evolves, and decisions get documented. Without it, the project becomes another disposable AI session. With it, the workflow becomes repeatable — and the next analyst who joins the team can see how the analysis actually happened.

Start with one high-leverage workflow. A QBR cycle. An earnings prep window. A forecast scenario review. Not a process that already runs cleanly — pick the one where the team is always going back for more cuts. That is where the difference will be most visible.

The bottom line

The old finance workflow was sequential: one person analyzed, the team reacted.

The emerging model is collective: the team analyzes together, against shared context, in real time.

That changes what the finance leader is responsible for building — not just better decks, but better environments for thinking.

The deck used to be the work. Now the project is the work. The deck is just how you communicate the conclusion.

The most interesting AI user in finance may not be the junior analyst.

It may be the VP trying to answer the third why before the business review starts.

Not just what changed.

Why did it change?

And then the more important question: why did that happen?

Revenue missed plan. Why? Enterprise bookings were light. Why? Two large deals slipped. Why? One was timing, one was procurement risk, and the pipeline coverage number was hiding a mix problem.

That is the level finance leaders are trying to get to before they walk into the room.

For most of my career, exploring that question required routing work through someone else. You described the question to an analyst, waited for a pull, reviewed the output, sent follow-up questions, waited again.

If you were lucky, you got to the real answer in 48 hours.

If the analyst was stretched, or the data was messy, or your question turned out to be three questions — it took longer.

AI is starting to change that dynamic.

And the change is not what most people expect.

Everyone is writing the wrong story

Most writing about AI in finance focuses on junior analysts.

AI automates the pull, the cleanup, the first-pass summary. The analyst spends less time on manual work and more time on interpretation. Faster output. Better first drafts. More time for analysis. Productivity gains.

That story is real, and it matters.

But it misses the more interesting shift happening one level up.

The FP&A Trends Survey 2025 found that 53% of finance organizations still use no AI in any FP&A process. PwC’s AI Agent Survey found that while 79% of executives say their company has adopted AI agents, only 34% of accounting and finance functions have.

The adoption gap in finance is not a capacity problem. It is not a tool problem.

It is a model problem — finance teams are experimenting at the individual level and stalling before they reach the people who have the most to gain.

The most underutilized AI resource in many finance functions is not the junior analyst.

It is the VP or Director who has the deepest context about the business — and almost no direct path to act on it quickly.

That is the shift worth paying attention to.

Dashboards helped — but dashboards still have edges

Dashboards changed finance work in a real way.

They gave leaders more self-service access than they had before. Start with total company performance, click into a business unit, drill into a segment, filter by region, and get closer to the issue without asking someone to pull a new report.

That was a meaningful improvement.

But dashboards still have edges.

They are only as flexible as the views someone already built.

They answer the questions the dashboard was designed to answer.

The moment your question takes a different angle — by customer cohort, sales motion, product mix, contract timing, rep tenure, renewal vintage, or some combination nobody anticipated — you are back in the queue.

That is the third-why problem.

The first why is usually visible.

The second why might be reachable through the dashboard.

The third why often requires a different cut, a different lens, or a different hypothesis.

And that is where the work usually slows down.

The structure that was always there

To understand why this matters, you have to see the traditional FP&A pyramid for what it actually was.

It was not just a hierarchy.

It was a form of labor arbitrage.

Directors and VPs held the context — years of business history, driver relationships, organizational dynamics, the knowledge of which assumptions had never been stress-tested and which business units were quietly understating risk.

Analysts had the time and the hands.

The pyramid existed to broker between the two.

Convert director-context into analyst-execution, one delegation at a time.

Every process, every tool, every review cycle was built around that structure.

And it worked — within the constraints of its own logic.

A director who understood the business deeply could still only move at the speed of the next available analyst, the next data pull, the next reconciliation pass.

AI collapses the arbitrage.

When execution is no longer the bottleneck — when a VP can interrogate an export directly, draft a first-cut commentary, pressure-test an assumption before the deck is even built — context becomes the scarce resource.

And context lives with the director.

That single shift reorders everything downstream.

AI changes the exploration loop

If AI is connected to the right source data, or if you can load the right export into an approved tool, the exploration loop starts to change.

Instead of clicking through a fixed dashboard path, you can ask:

“Show me what is driving the variance.”

“Break this down by region, segment, and customer size.”

“Which accounts explain most of the movement?”

“Is this a volume issue, a pricing issue, a timing issue, or mix?”

“What changed versus last quarter?”

“What would I need to verify before I take this to the CFO?”

That is not just faster reporting.

It is a different way to interrogate the business.

There is something else happening here too.

Senior finance leaders approach data from a different angle than the team.

An analyst may start with the standard variance bridge.

A VP may start with the business question behind the variance:

Is this a real trend?

Is this a timing issue?

Is this a planning miss or an operating problem?

Those are different starting points.

Before AI, the moment those questions required a different cut, the work moved to the team.

Now the VP can often go one or two layers deeper before pulling the team in.

Not as the production owner.

Just far enough to arrive with a hypothesis instead of a question.

That is where the leverage shows up.

This is not about replacing analysts

I want to be direct about this, because the wrong read causes real problems.

The VP Analyst is not a VP who stops asking analysts for help.

It is a VP who becomes a better analytical operator — someone who defines the problem more precisely, explores the first cut directly, and hands a sharper question to the team.

Context plus execution in one head beats context communicated across two.

Not because the VP is better at the analytical work.

They are not.

Because something always gets lost in the brief.

The VP who has already inspected the data knows things that cannot be fully described in a Slack message at 4 p.m.

The before and after here is not subtle.

Before:

“Can someone pull the data and tell me what changed?”

After:

“I looked at the first cut. The variance in enterprise renewals looks concentrated in three accounts. Can you validate whether this is timing, churn risk, or a contract mix issue — and pull the same view for Q1 so we can see if this is a pattern?”

The analyst’s work goes up in quality and specificity.

The VP’s question goes in sharper.

The loop runs faster.

And the conversation that matters — the one about whether the story actually holds — starts earlier, with more of the right people in the room.

AI does not add the VP’s judgment.

That was always there.

It removes the queue between the judgment and the first result.

What good looks like

The VP Analyst does not mean building every model or replacing the analyst bench.

It means moving faster through the early exploration loop.

From dashboard clicking to data questioning. Instead of being limited to the cuts already built into a report, ask follow-up questions directly against the data. Follow the question, not the structure.

From raw question to sharper hypothesis. Instead of asking “can someone tell me what changed,” come in with “I think the issue is concentrated in enterprise renewals — I need you to validate whether it is timing or churn risk.”

From waiting for the next cut to testing the next angle. When the first answer raises a second question, keep exploring until the question is specific enough for the team to verify.

From slide review to pressure test. Before the deck goes to the CFO, run it: what part of this story is weakest? What metric contradicts the narrative? What question is leadership most likely to ask?

The goal is not to produce more analysis.

The goal is to get to the third why faster — and arrive at the team conversation with something more useful than a vague ask.

The part nobody says out loud

Here is the honest version of what this shift requires.

Not every director will adapt to building.

Some people were promoted precisely because they are excellent at directing others — at describing what needs to happen and holding others accountable for producing it.

When the work is theirs to drive from first cut to output, those directors will struggle.

That is not a character flaw.

It is a real transition challenge.

The VP Analyst model asks something specific: willingness to get closer to the data earlier than you may be used to, and comfort operating in a faster, less structured analytical loop.

Some will find it energizing.

Others will find it threatening.

The ones who find it energizing are about to become significantly more powerful.

The ones who resist it will remain dependent on the same bottleneck that has always constrained them — except now the bottleneck is more visible, because the alternative exists.

What happens to analysts

The senior analyst role does not simply get better in this model.

It transforms — in a direction that not everyone will welcome.

Senior analysts have historically been the most sophisticated executors — the ones who pull harder data, build more complex dashboards, run more difficult reconciliations, and translate messy asks into usable outputs.

Their value was in skilled mechanical work.

In the VP Analyst model, that job shifts from mechanical to forensic.

The new work is investigation:

Chasing down the anomaly the AI first cut flagged but could not explain.

Reconciling the edge case between two systems that both show plausible but inconsistent numbers.

Building the context documentation that makes AI reliable for the whole team.

Owning the verification layer a VP cannot and should not own alone.

That is a harder and more interesting job.

But it requires a different orientation — more detective, less executor.

Some senior analysts will thrive in it.

Others built their careers on technical execution and will need explicit support through the transition.

Neither outcome happens automatically.

Both require the VP to be intentional about it.

Context-rich operators are about to get more powerful

Here is the thread running through all of this.

The traditional FP&A pyramid was built around execution as the scarce resource.

AI makes execution abundant.

Context is now what is scarce — and context lives with the people who have been in the business the longest.

A VP who has spent ten years in FP&A knows things that do not exist in any dashboard.

The drivers behind the drivers.

The reason one team’s forecast is always conservative and another’s needs pressure-testing every quarter.

Why a particular assumption was baked in three years ago and never re-challenged.

What the CFO actually wants to hear versus what the model says.

AI does not know any of that.

But it lowers the barrier for the person who does to act on it more directly.

The people who have spent years building that context are about to find it is worth more than it has ever been.

Not because the work got easier.

Because the execution gap between their judgment and the first result is finally closing.

Where to start this week

Pick one recurring dashboard you already use before a business review.

Next time you are trying to understand a variance, follow the standard path first.

Click through the dashboard.

Get as far as it lets you go.

Then stop and ask:

What is the next question this dashboard cannot answer?

That is the AI test.

Load the right export into an approved tool.

Ask the next three follow-up questions.

Push toward the third why.

Then bring that hypothesis to the analyst conversation — not the raw question.

The sharper version.

If the hypothesis is right, you have just cut two days out of the loop.

If it is wrong, you have handed your analyst a more specific starting point and they will find out faster.

Either way, the conversation starts in a better place.

That is the real promise of the VP Analyst:

Not doing the analyst’s job.

Making the work start closer to the truth.

Every AI conversation in finance eventually comes back to the same question:

Which jobs go away first?

I think something else is happening first.

The top performers using AI are separating themselves faster than ever from the people who aren’t.

It’s not layoffs. It’s separation.

And I’m already seeing it on my team.

The people leaning into AI — experimenting, pushing the tools, constantly asking “what else can this do?” — are accelerating quickly.

Not marginally. Noticeably.

Their turnaround time is faster.
Their analysis is sharper.
They’re producing more.
They’re taking on work that used to require additional technical support or another team entirely.

Meanwhile, the people treating AI as optional are often still operating at roughly the same speed they were a year ago while the environment around them accelerates.

That dynamic matters more than most leaders realize.

What I’m actually seeing

The pattern is straightforward once you notice it.

The people getting the most leverage from AI are not necessarily the people who started as the most technical.

In many cases, they were already strong performers before AI entered the picture.

What changed is that AI amplified the traits that already made them effective:

• curiosity

• initiative

• speed

• willingness to experiment

• comfort working through ambiguity

AI lowered the technical barrier enough that those traits could compound faster.

Now some of these same people are:

• writing SQL they would not have attempted a year ago

• running analysis they previously handed off

• solving problems without waiting for perfect expertise

• moving through iteration cycles dramatically faster

They are becoming more technical because they keep pushing.

That’s the part I think many organizations are underestimating.

The immediate impact of AI inside finance teams is not replacement.

It’s performance amplification.

And performance amplification creates spread.

Why this won’t show up in headlines first

Most AI discussions still frame the impact as binary:

• jobs eliminated

• jobs preserved

That framing misses how organizational change usually appears in practice.

The shift shows up quietly first.

It shows up:

• in performance reviews

• in calibration conversations

• in who gets trusted with the messy, high-visibility work

• in stretch assignments

• in the moment managers realize two people they used to evaluate similarly are no longer operating at the same level

That’s the real shift I think finance leaders should be paying attention to.

Because once the strongest performers begin compounding faster, the baseline for what “strong performance” looks like starts moving underneath the organization.

And many teams have not fully recognized that yet.

The management implication

This is why I increasingly think the AI story inside finance organizations is becoming less about workforce reduction and more about performance management.

The leaders I trust most are not treating AI as an optional side experiment anymore.

They are beginning to recognize that:

• AI leverage affects output quality

• AI leverage affects iteration speed

• AI leverage affects visibility

• AI leverage affects who becomes trusted with larger problems

Importantly, much of this happens implicitly before organizations ever formalize AI expectations.

Managers notice who consistently:

• solves ambiguous problems faster

• produces stronger first drafts

• synthesizes information more effectively

• moves projects forward without dependency bottlenecks

And over time, those observations compound into real organizational outcomes:

• stronger evaluations

• higher visibility

• more strategic work

• promotion momentum

Not because managers are explicitly measuring “AI usage.”

Because they are measuring performance.

That’s why I think many finance leaders are slightly misdiagnosing the intervention required.

Most organizations default toward training:

• workshops

• prompt libraries

• tool demos

Training helps.

But the bigger shift is expectation.

The teams adapting fastest are usually the ones where leaders make it clear — directly or indirectly — that experimenting with AI is now part of operating effectively in the role.

The part worth being honest about

I want to be careful not to turn this into a morality story.

Some of the people who risk falling behind are excellent employees. Many have been strong contributors for years.

The environment changed around them.

AI lowered the execution barrier on work that previously required deeper technical specialization or more organizational dependency.

Once that barrier moved, curiosity and experimentation started mattering more.

That shift is uncomfortable for organizations because it changes how performance separates.

Not through dramatic moments.
Quietly.
Incrementally.
Then all at once in hindsight.

The bottom line

I think many organizations are still watching for the wrong signal.

They are looking for layoffs.

Meanwhile, the more immediate change is already happening inside teams through widening performance spread between people pushing AI and people who are not.

A year from now, many managers will realize they have been calibrating against a moving baseline.

Layoffs may eventually become part of the AI story in some industries.

But inside finance teams, I increasingly think performance management is the story first.

That’s not a metaphor. It’s a missing feature.

Word autosaves. Excel autosaves. Google Docs tracks every version. The tools finance teams have used for twenty years all assume the same thing: the work is worth keeping, so the tool preserves it automatically.

Your AI session assumes nothing of the sort. Close it and everything inside — the logic, the assumptions, the decisions, the code it ran to get to the output — is gone. The chat transcript is not the work. It’s a record that work happened.

Every session you close without documenting it is a file you never saved.

It gets worse inside the session

Here’s the part most people don’t talk about.

The problem isn’t just what happens when you close the session. It’s what happens before you close it.

Context windows have limits. As a session grows — more files uploaded, more questions asked, more outputs generated — the model starts losing fidelity on earlier decisions. Assumptions you established at message 10 are being held loosely by message 40. Logic that was clean at the start starts drifting.

I noticed this pattern when I was doing deep analysis work — the longer I stayed in a single session, the more I had to re-anchor the model to earlier context. It wasn’t failing. It was just running out of working memory.

In finance, that’s not an acceptable failure mode. That’s how a number ends up wrong in a board deck.

The right response isn’t to distrust AI. It’s to design around the limitation — the same way you’d design any workflow around a known constraint.

What a save file for AI actually looks like

The fix is simpler than most people make it.

Before you close any AI-assisted analysis session, ask for one more output. I call it a One-Page Repeatability Note. Think of it as the save file the tool should have generated automatically.

It covers eight things:

1. Objective — what question the workflow was answering

2. Inputs — what files, tabs, or exports were used

3. Data prep — cleaning, filtering, mapping, reshaping applied

4. Business logic — definitions, assumptions, and thresholds

5. Calculations — metrics, variances, bridges created

6. Outputs — tables, charts, summaries produced

7. Human review — what finance must verify before using the result

8. Python code — your save file

That last item is carrying more weight than it looks like.

The code makes the work rerunnable next month. But more importantly, it makes the work portable — you can hand it to a fresh session, a new analyst, or a different tool entirely, and the logic travels with it. That’s not repeatability. That’s a save file.

Python is AI’s native save format

Here’s the part most finance AI content skips entirely, and it changes how you think about all of this.

When AI generates a finished deliverable — an Excel file, a PowerPoint deck, a PDF report — it’s not doing something abstract. It’s writing Python. Specifically, it’s calling libraries built for exactly this purpose: openpyxl for spreadsheets, python-pptx for slide decks, reportlab for PDFs. The chart didn’t appear by magic. The model wrote code, executed it, and handed you the output.

This means Python isn’t an external skill you’re bolting onto an AI workflow. It’s the language AI already uses to produce finance deliverables. The code in your save file isn’t a translation of what happened in the session. It’s the original.

That’s why handing a fresh session a clean Python script works so well. You’re not asking a new model to reconstruct your workflow from memory or description. You’re reopening the file. The new session reads the script, understands exactly what was built, and picks up without drift.

You don’t need to become a developer to use this. You need to be able to ask AI to write the code, explain it, revise it, and adapt it when the data structure changes next quarter. That’s a realistic bar — and increasingly a necessary one for VP and Director-level FP&A work.

The save file is also your audit trail

There’s a governance dimension here that matters for finance specifically.

When a leader asks where did this number come from, or what did the model assume, or can someone else reproduce this — a chat transcript doesn’t answer those questions. It proves a conversation happened. It doesn’t prove the work is sound.

The save file answers all three. It documents the input sources, the logic applied, the outputs produced, and what a human needs to verify before the work goes anywhere. That’s not just efficiency. That’s defensibility.

This is the lightweight entry point into what I’d call a full AI Audit Pack — the documentation layer that makes AI-assisted finance work auditable and explainable to leadership. You don’t need infrastructure to start. You need one document per workflow. The save file is that document.

How to generate it

Next time AI helps you get to a useful output, don’t stop when the answer looks good. Use this prompt:

“Create a one-page repeatability note for this analysis. Cover the objective, input files, data preparation steps, business logic, calculations, outputs, human review checks, and Python code to rerun this workflow with updated data next month. Make it clear enough that another finance team member — or a fresh AI session — could pick this up and repeat the process.”

Note that last line. You’re not writing this for a colleague. You’re writing it for the next session. The note is the handoff. The code is the file format.

The output won’t be perfect. Code needs testing. Assumptions need review. Finance judgment stays in the loop.

But you stop starting over. You stop trusting a session that’s 40 messages deep.

Every analysis deserves a save. Now you know how to do it.

A few months ago, I built a game with my son.

I still laugh a little when I say that, because I am a finance leader, not an engineer. But with AI, I could describe what I wanted, test the output, refine the logic, and keep going.

Somewhere in the middle of that project, something clicked — and it had nothing to do with the game itself.

I realized how much I had been waiting.

Waiting for IT to roll something out.
Waiting for the data team to stand up the right pipeline.
Waiting for a platform, a pilot, a proper use case.

Meanwhile, my son and I had built something real on a weekend using tools already sitting on my laptop.

If I could do that at home, what exactly was I waiting for at work?

That is the question I think most finance leaders need to sit with.

Because in an AI-first world, waiting is not a neutral posture. It is a strategic mistake. The leaders who wait for AI to come to them will get passed by the ones who engage early, understand where it fits, and start shaping how their teams use it.

The waiting posture is the problem

I have seen this pattern play out with every technology shift. A new tool shows up. Leaders treat it as something that will eventually arrive through formal channels. The platform will get selected. The pilot will get approved. The rollout will happen. Someone else will become the expert first.

Then the organization waits.

That posture does not work with AI.

AI is not an ERP rollout. You do not need to wait for a steering committee to start learning how it behaves. You can open a tool right now, put in a real piece of work, and learn something useful in fifteen minutes.

The barrier is not access. The barrier is willingness to be a beginner again.

That was a harder adjustment than I expected. I had all the usual reasons to stay on the sidelines: the data is not connected, the governance is not fully in place, the team should test it first.

Those constraints are real. But none of them is a reason for the leader to stay out of the work. If anything, they are the reason to engage personally. The leaders who understand the limitations from the inside are the ones who will make the right decisions about where to invest, where to simplify, and where a manual workaround is good enough for now.

The game-building project with my son is what made this clear to me. Not because it taught me to code. Because it showed me how fast the learning curve actually is once you stop treating AI as someone else’s project.

You cannot lead what you have not tried

A finance leader who has not actually used these tools cannot credibly shape how the team uses them.

They can sponsor the work. They can approve budget. They can encourage experimentation. But they cannot really guide it.

They cannot tell the difference between a workflow that is a strong AI fit and one that will produce confident-sounding output that is operationally wrong. They cannot push back on a vendor claim if they have no intuition for what the tools can and cannot do. They cannot tell whether a weak result came from the model, the context, the workflow design, or the person using it.

They are dependent on whoever in the room has actually tried it.

There is also a real limitation worth naming honestly. AI is only as good as the data it can reach, and the biggest constraint I still run into is not the model — it is the lack of a clean connection to the information I actually need.

That is where a lot of AI promise quietly dies.

I do not have this fully solved. Most finance leaders I talk to do not either. But the leaders working on it from the inside will get there faster than the ones waiting for a vendor to hand them the answer.

The standard I hold myself to now is higher than “the team should use AI more.” That directive is too vague to be useful.

The standard is that I should be able to say, specifically, which workflows are worth testing, which tasks should be repeatable, where a process needs more context before AI can help, where the output still needs human judgment, and when a weak result is a process problem rather than a model problem.

The only way to have a real opinion about AI in finance is to have used it on real work.

The bar for finance talent is going up

Once the leader is engaged personally, the talent conversation gets sharper very quickly.

The bar for finance talent in an AI-first world is going up, not down. Not because everyone needs to learn Python. Because the most valuable people in finance will be the ones who can think end to end — from raw data to final product, from question to analysis, from workflow to insight.

The old model rewarded people who could grind through the workflow. The new model rewards people who understand the workflow well enough to redesign it.

That is a very different standard.

One of my senior analysts recently rebuilt a recurring weekly package using ChatGPT. Before, the workflow took her about two hours every week: extract the data, pivot it, update the template, build the chart, write the commentary.

Now it takes minutes.

What made that work was not technical skill in the traditional sense. It was business context.

She understood the data.
She understood the audience.
She understood what the commentary needed to actually say.

That is what let her guide the model well enough to produce something operationally useful, not just something that sounded polished.

The people who will thrive in an AI-first finance function are the ones who understand the broader ecosystem of the work — where the data comes from, how summary layers are structured, how the final analysis gets shaped for leadership, and what the business actually needs from the output.

They do not need to be elite in every layer. They need to understand the system.

AI rewards people who know why they are doing the work, not just how to repeat it manually. Insight is still the premium in finance. AI does not lower the value of judgment. It raises it.

What all of this is actually for

Leaders who engage. Teams built around a higher standard. Better workflows.

All of that only matters because of what it unlocks.

The real point of AI in finance is time to insight.

Not how fast the team produces the package. How fast the team gets from raw inputs to business understanding.

A lot of finance work still gets slowed down by tasks that are necessary but low value. Pulling data. Rebuilding decks. Formatting slides. Stitching together reports. Recreating the same commentary from scratch.

Those are not just efficiency problems. They are time-to-insight problems.

Every hour spent assembling the package is an hour not spent understanding what it means.

Go back to the weekly package example. The interesting number is not “two hours to minutes.” The interesting number is what those two hours got redirected toward.

She now spends that time working directly with the sales organization — pressure-testing assumptions, unpacking what changed, and helping them think through what the numbers actually mean.

That is the shift.

Faster time to insight on one side.
More time in the business on the other.

That is how finance creates value.

And that is how I think about AI ROI in finance. Not as a vague productivity claim. Not as a headcount story. As insight velocity. As a reallocation of finance time toward the work only finance can do.

Everything else in this piece points back to that. The leader has to go first so the team sees what is possible. The talent has to be strong enough to guide the tools well. The workflows have to be redesigned around what matters.

But the point of all of it is better, faster decisions for the business.

That is what finance is actually here for.

Stop waiting

If you are a finance leader, the most useful thing you can do this quarter is not approve another AI initiative.

It is spend an hour with the tools on a real piece of your own work — awkwardly, imperfectly, and without pretending you already know what you are doing.

That is what changed for me.

Not a strategy offsite.
Not a vendor demo.
A weekend project with my son.

The question is not whether your team will use AI.

The question is whether you will lead that shift, or keep waiting while someone else does.

I’m a big fan of AI.

I’ve been using it heavily for months, and it can do some genuinely amazing things.

It can help me get past the blank page. It can help me synthesize information faster. It can help me structure thinking, test ideas, and move much more quickly than I could on my own.

But when it gets real work wrong, it really blows up.

That is the part of the story I think we talk about less.

Most of what gets posted about AI is the win. The smart summary. The fast draft. The impressive output. The productivity gain.

Those examples are real. I’ve had plenty of them myself.

But I think the more useful story is where it breaks.

Because real finance work is messier than the demo. It is not just about producing output. It is about judgment, hierarchy, context, review, and execution quality. And when AI misses one of those, the time you thought you were saving can disappear very quickly.

Over the last few months, I’ve had at least three moments where I thought AI was going to save me time — and didn’t.

1. The QBR deck

I gave AI the prior structure, tone, and format and expected it to help me move faster on a QBR deck.

What came back looked usable at first glance.

It wasn’t.

The layout was off. Visuals overlapped. The flow needed work. I ended up spending multiple rounds fixing the output just to get it back to something functional.

That was a useful reminder.

AI can help with content.
It can help with structure.
It can help get you started.

But it is still not a reliable design workflow for high-stakes finance materials.

I’ve seen people say AI can already do what a junior analyst can do. On this task, it was nowhere close.

The problem was not that it produced nothing. The problem was that it produced something that looked close enough to be tempting, but not accurate enough to trust.

That is a dangerous middle ground.

Lesson: AI can accelerate draft creation. It still struggles when the work depends on layout, hierarchy, and presentation quality.

2. The feedback summary

In another case, I asked AI to synthesize team feedback into something I could share back.

The output was fine.

Not bad. Not wrong. Just average.

Then I saw another team’s version and immediately understood the difference.

Their setup was better.

They had defined the audience more clearly.
They had been more specific about format.
They had a tighter view of what “good” looked like.

Same tool. Different setup. Better result.

That experience was a good reminder that a lot of disappointing AI output is not really a model problem.

It is a context problem.

When the audience is unclear, the format is vague, and the standard for quality is loose, the output usually reflects that.

Vague input produces generic output.

Clearer setup raises the ceiling.

That matters in finance because so much of the work depends on shaping the message for the right audience, in the right format, with the right level of precision.

Lesson: AI performs much better when the audience, format, and standard for quality are defined up front.

3. The visual

The third miss was more visual than analytical, but the lesson was the same.

I asked AI to help me create a visual for one of my articles.

One version gave me a person with three arms.

Another presentation had duplicate elements. And no matter how hard I tried to prompt it, I could not get it fixed cleanly.

Eventually, I had to start over.

That reinforced something important: AI can look impressive in the draft stage and still fall apart when precision really matters.

The problem was not a lack of effort. I kept trying to refine the prompt. I kept trying to correct the output. But the more I pushed, the more obvious it became that the system was not going to reliably resolve the issue the way I needed it to.

That is where a lot of AI frustration comes from.

Sometimes the problem is not that the tool failed completely.

It is that it failed just enough to consume more time than it saved.

Lesson: once the work depends on precision, layout, or visual coherence, prompt quality alone is often not enough.

The pattern

The pattern I keep coming back to is this:

AI is very good at first drafts.
It is much worse at final judgment.

That is still my working rule.

AI can own the first draft.

Humans still own the structure, the hierarchy, and the judgment call.

That is not a knock on the tool. It is the operating reality.

And honestly, I think more leaders should talk openly about the misses.

If your team only hears the wins, they will be less likely to show you where AI broke.

And if they do not show you where it broke, you will never build repeatable workflows around it.

That matters in finance because trust is everything. If teams are quietly hitting problems but only publicly sharing wins, leadership gets a distorted picture of what is actually ready for scale.

The point is not to become cynical about AI.

The point is to become more operationally honest about where it works, where it still breaks, and what kinds of work still need stronger human review.

That is how you move from demos to dependable workflows.

What has AI gotten wrong for you in real work lately?

A lot of finance teams are still talking about AI maturity the wrong way.

The conversation often sounds like this:

• Which model is better?

• What prompts are people using?

• What tool should we standardize on?

• How do we get the team to experiment more?

Those are fair questions. But they are not the most important ones.

The real question is this:

Where is AI actually creating value in the finance function today — and what has to change to move that value forward?

That is the lens I keep coming back to.

Because AI maturity in finance does not come from getting better at prompts. It comes from moving from individual productivity to repeatable, governed value creation.

That is what I think of as The Finance AI Value Curve.

It is not a model for judging whether a team is “good at AI.”
It is a way to understand how value shows up, how it evolves, and what leadership has to do differently at each stage.

Stage 1: Productivity

At the first stage, AI helps individuals work faster.

This is where most teams begin, and honestly, that makes sense.

The early use cases are familiar:

• rewriting emails

• summarizing documents

• cleaning up presentations

• turning notes into a first draft

• helping someone get past the blank page

This stage matters more than people sometimes admit.

It builds comfort. It lowers resistance. It gives people a reason to try the tools in work that feels low-risk and familiar.

But the value here is usually local.

One person saves time. One task gets easier. One deliverable gets cleaned up faster.

That is useful. It is just not transformational.

At this stage, leadership’s job is not to demand scale. It is to create permission to experiment and reduce the friction around adoption.

Stage 2: Analysis

The next stage is where AI starts helping people understand the work, not just move through it faster.

This is where it becomes more interesting for finance.

Examples might include:

• walking through a model someone else built

• asking questions about a complex file

• getting a first-pass read on variance drivers

• using AI to improve SQL or Python logic

• synthesizing research before a planning conversation

This stage is not just about speed. It is about analyst leverage.

A good analyst still has to think, judge, and decide what matters. But AI can help shorten the path to understanding.

That matters in finance because so much of the work is not just producing output. It is making sense of the output, spotting what matters, and framing it for someone else.

At this stage, leadership’s job is to help the team use AI to deepen understanding, not just accelerate activity.

Stage 3: Workflow

This is the point where the conversation should start changing.

Because once AI is helping with recurring finance work, the question is no longer “Can this tool do something useful?”

The question becomes:

Can this be turned into a repeatable workflow?

This is where the value starts to compound.

Examples might include:

• monthly commentary

• recurring reporting packs

• reconciliations

• forecast support

• standard management reporting prep

A lot of teams get stuck before this stage because they treat AI like a point solution.

They ask:

• Can it summarize this?

• Can it write that?

• Can it answer this one question?

Those are fine starting points.

But a point solution is not the same thing as a workflow.

A workflow has inputs. It has definitions. It has review points. It has expected outputs. It has to run again next month without starting from zero.

That is the difference between experimentation and operating leverage.

At this stage, leadership’s job is to standardize recurring workflows and define where AI belongs in them.

Stage 4: Decision Support

This is where AI starts moving closer to the reason finance exists in the first place: helping the business make better decisions.

At this stage, AI is no longer just helping produce work. It is helping improve the quality of decision-making.

Examples might include:

• forecasting support

• scenario planning

• working-capital insight

• management reporting

• surfacing patterns or questions that deserve attention

This is an important transition.

Because a lot of AI output looks useful until it enters a real business conversation.

That is where hierarchy matters. Judgment matters. Context matters.

A model can generate plenty of content. That does not mean it knows what matters most to a CFO, a business partner, or a leadership team in a given moment.

So the value at this stage is not “AI gives the answer.”

The value is that AI helps finance teams frame better questions faster, pressure-test assumptions, and bring more informed perspective into the room.

At this stage, leadership’s job is to improve decision quality — not just process efficiency.

Stage 5: Automation

This is where AI begins executing the first pass of work.

That might include:

• AP or AR support

• collections preparation

• contract review support

• reporting preparation

• close support

• exception identification

This is the stage people often jump to too early in the conversation.

They hear “AI” and immediately ask about automation.

But automation only becomes durable when the earlier stages are understood.

If the process is not clear, the data is not trusted, and the review model is not defined, then automation just lets a broken workflow run faster.

That is not maturity. That is acceleration without control.

At this stage, leadership’s job is to manage exceptions, define approvals, and make sure human oversight is clear.

Because the real challenge is no longer whether the tool can do something. It is whether the function knows how to govern it.

Stage 6: Orchestration

This is the point where AI is no longer helping with one task or one workflow.

It is coordinating work across people, systems, and controls.

Examples might include:

• multi-step finance workflows

• cross-system cash processes

• governed AI reporting

• workflows that move across planning, reporting, and operational systems

• coordinated outputs that require both automation and review

This is where scale starts to matter.

And it is where the conversation becomes less about AI as a tool and more about AI as part of the operating model.

At this stage, the leadership questions get sharper:

• Where does control sit?

• What is reviewed by whom?

• Which outputs are trusted?

• What can be audited?

• What definitions and rules govern the process?

• How do you scale the workflow without losing confidence in the output?

This is the stage where governance becomes real.

Not as policy language. As operational design.

At this stage, leadership’s job is governance, control, and scale.

Why this matters

I like this framework because it helps correct two common mistakes.

The first is assuming AI maturity is mostly about tool sophistication.

It is not.

A finance team with the newest model and the best prompts can still be immature if the work is fragmented, unreviewable, or dependent on one person.

The second mistake is assuming maturity happens all at once.

It usually does not.

It moves in layers.

First, people save time.

Then they understand more.

Then they build repeatability.

Then they improve decisions.

Then parts of the work are automated.

Then the workflows start to coordinate across the function.

That is a much more useful model than asking whether a team is “using AI” or not.

The leadership takeaway

The Finance AI Value Curve is not really about technology.

It is about how a finance function learns to convert AI from isolated productivity gains into repeatable business value.

That is why the leadership focus changes at each stage:

• At the beginning, leaders need to build comfort and adoption.

• In the middle, they need to standardize workflows and strengthen judgment.

• Later, they need to define controls, approvals, and governance.

That is the real maturity journey.

Not better prompts.

Better systems.

Better workflows.

Better decision support.

Better control over where value is created and how it scales.

Bottom line

The real AI journey in finance is not from better prompts to better prompts.

It is from isolated productivity gains to repeatable, governed business value.

That is the curve that matters.

And I think it is a better way to talk about AI maturity in finance than most of what we see today.

AI can already do a surprising amount with information outside your company.

I can ask it to compare earnings calls, talk through accounting topics, or even look at my son’s baseball stats and tell me whether they are good or bad for an 11U pitcher.

Once you see that, the next question comes fast:

Why can’t it do the same thing with our business?

That is the expectation shift happening inside finance right now. Leaders do not just want AI to polish an email or tighten a deck. They want to ask plain-English questions about the business and get back something useful: how the quarter is shaping up, where performance is strong, where it is slipping, and what needs attention. They want something that feels like a dashboard on steroids.

Some companies are getting there.

Most are not.

Most finance teams have ChatGPT. Almost none have connected it to their data in a way that produces trusted answers. The surveys confirm it.

Gartner’s 2025 AI in Finance Survey found 59% of finance functions are using AI in some form. But “using AI” and “asking AI about your numbers” are very different things. Wolters Kluwer found 86% of finance leaders are still exploring or piloting, with only 6% saying AI is scaled across the function. In a Vena study, just 3% of finance and operations professionals said AI was fully integrated into their workflows.

The bottleneck is consistent across the research: data quality, data availability, and data readiness.

This is not a personal failure. It is a systems problem.

And it is the same wall I kept running into.

Every path to connecting AI to finance data seemed to start with an engineering sprint. Someone mentions a semantic layer. Someone else mentions Cortex, Snowflake, or a new pipeline. Engineering gets looped in. A scoping conversation happens. The timeline slips to next quarter.

Meanwhile, the analyst is still pulling the same CSV into Excel, building the same pivot table, and writing the same QBR commentary by hand.

There is also a cost problem. Live natural-language queries against a warehouse are powerful, but they are not free. Ad hoc finance questions add up fast, and the first poorly scoped query against a large table is usually enough to shift the conversation from “how do we use this?” to “how do we govern this?”

What changed my thinking was a simpler question:

What happens if I treat the data as a document and build the business context around it manually?

It turns out you can get surprisingly far with a well-structured export, a Finance Context document, and a standing instruction inside a ChatGPT Project. No pipeline. No live warehouse connection. No sprint.

That is what I think of as the Data Wall.

The Data Wall is the gap between what AI can already do in public and what it can reliably do inside your business.

This piece is about how to work around it now, before the perfect integration is ready.

The gap between “using AI” and “AI answering my questions”

A lot of finance teams are already using AI for knowledge work: drafting, summarizing, editing, organizing, and pulling together information.

That matters. It saves time.

But it is not the same as asking:

What drove ARR this quarter?
Which segment missed plan?
Where is churn getting worse?
What should I worry about before the QBR?

Those are harder questions because they require AI to work with your actual numbers, in the right structure, under your company’s definitions.

That is where the wall sits.

The gap is not about willingness. It is about getting the right data into the model and giving the model enough context to interpret it correctly.

The data may exist. The dashboard may exist. The analyst may already know the answer.

What usually does not exist is a clean way for the model to access the right slice of data and apply the right business rules to it.

That is why this matters.

The near-term opportunity is not just waiting for a perfect integration. It is being nimble enough to create a usable setup before the ideal architecture arrives.

For most finance teams, that is the real opening.

What you are actually building

A ChatGPT Project is a persistent workspace. Files, instructions, and conversations stay together instead of resetting every time you start a new chat.

The setup has three parts.

First: the Finance Context document.
This is the file that explains how your business works: metric definitions, business rules, org structure, fiscal calendar, and column-name mappings. It is the difference between a smart-sounding answer and a finance-grade answer.

Without it, the model fills in the blanks on its own. It uses the wrong churn formula. It assumes a calendar year. It maps the wrong column to the right metric and answers with confidence anyway.

In a proper integration, a semantic layer handles this. In this setup, you are encoding that logic manually in a document.

It takes more work upfront. It makes every session after that much more reliable.

Second: the pre-aggregated data extract.
Not raw transactions. Not a massive flat file. A clean CSV at the grain you actually analyze: monthly metrics by segment, region, or product line. The same summary layer you already use for dashboards, QBR prep, or business reviews.

This is where ChatGPT’s Code Interpreter works well. Give it a structured summary file and it can produce variance commentary, trend analysis, and outlier flags quickly. Give it a messy transactional export and quality drops fast.

The goal is not to upload everything.

The goal is to upload the right layer.

Third: the standing instruction.
A short paragraph in Project settings that tells the model how to behave every time the workspace opens. Tell it to check the Finance Context document first, show its calculations, state the period and segment it is analyzing, and flag uncertainty or outliers.

That one paragraph removes a lot of drift.

The Finance Context document is where this lives or dies

This is the most important part of the setup, and the one most teams skip.

The common failure mode is simple: someone uploads a CSV, gets an answer that looks plausible, and uses it in a deck. Then they discover in the review that the number was wrong because the model applied the wrong business rule.

The data was there.

The context was not.

Every Finance Context document should cover five things.

Metric definitions
Not the textbook definition. Your definition. ARR as your company defines it. Gross margin the way your team reports it. Churn using your denominator, not the model’s guess.

Business rules
The logic that does not live in the data. Which regions roll where. Which items are excluded. What counts as closed won. What the export labels actually mean.

Org structure
How segments roll up, which products are in scope, and where naming in the source data diverges from naming in the deck.

Fiscal calendar
When quarters close, what your fiscal year looks like, and whether month one is February or July or something else. The model will assume calendar periods unless you tell it otherwise.

Column-name guide
A direct mapping from field names in the export to what they actually mean. This is one of the fastest sections to build and one of the most useful.

Assign an owner to this document. Review it quarterly. Drifted context creates the worst outcome: answers that look authoritative and are wrong in subtle ways.

What the workflow looks like

Once the Project is set up, the workflow is simple.

Open a new conversation inside the Project. The model reads the files. Then ask the question.

A clean prompt might be:

Using the uploaded data, summarize ARR performance for Q2 versus Q1 by segment. Highlight the two largest drivers of variance. Flag any segment where churn exceeded 2% in the quarter. Show your calculations.

That gets you a real first draft of analysis in seconds.

The prompt library matters almost as much as the setup. Build three to five reusable prompts for the recurring asks:

QBR variance summary.
Segment deep dive.
Executive headline draft.
Ad hoc metric pull.
Trend explanation.

The leverage compounds when the team stops rewriting the same prompt every quarter.

This setup really earns its keep on ad hoc requests. When an executive asks what net new ARR looked like for mid-market last quarter versus the prior two quarters, the analyst can open the Project, run a scoped prompt, check one trusted anchor number, and respond in minutes.

No ticket. No queue. No wait.

What this setup cannot do

This is a workaround, not magic.

There is no live refresh. The data is a point-in-time snapshot. For closed-period analysis, that is usually fine. For live numbers, you need a fresh export.

Large files will hurt output quality. Pre-aggregate before uploading. If you need detail, export the specific slice for that session.

Long sessions lose focus. If outputs start drifting, start a new conversation inside the same Project so the sources reload cleanly.

The model will not always flag uncertainty. That is why every workflow needs a verification habit. Before using any output in a deck or review, check one number against a source you already trust.

And governance still matters. Strip PII, deal names, and employee identifiers. Confirm the export is permitted under your AI policy before anything gets uploaded.

Why this is the right move right now

The data-readiness problem is not getting solved this quarter. Enterprise data work takes time. Semantic layers take time. Integrations take time.

In the meantime, expectations have already changed.

Finance teams still have QBRs. They still get Tuesday-morning questions from the CFO that need an answer by noon. Analysts are still spending too much time rebuilding the same first-pass analysis by hand.

And now leaders are asking those questions with the assumption that AI should help.

That is why this setup matters.

It closes a large part of the gap without waiting for infrastructure that may be quarters away. It lets the team start learning now: which definitions break first, which exports are most useful, which business rules are missing, and which questions come up every single cycle.

That learning compounds.

It also makes the eventual integrated solution better, because the team already knows what the model needs in order to be useful.

The teams that will look smartest a year from now are not just the ones with the cleanest architecture.

They are the ones that built the data and context layer early.

Start here this week

Pull the summary export you already use for your next business review.

Do not start with raw transactions. Start with the file you already trust.

Build a minimum viable Finance Context document with metric definitions, fiscal calendar, segment rules, business logic, and a simple column-name map.

Upload both into a ChatGPT Project.

Before asking a real question, write down one number you already know.

Ask the model to retrieve it and show its math.

If it gets it right, ask the question sitting in your queue.

The goal is not to replace your data infrastructure.

The goal is to stop waiting for a perfect system before building something useful.

That is how you start breaking through the Data Wall.

AI adoption does not happen because a leader announces it. It happens the moment someone on the team sees it help with a problem they already have. Everything in this article is built around that idea.

How I got there

I started with code. I almost stopped there.

When I first started using AI seriously, my mental model was narrow. I had been using it to build a game with my son — generating code, debugging logic, and working through problems I would previously have assumed required an engineering background. That was the use case I understood.

I could see pretty quickly that teams like mine would be able to create and modify code faster with tools like this. What I assumed, though, was that most other finance use cases would require full system integration before they became truly useful. I thought the gap between what AI could do and what finance teams needed was still too wide.

Then an analyst sent me a model.

The moment the use case became real

It was a finance model with multiple complex formulas, lookups, and logic that had built up over time. Normally, that is the kind of file where you ask for a walkthrough. Instead, I loaded it into ChatGPT and asked it to explain, in plain English, what the model was doing and how the logic worked.

It oriented itself quickly. Within a few minutes, I had a clear explanation of how the file flowed, where the logic was concentrated, and what I should pay attention to. I had not given it much context beyond the file itself, which is what made the moment stand out.

Once it gave me the logic back in plain English, I pushed further. I asked how the same analysis could be run in Python and how the workflow might be made more repeatable.

When I shared the output with the team, the first reaction was simple: “Can you show me how you did that?”

That was the moment.

Not because AI had replaced the analyst. It had not, and that was never the point. It mattered because people could suddenly see a practical use case. AI could help them understand work faster, explain logic more clearly, and start turning file-based effort into something more repeatable.

What changed after that

Sharing it opened the door.

I started carving out 10 minutes in each staff meeting to talk about AI, and I brought this example in first. Not as a formal presentation. Just a simple discussion of what I tried, what happened, and what I learned. The goal was not to turn the meeting into an AI workshop. The goal was to make it clear that this was worth discussing, worth experimenting with, and important enough for the team to learn together.

That mattered in a way a broad email announcement would not have. An email says AI is a priority. A recurring discussion in staff says the leader is actually spending time on it and expects the team to build judgment around it. Those are different signals. Teams read them differently.

Within a few weeks, I started hearing new examples. Someone had used it to clean up a messy data export. Someone else had used it to test a complex rules model. Another person had used it to explain a formula they inherited from a model they did not build.

Small things. But each one came with a better question: “Is this the kind of thing you had in mind?” or “What else should I try?”

That is the conversation you want.

The discussion changes. People stop asking, “Should we use AI?” and start asking, “Could this help me get to a first draft faster? Could it help me pressure-test a forecast? Could it help me summarize what matters in the data?”

That is the shift — from theory to workflow.

The leadership point

AI adoption does not happen because a leader announces it. It happens when a leader makes time for it, shows examples, and creates permission to experiment.

Those three things together — leader attention, real examples, and permission — move teams in a way that policy statements and training programs usually do not.

In practice, that looks like five things:

• Make time for AI in a visible, recurring way. A short show-and-tell in staff can do more than a broad email announcement.

• Use real examples. A model, a forecast draft, or a narrative rewrite will teach more than a generic vendor demo.

• Reward experimentation, not just success. Teams learn faster when a failed test is treated as useful information instead of wasted effort.

• Help people build intuition for where these tools are useful: first drafts, pressure tests, summaries, scenario framing, and data-to-narrative work.

• Be explicit about guardrails. Use enterprise-approved tools, clarify what data is allowed, and keep judgment with the team.

What slows adoption

The patterns that slow teams down are consistent.

Telling the team to use AI without showing them what it looks like on real work.

Waiting for perfect data, live system connections, or a companywide IT program before allowing the team to start learning.

Using abstract vendor demos instead of real finance work the team already recognizes.

Treating every experiment like it needs to be production-ready before it is worth sharing.

You can start with exported files, raw reports, and real work that already exists inside finance. Learn what the tools can do first. Build the process, controls, and integrations as you go.

A simple 30-day leadership play

Week 1: Show one real example in staff using a finance workflow people already recognize — a model, a forecast draft, or an analysis rebuilt from a raw file.

Week 2: Ask each leader or analyst to test one small use case and report back what they learned.

Week 3: Compare outputs, discuss what still needed human judgment, and capture the best prompts or workflows.

Week 4: Decide which one or two use cases deserve to become repeatable team practices.

Bottom line

If you want your team to use AI, do not start with a mandate.

Start with a real example and a recurring place to discuss it.

Show them something they recognize. Make room for experimentation. Keep the guardrails clear.

That is when AI stops feeling like a corporate initiative and starts becoming part of how the team actually works.

Finance Leadership, AI in Finance, FP&A and AI

My world has always been models, planning, forecasts, business reviews, Excel, and PowerPoint. I do not come from a coding background. Until recently, I had never built and deployed an application myself.

Then one weekend, my son and I built a college football simulator.

Not bought. Not downloaded. Built.

What made it even more meaningful was why we built it.

After watching Indiana’s turnaround, my son got fixated on the idea of taking over a program and building it into a winner. That was the hook for him. He wanted to recreate that feeling - the challenge of taking something struggling and turning it around through smart decisions over time.

For me, that tapped into something familiar too.

I grew up loving sports games, but what I always liked most was not just playing them. It was building. Recruiting. Managing a roster. Making tradeoffs. Developing a system. Trying to turn potential into performance.

So when my son asked, “Could we build our own version of that?” it stopped me for a second.

A year ago, I would have said no.

Not because it was a bad idea, but because I would have assumed it required technical skills I did not have and a path I would not know how to navigate.

This time, I approached it differently.

I described what we wanted in plain English. AI helped generate the code. I tested it, reacted to what I saw, adjusted the logic, refined the outputs, and kept going. When I got stuck, I asked questions. When something broke, I described the issue. When I did not understand a step, I asked for an explanation.

What struck me was not just that AI could produce code.

It was that it made the process accessible.

It gave me a way to move from idea to working product without first needing to become a software engineer.

By the end of the weekend, we had a functioning simulator.

That alone was exciting. Building something with my son made it even better.

But the bigger insight came a little later.

As I was working through the model logic, I realized I had seen this structure before. Many times.

The game had:

• a data layer

• a simulation engine

• a resource allocation layer

• a user interface

That is not just a game architecture.

It is also a finance architecture.

In finance, we use different language. Actuals. Drivers. Assumptions. Scenarios. Resource allocation. Dashboards. Decision support.

But the structure is the same.

That was the moment AI clicked for me.

Finance professionals already know how to think this way. We already understand how to structure models. We already know which drivers matter. We already know the business context that makes a tool useful instead of just interesting.

What we often have not had is the ability to build and ship tools ourselves.

AI starts to change that.

Not because every finance professional now needs to become a software engineer. That is not the point.

The point is that people with deep domain expertise now have more leverage.

If you understand the business, understand the decisions, and understand the model, AI can help close the gap between knowing what should exist and actually building it.

That has major implications for finance teams.

Scenario planning. Forecasting tools. Variance analysis. Internal apps. Decision support tools. Workflow automation. Executive-ready interfaces layered on top of complex models.

These are not abstract ideas anymore.

They are increasingly buildable.

That is what stayed with me after that weekend.

At first, I was excited because we had built something fun together. But very quickly, that excitement turned into something bigger: curiosity about what else might now be possible, and motivation to figure out how to apply it to my day-to-day work in finance.

That is the part of AI I find most interesting.

Not AI as entertainment. Not AI as hype. Not AI as a generic productivity tool.

AI as a capability layer for domain experts.

That is what I want to write about here.

Where AI is useful in finance. Where it is overhyped. What finance teams should actually experiment with. What skills matter. What workflows are worth rethinking. And how people without technical backgrounds can still get started.

My view, at least right now, is simple:

The biggest beneficiaries of AI may not be the people with the deepest technical skills.

They may be the people with the deepest domain expertise.

Finance is one of those domains.

And for me, that realization did not come from reading about AI.

It came from building something with my son and realizing I wanted to bring that same mindset into my everyday work.

If that is your world too, you are in the right place.

So when AI started moving into the mainstream, my first reaction was not excitement. It was concern.

I think a lot of finance leaders had the same question: What does this mean for my role, my team, and the kind of work we’ve spent years mastering?

What changed my view was using the tools.

The more I worked with AI, the more I realized this is not just a story about disruption. It is also a story about leverage. Used well, AI can help finance teams move faster, synthesize information more effectively, and spend more time on judgment instead of friction.

And this is already happening across the finance function. Gartner reported that 59% of finance leaders said their finance function was using AI in 2025, up from 37% in 2023. KPMG found 71% of companies surveyed are using AI within finance operations, with 41% using it to a moderate or large degree. Deloitte’s Q4 2025 CFO Signals survey found 87% of CFOs expect AI to be very or extremely important to their finance department’s operations in 2026.

So this is no longer a future topic.

It is a leadership topic.
It is an operating topic.
And for finance teams, it is quickly becoming a real management topic.

What changes now is not the importance of finance. It is the shape of the work.

AI can help reduce the time it takes to get from blank page to first draft, from scattered inputs to synthesis, and from data to decision support. It will not replace judgment. But it will increase the value of people who can apply judgment well.

That is why I started AI for Finance Leaders.

This publication is for finance executives, FP&A leaders, analysts, and operators who want a practical point of view on how AI is changing finance work.

I’ll be writing about planning, forecasting, analysis, workflow design, and where human judgment still matters most.

My goal is simple:

Make this useful.

Where do I start?
What should I be asking my team?
What are the best use cases?
What is real, and what is just noise?

That is what I want to explore here.

Welcome.