How MongoDB Cut PR Size by ~50% and Improved PR Cycle Time with Optimal AI

Every engineering manager wants to build their own analytics tool. It feels like you’re saving money, but you end up with a fragile system that requires constant maintenance.

This was the reality for MongoDB’s Internal Tools team. They were scaling, but their visibility into engineering health was held together by duct tape.

“It was never as good as we wanted it to be,” says Lila Brooks, Engineering Manager, Internal Tools. “We had to run it manually and modify the data. It wasn’t easy to use.”

The Problem

Their "free" solution was actually expensive. Engineers were wasting valuable time fixing broken data scripts instead of writing code. Because the data was so hard to pull together, nobody trusted the numbers.

They were flying blind; they couldn't see how much time went into tech debt versus new features, and they didn't know why their code reviews were taking so long.

The Solution

A single source of truth with Investments, Jira integration, and smooth UX

MongoDB killed the scripts and deployed Optimal AI.

This gave them an automatic, real-time view of their Jira and GitHub data.

The new system showed them exactly where their time was going. It highlighted one massive problem immediately: Their Pull Requests (PRs) were too big. Because the PRs were giant, nobody wanted to review them, causing code to get stuck.

Optimal AI broke down effort into hard categories: Technical Debt, Bug Fixes, Discovery, and Feature Work.

“Investments shows where the team’s effort is spent. Seeing tech debt, bug fixes, discovery, and features by sprint or quarter helps us focus.”

This allowed them to visualize the correlation between PR size and review time. They stopped "monitoring" the problem and started fixing the root cause: giant PRs that nobody wanted to review.

The Results

PRs ~50% smaller, faster cycle time, and organization-wide adoption

Once the team saw the data, they fixed the behavior. They started breaking their work into smaller chunks.

The impact was clear. They cut their average PR size by 50%. Because the chunks of code were smaller, reviews became much faster, improving their overall speed by 30%.

Unlike the old scripts, everyone from engineers to Directors actually uses this system now because they trust the data.

• PR Size Cut by ~50%
• Cycle Time Dropped by ~30%
• Adoption from the Bottom Up: The new system’s smooth UX meant adoption actually happened from the IC level up to Directors.

“We were able to get the size of our PRs much smaller, nearly 50% and improve our PR cycle time by understanding why reviews were taking time.”

You can keep running your home-grown scripts. It feels free. But the cost isn't on the invoice; it's in the lost hours your team spends waiting for code reviews on PRs that are too big to merge.

Scaling faster with Developer Experience at the center

You can keep running your home-grown scripts. It feels free.

But the cost isn't on the invoice; it's in the lost hours your team spends waiting for code reviews on PRs that are too big to merge.

“I highly recommend teams invest in developer experience. Measure the right KPIs and show them to the team. That’s what improves productivity and experience.”