When Finance Becomes a Builder: Figma’s Case for Automation With Accountability

1. Guest Background

Praveer Malani, identified in the episode as Figma’s chief financial officer, approaches automation through an operating question: how can finance help people understand the business and act on that understanding? Across this roughly 50-minute interview, he discusses his own data work, his team’s emerging applications, and the organizational responsibilities that follow when more employees can build software. His examples are accounts of internal practice, rather than independently evaluated productivity studies.

His relevant experience predates the AI workflows discussed here. Early at Figma, he recalls writing queries of roughly 400–500 lines to map product usage and utilization data to financial information in Stripe. He created standard tables, then asked data scientists to incorporate them into recurring ETL jobs feeding systems such as Salesforce and Marketo. The benefit he emphasizes is a common factual foundation: colleagues could spend less effort debating definitions and more effort discussing business action.

That work also involved close attention to individual customers. Malani remembers examining about 30 paid signups a day during his early tenure, checking personal versus business addresses and possible contacts to inform his understanding of an eventual organization-level product. Today, he describes reviewing hourly dashboards and daily metrics, with the expectation that his team will identify anomalies and opportunities promptly. These experiences establish the perspective behind his argument: finance leadership combines data construction with operating judgment. The supplied evidence does not establish a fuller career history.

2. What the Episode Covers

The interview makes its case through work already being attempted inside finance. Malani describes Kajal, on the credit and collections team, rebuilding a workflow spanning invoice tracking, cash collections, and reconciliation to NetSuite. Kajal then extended the approach into credit checks and connecting fragmented datasets. Malani presents the resulting capacity as an opportunity to focus on receivable days and other consequential work while allowing colleagues to reuse the tools. He does not report a measured reduction in collection time, receivable days, or labor hours.

Corporate development provides a different application. Team members with finance backgrounds try recreating a target product during diligence to develop an intuition for technical difficulty and defensibility. They still collaborate with product specialists, but can enter that collaboration with something concrete to examine. They also encode recurring leadership questions into personalities or skills that review investment and acquisition memoranda. Malani says this helps identify arguments needing reinforcement or further diligence and reduces time spent in collective review; no numerical improvement is supplied.

These efforts use a mixture of tools. Malani mentions Codex, skills and workflow automation around ChatGPT agents, and emerging applications built and hosted through Figma Make. The episode’s common thread is employee agency: people closest to a task can attempt a solution themselves. That freedom also changes what a manager must inspect. In his VP Finance hiring process, Malani permits available tools but asks candidates to explain their model’s structure, sensitive variables, and business implications. Producing an output and understanding it remain separate achievements.

The conversation also examines the burden created by effortless production. Malani says Figma has policies identifying AI-written material and expects authors to read, understand, summarize, and simplify it. A document consumes the recipient’s time even when generating it was easy. Internally, leadership demonstrations, show-and-tell sessions, hackathons, and exchanges with external finance leaders help circulate more useful practices. He reports employees connecting the freedom to explore with enjoyment and willingness to stay, and says he now raises technology access in recruiting. Those reports describe sentiment, rather than measured retention effects.

The intended destination is more substantial finance work. For the team supporting Figma’s self-serve business, Malani wants less time spent reconciling last week or last month and more time interpreting experiments, identifying trends, and deciding where additional spending belongs. Automating recurring materials, he says, has begun improving speed and quality while leaving people to concentrate on annotation and understanding. He offers no quantified result, and acknowledges that expanding business complexity continues to compete for the time automation might release.

3. Core Views: Reasoning, Examples, and Limits

The interview’s strongest proposition is that building becomes valuable when it improves the connection between business questions and trustworthy information. Malani’s early SQL work illustrates the mechanism: common tables and definitions gave colleagues a shared basis for discussion. AI expands who can attempt that work, but does not settle what the underlying numbers mean. A participant’s account of customer success representatives at another company producing dashboards with different figures exposes the distinction. Access to construction tools can multiply representations of the business while leaving reconciliation unresolved.

The travel and entertainment example shows why the difficult work often sits beneath the interface. During a review for 2027 planning, Figma’s team combined information from multiple sources and used fuzzy matching to interpret circumstances such as attendance at an offsite, travel, and residence. Someone’s presence in a city does not by itself establish the nature of the expense. Malani estimates that getting the data into shape represented 95% of the challenge in that particular exercise. He also recalls requested visualization changes appearing about 30 minutes after his feedback. These are a case-specific estimate and a reported incident, respectively; neither establishes a universal performance benchmark.

His willingness to accept directional accuracy in that review is equally consequential. The analysis was meant to reveal areas for policy examination and further investigation. That purpose permits a different tolerance from controlled accounting output. Malani credits accounting experience among finance-supporting data scientists with helping them understand refunds, uncollectible amounts, checks and balances, and requirements for correctness. He separately calls audit-ready output in a business-critical system an extremely high bar, including the need to understand what auditors will accept. The reasoning is therefore conditional: an approximate classification may help locate a question without being adequate to settle an accounting conclusion.

A second proposition concerns the relationship between automation and expertise. Malani’s case interview probes whether a candidate can explain a model’s structure and sensitivities because a fluent output can conceal weak understanding. The corporate development examples carry the same boundary. Recreating a product can make technical discussion more concrete, yet the team continues working with product specialists and Malani acknowledges nuance. A recreation attempt alone cannot establish a company’s defensibility. Likewise, simulated leadership feedback can reveal unanswered questions in a memorandum without assuming the authority of the actual decision-makers.

The organizational argument follows from the lifespan of a useful tool. Malani identifies similar patterns of collecting information, following up, triaging, and reconciling across internal audit, GRC, and accounts payable. Specialists understand these problems and can prototype quickly. A CIO organization can then address upstream dependencies, hosting, reuse, and continuity when an employee leaves. This division preserves local discovery while recognizing that shared infrastructure creates obligations beyond its original task. It remains a proposed direction within an unfinished transition: Malani describes Figma as partly centralized and partly decentralized, rather than presenting a completed governance model.

Formal metrics impose another boundary. Malani says finance owns these outputs and values consistency across board, leadership, and earnings communication, with stable historical figures and durable definitions. Easier access to code does not itself justify changing the business’s reported meaning. His account of CFO creativity concerns new ways to understand and influence the business, alongside accounting knowledge and planning discipline. Communication, relationships, and trust matter because an analysis changes little until other people understand it and coordinate action; he acknowledges initially underestimating those skills.

Finally, the episode does not establish an automatic conversion from experimentation to savings. A participant recounts another company building 40–50 agents in a month or two, then explicitly guesses that perhaps 90% were no longer used. The defensible lesson is about developing an automation habit, not a measured abandonment rate. Malani’s staffing prediction is similarly qualified: fewer people might be needed if business complexity stayed constant. New products, acquisitions, and evolving operations continue increasing Figma’s support requirements. Any claim about headcount must retain that condition rather than treating efficiency as a fixed staffing formula.

4. Learning and Application

A practical starting point is to name the decision a workflow should improve. For collections, Kajal’s example suggests examining the manual connections among invoices, cash receipts, and reconciliation, then asking whether better coordination lets someone address the exceptions that matter to payment. The episode supplies a useful problem-selection pattern, but no verified savings baseline. An implementing team should therefore distinguish a functioning workflow from shorter processing time or improved receivable performance, recording those outcomes separately before claiming a business benefit.

Next, establish whether the data can support the intended decision. One participant recommends a sequence of data integrity, access, and tracking, followed by reporting discipline, metrics, and narrative. The warning about revenue calculations unsuited to a business model makes this more than a technical housekeeping exercise. Missing tracking requires new records; inconsistent meanings require agreement about definitions. A generated interface cannot recover events that were never captured or decide on behalf of the organization what revenue should represent.

The execution design should distinguish deterministic steps from permissible inference. An exploratory expense review may use approximate matching to flag patterns, provided ambiguous classifications remain available for examination. Controlled reconciliation needs stronger verification. Malani’s buy-versus-build approach offers one boundary: purchase core systems of record and solutions for areas the business cannot afford to get wrong, while building around repetitive workflows. That is a practical preference described in the interview, not a guarantee that purchased software is correct. Business-critical outputs still require explicit checks and discussion with auditors about acceptable evidence and operation.

Model review can combine explanation with direct manipulation. Ask the author to identify inputs, structure, sensitive variables, and the business decision a changed assumption would affect. Then inspect those relationships in the model. Malani’s use of AI to identify drivers in a 20-tab workbook is useful as a way to prioritize attention; his attachment to Excel reflects the value of exploring relationships directly to build understanding and trust. General-ledger flux analysis offers a similar division of labor: a tool can suggest explanations and investigative threads, while an accountant follows the evidence before accepting a conclusion.

Once colleagues depend on a prototype, assign responsibility for hosting, upstream dependencies, maintenance, sharing, and handover. Business specialists can validate the need before a systems team decides which components merit reuse. This adds coordination work, but addresses duplication and dependence on an individual creator. Internal demonstrations and peer learning can spread the approach, especially when people explain the data connections and failure conditions alongside the successful output. Evaluate experiments, sustained use, and business effects separately; the anecdote about abandoned agents supplies no reliable conversion rate among them.

Finally, allocate any released capacity deliberately. The self-serve finance example points toward experiment interpretation, trend investigation, and incremental budget decisions as concrete destinations. Those uses depend on verified materials and people having time and authority to pursue the questions. Growing complexity may absorb much of the capacity, so the episode does not justify promising staff reductions in advance. A more useful assessment asks whether the team notices important changes sooner, can explain what requires further investigation, and turns that understanding into an informed operating decision.

Source

• Original episode: How AI Is Turning Figma’s Finance Team Into Builders