Do It Twice, Write a Workflow. Write the Workflow Twice, Write an Agent. It's a Good Rule — and It Is Missing Two Things Your Finance Team Can't Ignore
Do It Twice, Write a Workflow. Write the Workflow Twice, Write an Agent. It's a Good Rule — and It Is Missing Two Things Your Finance Team Can't Ignore
A one-line operating rule from a16z, turned into something a two-to-five person finance team can actually rank work with.
A piece published by a16z on 8 October, You Need a New CFO, contains a sentence worth more than most automation frameworks: "if you do something twice, write a workflow; if you write the workflow twice, write an agent."
I like it because it replaces a judgement call with an observation. Most decisions about what to automate get made on enthusiasm — someone is excited about a tool, or irritated by a task. Frequency is different. Frequency is countable, it is already recorded in your month-end checklist, and it does not care who is excited.
For a finance team of two to five people, which is most of the organisations I work with, it is also the right order of magnitude. Nobody there is going to build an automation platform. They might build eight small things, and the question is which eight.
But the rule as written is a necessary test, not a sufficient one. Applied literally in a finance function it will put you to work on the wrong things first, because frequency is only one of three dimensions that matter, and the other two are the ones that bite.
What frequency leaves out
The cost of being wrong, and whether you'd notice. Reformatting a bank file and calculating a leave provision happen with similar frequency. One is self-evidently broken when it breaks. The other is wrong quietly, for a year, and then appears in an audit adjustment. Frequency ranks them identically. Nothing else does.
The evidence trail the output has to carry. A lot of finance work produces something that must still be defensible to an auditor, a funder or a regulator long after the person who ran it has left. That is not a quality concern, it is a structural one: an automation whose output cannot be traced back to a source and a sign-off has not saved you work, it has moved the work to a worse time. We went through what that record actually has to show in the piece on what your auditor will ask about AI.
There is a third, more mundane constraint that the rule does not contemplate at all: in a team of three, every automation has an owner, and that owner is already fully occupied. An unowned agent is a liability with a schedule attached.
The ranking, in three columns
Take your month-end checklist — the real one, not the documented one — and list every task that recurs. Then score each on three things, high / medium / low is enough.
Frequency. How many times a year does a person do this by hand? Twelve is the floor for interest. Fifty-two or 250 changes the economics entirely.
Error cost. If this is wrong, when does someone find out, and what does it cost to unwind? Same-day and self-correcting is low. Found at audit is high. Found by a funder is higher.
Evidence burden. Does the output need to be reproducible months later, with its inputs and its approver attached? Reconciliations, provisions, acquittals and anything feeding a statutory return are high. An internal working schedule is low.
Then sequence by this rule: automate high frequency and low error cost first. Automate high frequency and high error cost second, and only with a documented approval step. Leave low frequency alone no matter how annoying it is.
| Task | Frequency | Error cost | Evidence burden | Verdict |
| Normalising a supplier or roster export into a fixed layout | High | Low | Low | First |
| Producing an exceptions list from two datasets | High | Medium | Medium | Early, with sign-off |
| Drafting the first sentence of variance commentary | High | Low | Low | First |
| Calculating a provision or accrual | Medium | High | High | Later, never unattended |
| Annual grant acquittal pack | Low | High | High | Leave it |
Notice what that ordering does. It puts you on the boring preparation layer first — getting data into a consistent shape, producing lists for a person to decide on, drafting text a person will edit. None of it is impressive. All of it is reversible, checkable on sight, and used often enough that a week's effort returns a day a month.
It also keeps you away from the task everyone wants to start with, which is the one that is painful once a year. High pain, low frequency is the worst possible first project: you will build it, use it once, forget how it works, and rebuild it next year.
The second half of the rule deserves more suspicion than the first
"If you write the workflow twice, write an agent" assumes the second writing was caused by scale. Sometimes it was. Sometimes a funder or regulator changed the rules underneath it, and the rewrite is ordinary maintenance. But often, in a small finance function, writing a workflow twice means the workflow was wrong the first time — because the underlying process has undocumented variations nobody had enumerated.
When that is the cause, building an agent on top automates the variation instead of resolving it. The honest response to the second rewrite is to ask why the first one did not hold. If the answer is "because three of our twelve funders send the data differently", the fix is a standard, not an agent.
So I would add a clause: if you write the workflow twice, find out why before you write an agent. In my experience the answer often removes the need for one.
How this differs from measuring the pilot
This is a sequencing method, not a measurement one. Earlier I argued for building the measurement two weeks before the pilot — a baseline, a small number of measures and a written kill criterion. That tells you whether a thing you built is working. The twice rule, with the two extra columns, tells you which thing to build. You need both, in that order: rank, then baseline, then build.
And none of it says anything about the ambition in the a16z framing — that finance teams become smaller and more senior while the tooling gets built in-house. That claim deserves its own examination, which is tomorrow's post.
What we do with this ourselves
We run a version of this ranking across client engagements, and the honest summary is that the top of the list is almost always the same three categories: shaping data into a consistent layout, generating exception lists for a person to clear, and drafting narrative that a person then owns. The tools differ. The ordering barely does.
We are also building something in this space — a retrieval-based checker for payroll questions — and it is at early stages. I am not ready to talk about it in detail yet, for the straightforward reason that the interesting part is whether it holds up on edge cases, and we do not know that yet.
The part I am confident about is the ranking itself. It is cheap to run, it takes an hour, and it is the difference between eight small automations that compound and one ambitious one that gets abandoned.
Have you ranked what to automate, or just started with whatever annoyed you most?
The order matters more than the tool: the wrong first project costs a month and teaches a team that automation doesn't work. PFL provides senior-level outsourced finance, management reporting, and AI automation for Australian NFP, NDIS, and SME organisations — including running this ranking across your own close checklist.
Talk to PFL →
Comments
Post a Comment