Trunk based development: A Teams experiment

🚧 Challenging the Pull Request Habit: Our Team’s Trunk-Based Development Experiment

Coming from a background rooted in open source, RFCs, and collaborative workflows, our company has a strong culture of development through pull requests. PRs are central to how we collaborate, review, and deliver software.

But recently, I’ve been reflecting on whether this approach still serves us best—especially as a small, high-performing team.

There’s been a growing body of research, especially from Google’s State of DevOps (DORA) and the book Accelerate by Nicole Forsgren, Jez Humble, and Gene Kim, that highlights an interesting trend:

Teams that practice Trunk-Based Development (TBD)—merging small, frequent commits directly to the mainline—consistently outperform in both speed and stability.

This sparked a question for me: What if we tried something different?

🤔 Why Experiment with Trunk-Based Development?

Let me be clear: this isn’t a rejection of PRs. Pull requests are essential in many contexts—especially when introducing potentially breaking changes, managing infrastructure as code, or contributing to open source, or other controlled environments.

They’re valuable tools, and we’re not throwing them away.

But in our case—a tight-knit team of three developers—we’ve noticed some subtle but persistent friction:

• PR’s are often merged within a few hours, but they still introduce context switches and unnecessary overhead.
• Review comments tend to focus on minor improvements—naming, formatting, etc. Which could often be addressed later or handled differently.
• We rarely catch logical flaws with the code during reviews
• We still release bugs (albeit minor) into production despite our best efforts
• Each PR brings with it process weight: writing the description, tagging tasks, running manual tests, waiting for reviews, and so on.

Individually, these frictions aren’t catastrophic. But together, they slow us down just enough to matter.

So, what if we could maintain quality, increase flow, and reduce friction—all while keeping our high trust and collaboration intact?

My stomach feeling is that when developing new features, you can code 80-90% by isolating specific feature, and only the last percentage is integrating with existing code and services.

🧪 The Experiment: A Shift to Trunk-Based Development

We’re running a TBD experiment over a few sprints. It’s structured, intentional, and driven by data. Our goals are to improve lead time, reduce cognitive load, and boost developer satisfaction.

✅ What We’re Testing

1. Refined Process

• Share a developer brief to introduce the experiment and invite team reflection.
• Establish team agreements on how we’ll operate.
• Pull requests are still being used—but used selectively, especially when code requires manual testing or broader review, or integration.
• Tagging of commits with task IDs for traceability, and to support non-blocking reviews.

2. Lean Into CI/CD

• Automated testing is mandatory for all new code—preferably unit tests, but anything that makes sense contextually and is automated
• Any commit that passes CI is eligible for deployment.
• Emphasise tiny, frequent commits and early integration.

3. Non-Blocking Reviews

• Reviews are asynchronous and post-merge where appropriate.
• Feedback is delivered directly to authors, especially for more significant changes.
• Minor improvements can be committed directly to main by reviewer.
• The focus shifts from gatekeeping to enabling flow and improvement.
• Boyscout commits, such as removing unused namespaces, updating variable names or whatever leaves the campsite cleaner does not need to be part of the review process.

4. Weekly Team Check-ins

Each week we ask:

• What friction points have emerged?
• Are we moving faster—or slower?
• Have we introduced or reduced bugs?
• Can we replace manual steps with automation?
• How do we feel about the process overall?

📈 Metrics We’re Tracking

• Lead time from commit to production
• Deployment frequency
• Rate of bugs or rollbacks
• Team sentiment and confidence in the process

This isn’t a leap of faith—it’s a measured experiment. We’re testing, learning, and adapting.

🌱 The Feeling of Growth

Pull requests have become more than a workflow—they’re a symbol of caution, structure, and trust. In large or distributed teams, they play an essential role.

But in small, high-trust environments, those same rituals can become bottlenecks. And the truth is: what worked five years ago might not be the right fit for who we are now.

This is a moment to reflect, evolve, and improve.

🧭 In Closing

I don’t know yet if Trunk-Based Development will be the silver bullet for us. (Is anything really?)

But I do know this: it’s worth exploring.

We’re not abandoning quality—we’re doubling down on trust, tooling, and transparency.

If you’re in a small team and feel the drag of over-engineered process, maybe it’s time to ask: What are we optimising for?

For me its all about running the experiement, gather the data and the feedback, and if it does not work, the worst thing that happens is that we go back to the “old” ways of working.

Let’s see what happens. I promise to do a followup