TL;DR: Yes, we ship code fast - at a pace that’s unusual even by top-tier engineering standards. But more importantly, we do it by embracing a workflow that minimizes the waiting game, encourages thoughtful iteration, and makes the most of our tools.

Why discussing speed is tricky

Engineering productivity is a sensitive topic. On the surface, it sounds simple - ship more code, faster. In reality, it’s not that straightforward. Different products and teams have vastly different requirements, from complex regulatory hurdles to intricate performance constraints. Metrics like lines of code or hours in the office rarely capture the true nuance. Every experienced engineer knows that “butts in seats” or “hours worked” is a poor proxy for real productivity. Quality matters. Thoughtfulness matters. Maintenance and reliability matter. And yet, we keep coming back to the same question: “Is your engineering team fast?”

At Graphite, I get asked this question a lot - by investors, customers, potential hires, and even peers at other companies. Some form of the question inevitably pops up: “Are you pushing the team hard enough?” or “I’ve heard of companies that pull all-nighters - are you doing that?” Sometimes, it’s simply: “You build productivity tools, so you must be insanely productive yourselves, right?”

These questions don’t come from a bad place. They come from curiosity and the desire to understand what “fast” looks like. They also come from a world where, historically, productivity has been measured in the wrong ways. That said, if you’re on the outside looking in, it can be perplexing. Our team is well-compensated, well-supported, and trusted to work their own hours - yet we don’t subscribe to the “always on” hustle, nor do we push for grinding 20-hour days. How, then, do we show that we are indeed moving at an exceptional pace?

Measuring code change velocity

If there’s one thing Graphite knows, it’s how to measure the flow of code. After all, one of our core offerings is built around managing and tracking pull requests.

So, I’ve decided to let the data speak for itself. Below are some metrics collected over a recent quarter (Q4 2024) for our 9-person engineering team. I compared them against industry-wide benchmarks (based on aggregate data from GitHub repositories of all shapes and sizes):

• Number of pull requests per engineer per quarter (median):

  • Industry median: 33 PRs per engineer

  • Graphite median: 324 PRs per engineer

• Number of pull requests per engineer per quarter (P90):

  • Industry P90: 114 PRs per engineer

  • Graphite: 489 PRs per engineer

• Median lines changed per PR:

  • Industry median: 36 lines

  • Graphite median: 34 lines

• Median time to merge (from PR open to merge):

  • Industry median: 2.7 hours

  • Graphite median: 5.7 hours

The takeaway? Graphite’s engineering team is in the 99th percentile and beyond when it comes to throughput measured by merged PRs. Our changes aren’t abnormally small, and our time-to-merge is actually a bit slower than average. Yet, we produce far more merged PRs per engineer than typical teams.

At first blush, that might seem contradictory. If we merge more slowly, how are we shipping more code? The key lies in how we structure our work.

The secret sauce: stacked PRs and parallelized work

A defining principle of our development process is the use of stacked PRs, a core concept we champion. Traditionally, waiting for a PR to merge before moving on to the next related change can act as a bottleneck. By stacking PRs, we break down large changes into a series of smaller, reviewable increments. Each increment can be developed, reviewed, and tested concurrently. Instead of waiting idly for one PR to merge, engineers can continue building the next layer of functionality.

This approach naturally leads to a higher total count of PRs - each one is smaller and more focused. It also means that a single PR might wait in the queue a bit longer (hence the slightly increased median time-to-merge), but the overall flow of code doesn’t stall. Engineers are never blocked; they always have another PR to work on. As a result, the entire chain of features moves forward in parallel, and a steady, healthy drumbeat of merged PRs follows.

This method directly reflects the philosophy behind Graphite’s tooling. Our product encourages an iterative, parallelized workflow that maximizes efficiency without sacrificing code quality. We eat our own dog food, and it’s working.

Perspective and caution

Now, none of this is to say that shipping a large number of PRs is the only metric that matters. Teams vary widely in their domains, skill sets, and constraints. Some products need more rigor and longer review cycles due to the criticality of their software - think medical devices or financial platforms. Others might have less internal tooling or different cultural norms around code review. Simply aiming to be “faster” without understanding your product’s unique context can lead to burnout or dropped quality standards.

I share these metrics and our workflow not to brag, but to inspire. If you’re a leader frequently asked about your team’s productivity, let these numbers serve as one data point. If you’re an IC engineer who knows how nuanced productivity truly is, consider this a case study of how process and tooling can unlock surprising speed. And if you’re evaluating Graphite itself - either as a prospective employee, customer, or curious observer - know that we’re not only building productivity tools, we’re proving they work.

It’s fair to be skeptical of any claims about “incredible speed” in engineering teams. The industry has a long history of measuring the wrong things and glorifying overwork. I hope to show a different story: a small team shipping at a remarkable pace, not because we’re pulling constant all-nighters, but because we’re leveraging parallel workflows, trusting each other, and using our own tools to minimize friction.

Is Graphite’s engineering team fast? The data suggests we are, by a wide margin. More importantly, we’ve found a model that consistently lets us iterate quickly, maintain quality, and stay sane. I believe others can learn from this, adapt it to their own contexts, and ultimately deliver value to their users at a pace that might just surprise them.