#LT018 Trunk-Based Development: It's Not Just a Git Strategy
Mindset Change, Non-Blocking Code Reviews and Batch Sizes
Today’s post is a closer look at Modern Software Engineering’s “We Tried Trunk-Based Development… The Results Were Shocking.” Shocking, in this case, in a good way. My main takeaways…
Trunk-Based Development requires mindset change, not just Git strategy
Small batches reduce risk; big batches increase it
Non-blocking code reviews fail without shared purpose
First, a quick reset on what Trunk-Based Development actually is.
It’s a source control model where developers collaborate on a single main branch, often called the trunk. The discipline is not about never branching at all, but about resisting long-lived branches by using well-known techniques. Done well, teams avoid painful merges and keep the system deployable most of the time.
1. Mindset Change
Trunk-Based Development only works if you change how you design and deliver software. Fast commits to main force smaller batches of work. Feature toggles stop being optional. Incremental design becomes the default. Feedback has to be fast, and observability has to be good enough to catch mistakes early.
The case study in the video makes this clear. The technical setup mattered, but the real shift was mental.
2. Non-Blocking Code Reviews
One part of the experiment struggled: non-blocking code reviews. The feedback from the team was blunt.
“…there were several problems. The main one was that people didn’t prioritize reviews enough. Non-blocking was interpreted to mean non-urgent. So, reviews were not conducted close to the time when the work was done. So, feedback became stale.”
“The team saw no shared purpose for the code reviews. This is important. People didn’t know what the code reviews were meant to be for.” (source)
No amount of CI, automation, or branching discipline would have fixed that. If people don’t agree on why reviews exist, removing the gate just exposes the gap faster.
That’s the part of Trunk-Based Development that gets glossed over. The mechanics are well documented. The behaviour change is not.
3. Big To Small Batches
A common pushback for Trunk Based Development is that it’s risky. Actually the reverse is true. Making features bigger, extending branches just increases risks. It puts more pressure on the releases.
If you treat Trunk-Based Development just as a Git strategy, you’re missing the point. There are massive benefits available but they require developers to think and organise their work differently.
Have a great week.
Really good articulation of the behavioral shift. The batch size point is the one teams underestimate most. I've seen orgs try trunk-based with massive PRs that sit for days and they wonder why it doesnt work. The non-blocking review problem you highlighted is real, when reviews become non-urgent they lose their signal value entirely and just become compliance theater. What helped us was making review latency a tracked metric alongside deploy frequency, once people saw that stale reviews correlated with longer cycle times the priority shifted naturaly. The mindset change is definitly harder than the Git config.