How Emburse takes AI ROI to its board with LinearB

Emburse builds expense, spend, travel, and accounts payable software used by finance teams to control company money, serving more than 20,000 organizations across 120 countries. Behind it sits an engineering organization that ships across several product lines and is rapidly expanding in the new era of AI-first development.

Ken Ringdahl joined as CTO just over two years ago. Deni Spasovski, Director of Engineering, oversees the teams behind the SMB spend and expense products, Emburse Spend and Emburse Professional, and together with a colleague was given the mandate to bring every team into LinearB, make the data trustworthy, and help managers act on it.

Emburse stopped trusting delivery data once AI arrived

When Ken arrived, Jellyfish was the incumbent platform, and its use was concentrated in a few teams. Deni was its heaviest user and its internal advocate, but the platform had never been given an owner whose job was to drive it across the wider organization.

Two problems made the case for a change. The first was, by no surprise, AI. As coding assistants moved into the SDLC and became a core part of how the team worked every day, Emburse needed a reliable read on what those tools were doing to deliver, and the numbers coming back were hard to square with what leadership saw on the ground.

The second was where the data came from. Jellyfish reads from Jira, so its numbers carry whatever inconsistencies sit in the ticketing process, and no engineering organization keeps that perfectly uniform across every team. A stretch where teams caught up on tickets in bulk could move the reported numbers without anything changing in how the software was built, which made trends hard to read. Ken wanted delivery data grounded somewhere that held still.

Pre-built reports they could use on day one decided the evaluation 

Switching platforms is a significant decision, requiring careful consideration, so Emburse treated the process methodically and thoughtfully. They looked at four vendors and ran proof-of-concept projects with two.

The criteria they defined up front:

• Source control as the source of truth, rather than the issue tracker
• Software capitalization reporting their finance team could use
• Baseline sprint metrics, as a full Agile shop
• Coverage across the AI tools they were using and might use, including Copilot, Cursor, Claude Code, and Windsurf
• DORA metrics that were straightforward to instrument, which in LinearB meant a deployment marker in their CI/CD pipelines rather than a large integration project
• Pre-built reports that their engineering managers could open and use without training or custom report building

LinearB won on that last one. Emburse has engineering managers spread across many products, and the platform had to work for all of them on day one, without training or custom reports to build first.

GitHub and Jira were connected during the POC, so LinearB was already returning live delivery data before the rollout formally began. Emburse then took its time on the human side, working through managers one at a time and holding a checkpoint where each confirmed their own team’s data was accurate.

Why Emburse only sets targets for pickup time and rework

Emburse works from a definition of what it is aiming at, one Deni used to close an internal metrics presentation.

Emburse measures a wide range of metrics and holds teams to two: pickup time under eight hours and rework under 7%. That restraint shaped everything after it. Teams act on both mid-sprint, while they can still change how it ends.

Pickup time is the target because review latency usually drives cycle time, and a team whose cycle time eats most of the sprint has little chance of closing what it committed to. When pickup time drops, the sprint becomes predictable.

Emburse is hitting both. Pickup time averages 6 hours 37 minutes against the eight-hour ceiling, and rework averages 2.82% against 7%.

Pickup time hit its low in March and has crept back up since, so Emburse keeps it on the dashboard instead of calling it solved.

The same LinearB data shows up in retros and board decks

Deni pushes one practice harder than the rest: "Use the LinearB data in the retrospective." Anyone at Emburse can get viewer access, so a whole team sees its own numbers rather than a summary of them. In the retro, each team works out its own cycle time problem and what it will change before the next sprint.

A level up, engineering managers are in LinearB weekly, starting with their team dashboard and their project delivery metrics, and leaders running several teams are in it more often than that. Ken takes the same data into the engineering and product all-hands every couple of months, using it to explain the reasoning behind a direction, because the data and the visualization "helps support the narrative and explain the why." Engineers are inquisitive, and they want the basis for anything they are asked to do.

When the board asks about AI ROI, Ken answers with LinearB metrics.

The results

• 39% faster cycle time, excluding deploy time, Jan to Jul 2026
• 35% lower cost per effective PR over the same period
• 8 months to ship a new AP product, against a 12 to 18 month pre-AI baseline

Emburse is clear about attribution. AI is the major factor behind the delivery numbers, and Ken says so directly. The new AP product shipped in eight months against a pre-AI baseline of twelve to eighteen, with a team half the size. LinearB shows them what that speed costs, so they can correct course while there's still time to act.

Cycle time down 39%, for a different reason on every team

Emburse cut cycle time from 11.6 hours in January 2026 to 7.0 in July, more than any other metric they track. The chart tracks cycle time excluding deploy time, because Emburse runs a broad set of CI/CD tools and is still consolidating them, so deploy time is measured separately.

No two teams got there the same way. Because each team reads its own numbers in its own retro, one finds slow reviews, another oversized stories, another unclear requirements, and each fixes the thing actually in front of it. Managers use the same per-engineer view to coach, with Deni tracking review counts for new joiners as an onboarding signal and pushing them to "do more reviews, read more code. That's how you learn the product faster."

Rework spiked, then came back inside a quarter

This is the part AI does not deliver on its own. When agentic coding tools arrived in late 2025, rework climbed sharply through November and December. Because Emburse watches rework as a leading indicator rather than a scorecard number, the climb was visible in real time, and teams changed how they broke work down in response. Rework was back under 3% by February and has stayed there.

Rework averaged 5.91% across the full window; the November–December spike accounts for nearly all of it.

Cost per effective PR fell as AI took over more of the work

In April 2026, AI-assisted merges passed unassisted merges for the first time, and by late July they were running at roughly double the unassisted rate. Most of Emburse's code now gets written with AI.

Over the same seven months, Emburse's effective PRs climbed by around 75%, while the cost of producing each one fell by around 35%.

Cost per effective PR weighs people cost, and AI spend against the pull requests that merged and did not come back as rework, so it only improves when more of what the team ships survives. Both lines come from the AI ROI dashboard in LinearB, which is where Ken gets the charts he takes to the board.

Looking ahead

Ken's position is that handing more of the SDLC to AI has to be earned with evidence rather than assumed, so Emburse stays firmly human-in-the-loop on code review. The bottleneck has moved downstream in the meantime. Pre-merge flow is fast enough that deploy time is now the longest stage left, and Ken plans to consolidate the CI/CD tooling behind it.

The second priority is putting AI cost and efficiency data in the engineers' own hands. Emburse never pushed tokenmaxing, and after a long period of driving adoption it has been pushing steadily on efficiency instead.

Engineers ask for the data to keep doing that themselves: "Our engineers are very open to it. They say, tell me how I can become more efficient."

Emburse did not hand its judgment over to a dashboard.

See how LinearB can help your engineering team today.
Book a demo