Why pair programming almost certainly will make your team ship faster

On the surface, pair programming looks very wasteful. After all, the task was being done by one engineer, and now you want to put two on it.

But this measures the wrong thing. It focuses on engineers per task rather than how long the task takes.

My purpose in this article is to convince you why pair programming will almost certainly make your team faster

My first encounter with pair programming

One of the first things I learned about Gojek's engineering culture was that they strongly believed in pair programming. My first pairing session was with the GoPay liquidity team, with an engineer I'd just met. We picked up a small update from the board. Read it together, launched the editor, set up the repo, and paired through the changes. Wrote the tests. Added a feature flag. Got it green. We liked it.

I asked, "what's next?"

"Next, we commit and merge."

That was the first shock. Everyone just merged to main. No PR queue. No reviewer to wait on. The pair was the review.

"Then what?"

"Then we push, and watch New Relic for about thirty minutes. If something breaks, we kill the feature with the flag. If it's serious, we roll back."

I couldn't believe it. We'd pulled a story off the board, and an hour later it was running in production for millions of users.

This level of velocity worked out wonderfully for Gojek. They grew into one of Southeast Asia's largest tech companies, reaching decacorn valuation over $10 billion before merging with Tokopedia in 2021.

But Gojek is one company, with years and resources to get this right. Could the same level of velocity be replicated by a brand new team? Later in my career, I got the chance to find out

Trying it at Welysn

Years after I left Gojek, after we'd all survived COVID, I joined Welysn, an Australian telehealth startup. The platform was legacy, we deployed once a month and my first job was helping with the migration off it.

Later, we were about to start a new product. That window felt like the right time to try something different. So I made my pitch.

The team was remote, so we got on a call and I was explicit: for this new product, we'd run things differently. Pair programming would be a core ritual. I shared what I'd seen at Gojek and what I thought we could get from it.

Here are the key decisions we made:

• Continuous deployment. We moved off the monthly cadence entirely. Pair programming on a monthly deploy cycle is just two engineers writing code that won't ship for weeks. The feedback loop is the practice — without continuous deployment, you don't have one.

• Three pair sessions a day. 1.5h after standup, then 1h, then 1.5h. We'd join a single call to sync, then split into breakout rooms. Pairs rotated. The rest of the day was solo.

• One shared language across the team (DDD). Design called things one name, product another, engineering a third. Ask three people about a feature, get three slightly different answers. We adopted the domain-driven design principle of a ubiquitous language, same word, same concept, across design, product, and engineering.

• End-of-sprint retros. at the end of the sprint, the team would name what to keep, what to change, what to drop. None of the above was set in stone. The team would refine it as we went.

To say there was doubt in the air would be an understatement. And if I'm honest, at the time, even I wasn't sure it would work. I'd been on teams that did pair programming. I'd never been the one introducing it.

Nonetheless, the team committed anyway. And it worked!

What happened

The benefits I pitched landed roughly as expected. Velocity climbed. Knowledge spread, every part of the code had at least two people who knew it. Decisions got made faster.

However, two things I didn't see coming.

The first was how much morale improved. In retrospect, that made perfect sense. We were spending way more face time together. On a remote team, your default contact with a teammate is a Slack message when something's broken or someone needs something. Pair programming changed that.

The other thing was how much velocity would actually increase. I thought it would go up. I didn't expect it to keep going up, sprint after sprint, consistently, to the point where the product manager, the designer, and I were struggling to write well-defined stories fast enough to add to the sprint.

It was a welcome problem to have. And deal with it we did.

Parallelizing discovery (the trio system)

We started seeing it in retros, a few sprints in. We weren't writing stories fast enough. Sprint planning would get to the bottom of the backlog with the team still on the call.

The bottleneck wasn't engineering anymore. It had moved upstream to the place where vague problems get turned into well-defined stories.

The way we addressed it borrowed from a concept I'd later see named the "product trio" — popularized by Teresa Torres in Continuous Discovery Habits. Our version was more delivery-focused than hers, but the spirit was the same: the people who shape a feature should be the same people who deliver it.

Here's how it worked.

The project manager held a rough roadmap, the problems we wanted to solve, the outcomes we wanted to hit. From that, they'd identify a chunk big enough to be its own initiative or epic. At that point, a trio formed around it: a PM, a designer, and an engineer. The trio took the vague problem-and-impact statement and figured out the how, solution shape, design direction, technical approach. Sometimes that meant customer interviews. Sometimes not.

The engineer in the trio was the one I'd call the engineering champion. They weren't just there to advise on technical feasibility. They did the feature breakdown, wrote the stories, and pitched the architecture back to the engineering team. Once the stories hit the board, any pair could pick them up. But the champion stayed accountable for that feature, the one person holding the whole picture, from problem statement through shipped code.

That's the line in the diagram. Above it, the trio. Below it, the pairs. The engineering champion crosses the line, they're a member of the trio when the feature is being shaped, and they're a member of a pair when the stories get picked up. Same person, different altitude.

Pair programming had parallelized execution. The trio system parallelized everything upstream of execution. Same belief underneath both: complex work goes faster when the people doing it think together.

Velocity as the north star

Looking back, almost every decision I made on this team was in service of one thing: protecting velocity.

Pair programming. Continuous deployment. Vercel instead of self-hosted infrastructure, so engineers' time stayed on domain code instead of plumbing. The trio. A shared language across product, design, and engineering. Each one was a velocity decision in different clothing.

Velocity isn't the agile chart. You can feel it in your bones. How fast the company actually moves. How fast you respond to what users tell you. How long an idea sits between someone having it and someone shipping it. The chart is the shadow of that.

It isn't the only thing a company needs to succeed. DORA's research covers what else matters. But velocity is one of the most important things, and one of the most under-invested in.

None of this worked because of a principle, though. It worked because the team committed. I held the lens. They made it real and for them I'm immensely grateful.

The skeptic at the top of this article looked at two engineers at one screen and saw waste. They were counting engineers per task. The thing worth counting is how fast a task ships, and the next one, and the one after that.

That's velocity. And once you've worked at this pace, you can't go back.