Amanda Whalen is CFO of Klaviyo. She joined in May 2022 and took the company public 16 months later. Before Klaviyo she was EVP and CFO of Walmart International, running finance across 8 markets and more than $90 billion of revenue, and before that Walmart’s SVP and Treasurer, where she led the digital rebuild of the FP&A function. For the last 2 years, Amanda has been turning a finance org of accountants and billing specialists into a team that writes its own tools.
My main advice to any finance leader starting this is not to begin with the grand master plan.
Five years ago, transformations had a program management team, multi-year plan, phases, and a lot of meetings about how to break it down into pieces. It was a lot like waterfall software development.
“The big difference today is it is much more real-time, much more citizen or developer-led, and you really need to engage your entire team in doing the building and implementing what’s going to work. Don’t feel like you need to start with a grand master plan. Start with a strong group of energized people who have learned how to build themselves, and let that energy drive your transformation.”
Our remaining performance obligation process (RPO) used to take 5 people about 4 to 5 days. It now takes them about 10 minutes. The agent now reads the contract, identifies the relevant clauses, takes a visual snapshot, extracts the data into our standard template and puts the snapshot right there next to it for supporting proof, and the template runs the calculations the way it always has.
Other finance leaders ask me about how we got here. The project before it was renaming screenshots for audit files. We started by looking for tedious things like that to automate and went from there. We would not have gotten to RPO so fast without doing a lot of small things first.
Pick something small enough to build in front of everyone
When you pull evidence for an audit you are matching a posted invoice back to its PO, and the file name has to carry the PO number and the invoice number so that anyone can find it again in 2 years’ time. Someone on our accounting team automated the capture and the naming.
“Nobody goes to school thinking, when I grow up I want to clip screenshots and rename them with the file name I need. It only takes a little time on an individual basis, but it adds up, and quite frankly it’s boring.”
This would take a Klaviyo accountant a few hours a month. It was the best first project to automate because an accountant built it without needing our BI team or a vendor, and the rest of the company watched her do it as her solo hackathon project. The time saved wasn’t substantial. But afterwards, people across the department started coming to me with the tasks that annoyed them and ideas for how to get rid of them.
I would rather have 10 small projects running at once, built by 10 different people who really know what they need, than one big automation that somebody else built for our team.
So when people ask me how to pick the first project, I tell them to look for something repetitive that one person owns and openly resents doing.
Keep it voluntary
Our people team ran the company-level work, with sessions for everyone and brought in outside help, including people from Cursor to show Klaviyos what AI tools can do rather than what they promise.
In finance we added a weekly session, which we called ‘AI learning parties’. Some weeks we picked a topic and learned about it. Other weeks, we built something together during the session. Sometimes someone on the finance team would show us what they’d built that week and we would go through the steps to an MVP.
“The idea was to create a regular safe space for people to spend time together learning, exploring and experimenting. At one point, it was completely voluntary, and we had about three quarters of the team joining every week, because the sessions were just fun.”
Mandatory training would have got me attendance and nothing else.
I also stopped opening these sessions with why this matters to Klaviyo. An analogy I picked up early in my career is that there is a wall between people and the thing you want them to achieve. You can keep telling them to climb it, or you can take it down. Telling someone exercise is good for them rarely gets them to the gym. Buying the membership and laying their clothes out the night before usually has a better chance. So I tried to take away whatever was stopping people from starting.
“Instead of saying here’s why this is important, the way I frame it is here’s why this is great for you.”
In finance the wall was one of 2 things. Either people believed they were being asked to automate their own jobs away, or they believed building software was somebody else’s problem. Both of those started to change once someone on the team built something and everyone else saw it.
18 months ago, one of our billing specialists asked me what a prompt was. 6 months later she had built a tool that reconciles Salesforce against NetSuite and flags the discrepancies for her to investigate.
“Nobody wants to spend their time cutting and pasting and doing visual comparisons of data. You want to be investigating why, and solving the root problem. You want to be thinking about what drives this accrual, and whether it’s actually valid.”
Save the big process for later
RPO is one of the more complicated processes in SaaS accounting. A transformation program 5 years ago would have put it in phase 1, because the hours are so visible, but it would have taken six months of planning, scoping, and developing requirements just to get to phase 1.
We got to it after those same six months, but not six months of planning. We had spent six months building small things and seeing them work, which gave us confidence to take on the big one. A small cross-functional group redesigned the process end to end: someone from our BI team with data engineering experience, plus the revenue accountants who own it.
Everybody on that revenue accounting team had already shipped something of their own. They knew where AI tools fall short based on experiences with small projects leading up to this.
The extraction lands in the same standard template we have always used, and the calculations sit where they always sat, which is what makes it reviewable. All of the time we saved came out of the data gathering.
Be precise with data definitions
When I joined, a question like how fast ARR is growing in Europe went into a queue with our BI team. We moved that to Google Sheets, then to reporting tools that covered the questions we expected people to ask.
Now we have a tool we built called KBI. It works like an internal search engine for the business. Anyone at Klaviyo can type a question in plain English, like how many customers we added in Germany last quarter, and get the answer straight from our data without needing an analyst’s help.
That moved the bottleneck to data governance. If you ask what is happening to churn among small customers in Australia, you have to know what counts as a small customer, whether churn is gross or net, logo or dollar, and which date it is measured from. A BI analyst used to carry all of that knowledge in their head and apply it the same way every time. In effect they were the governance layer.
“You really do have to be very precise and knowledgeable about what the data definitions are. It has increased the importance of data governance, and increased the importance of education across our business in the way that we define and use data.”
KBI has ended up mattering more than we expected when we built it. A while after launch our CEO started putting quiz questions into the leadership team Slack channel that you can only answer by using KBI.
Staff finance with builders
We have an internal company-wide team of expert AI builders, and finance is not near the priority list. If those employees can change the working day for a few hundred people in GTM or engineering, that is where they should be. Finance is a small team with a long tail of specific processes, which means we have to do a lot of it ourselves.
That has to show up in how you staff. At our June offsite we went through every part of the team and listed the projects too big to do alongside a day job. We revisit that list and its order regularly, and put a small group on whatever is at the top. Some people in finance are now part-time builders and some are full-time. That builder role was not on my org chart 2 years ago.
The list from June is longer than we will finish this year, and the next one will be longer again. You can’t hire a team to work through a list like that. Your own people have to learn to build, which is why I would still tell somebody to start with the file names and not the 5-day close.