The Trunk is the Team

An orchestra can rehearse in separate rooms. Each section sounds fine to itself. Strings keep time, brass hit their notes. But the first time they come together the rhythms do not match. What was music alone becomes noise together. The only way to avoid it is to rehearse in the same hall, again and again.

That is how many large repositories behave. Project teams work on their own develop branches, merging later into a release branch where all products finally meet. The release is then merged back into main. In theory it works. In practice the first real rehearsal is late in the cycle and that is when problems appear.

Trunk-based development removes the intermediate steps. The release is cut from main. Everyone plays in the same hall. Integration does not wait until the end. It happens daily, in the open, where adjustments are easier and the rhythm is shared.

Daylight and discipline

Code in trunk is visible immediately, not hidden for weeks. Junior engineers do not wait to discover their approach will not hold. They learn in days, while the lessons are still manageable. Product teams see progress as it unfolds rather than as a reveal. And players feel value sooner, as a steady rhythm of improvement.

A monorepo helps with visibility and consistency, but it is not enough on its own. You can still have long-lived branches and late merges inside a single repository. Trunk-based development is the practice that makes the monorepo effective, turning shared code into shared progress. Think of it as phase two: once code is together, the challenge is keeping people together.

Merging main into a feature branch helps, but only partly. It shows whether your code works against the past. It cannot show how it behaves against the hundred other branches in flight, each carrying its own version of the future. The trunk collapses those futures into the present.

This only works when the trunk is treated as sacred. Break it and you fix it immediately. That expectation changes behaviour. Developers test more carefully before pushing. Teams lean on flags instead of leaving half-finished work exposed. It takes a cultural shift, and it is not perfect at first. Over time people adapt to the rhythm.

The approach comes with costs. Smaller and more frequent commits take practice. Feature flags accumulate debt and need discipline to clear. Tests must be fast and trusted or progress slows. These drawbacks are visible and manageable. The alternative is drift hidden in dozens of branches, which is harder to correct and more costly in the long run.

With five hundred engineers, visibility compounds. Not because everyone becomes a tester but because seeing each other’s work builds judgment. Junior developers learn faster. Seniors see what their choices unlock or constrain. Thousands of small decisions each week are made in the open, and that openness is what scales the wisdom of the crowd.

Changing the key

In an orchestra, changing key is not just one player shifting a note. The whole section must move together. Strings adjust as one, then brass, then percussion. The score is the same, but the pitch is new.

Large refactors in software feel the same. A design system refresh, an Angular upgrade, a shift in a shared pattern. Hundreds of files move. Every product is affected. It is not enough for one team to play in tune. The section must change together, and the performance cannot stop.

Trunk makes this possible. The new key is introduced in steps. Nx generators apply consistent changes across the repo, keeping signatures and imports aligned. Incremental builds reduce the cost of touching many files at once. One product moves first, while others continue as before. When that product is stable, the path is clear for the rest.

Not every change can hide behind a feature flag. Some differences will surface in the open. That is acceptable. The point is not to insulate the organisation from change but to make it visible early, when it is still possible to adjust.

The performance continues. Developers hear each other adapt and adjust their own parts. By the time the last product moves, the new key already feels natural. The piece carries on, coherent and whole.

Why it matters

Trunk-based development is not only an engineering concern. It shapes how quickly products reach the market, how reliably they perform across brands, and how visible progress is while they are being built.

For leadership, the benefit is clarity and faster learning. Work flows into the hands of players sooner, with fewer surprises at launch. Product direction can be adjusted earlier because progress is visible every day rather than hidden in long branches. Teams learn more quickly what works and what does not, which reduces the cost of mistakes and shortens the path to value.

For players, the benefit is continuity. Value arrives in smaller, steadier increments. The product does not lurch forward and stall, it evolves smoothly. Reliability matters as much as speed, and trunk supports both.

Like an orchestra, trunk-based development is cultural. It takes practice. The first rehearsals are awkward. Mistakes are public. But people adjust to each other’s timing. They listen as well as play. In time the noise settles into rhythm, the rhythm becomes music, and the organisation can move as one.