The CTO's Branch Nightmare
Why Your 120-Person Engineering Team Spends 40% of Its Time Managing Branches Instead of Shipping Code
I'm on a zoom call with Marcus, a CTO whose company just crossed 120 engineers. He's sharing his screen, showing me a diagram that looks like a subway map designed by someone having a fever dream. Red lines, blue lines, green lines—each representing a different feature branch in their codebase.
"We call this the Branch Board," he says, his voice flat. "My VP of Engineering updates it every morning. These 47 lines? They're just the active branches from the last month."
I watch him trace a particularly twisted path with his cursor. "This feature here? It's been done for 19 days. Can't ship it because it depends on a refactor that conflicts with a hotfix that breaks three other features that are also done but can't ship."
His Slack notifications are going off constantly. I can see the preview of one: "Integration party this Thursday. All hands. Please clear your calendars."
"How often do you do these integration parties?" I ask, though I already know the answer.
"Every. Single. Week." He minimizes the diagram and turns on his camera. He looks exhausted. "Etienne, we have 120 of the smartest engineers I've ever worked with. Right now, 30 of them are blocked. Not because they can't code, but because their branches are stuck in what we call 'merge purgatory.'"
His phone rings. He shows me the screen. It's his CEO. "I need to take this," he says, then puts it on speaker anyway.
"Marcus, the enterprise feature we promised three weeks ago, where is it?"
Marcus pulls up Jira. The ticket is marked done. Has been for weeks. "It's in QA integration," he says.
"What does that even mean?" the CEO asks.
After the CEO hangs up, Marcus slumps back. "We're not a technology company anymore. We're a branch management company that occasionally ships software by accident."
That's when I know exactly how to help him.
Your feature branches aren't protecting you from chaos. They're creating it. Trunk-based development isn't about being reckless but being so disciplined that branches become unnecessary.
After Marcus showed me his branch board, we did some brutal math together. His 120-person engineering team was spending 40% of its time on integration-related work. I pulled out my calculator right there on the call.
"Marcus, at an average fully-loaded cost of $200,000 per engineer, you're burning $9.6 million annually. Not on features. Not on innovation. On merge conflicts."
He went quiet. Then: "That's...that's 48 engineers’ worth of salary."
Every CTO I work with has this moment of realization. They're so deep in the daily crisis of integration that they can't see the massive cost until someone adds it up for them.
Existential Threat
I've coached dozens of CTOs through this transition, and there's a clear inflection point. When teams hit 100+ engineers, feature branches go from being a minor annoyance to an existential threat.
"Marcus," I told him, "Google has 35,000 engineers committing to a single trunk. Facebook, Netflix, same story. You think they have less complex requirements than you?"
He laughed bitterly. "Our board would freak if we proposed committing directly to main."
"Your board is already freaking about your velocity. Would they rather have the illusion of safety or actual delivery?"
I showed him data from three other clients who'd made the switch:
FinTech client (150 engineers): Deployment frequency up 10x
Healthcare SaaS (90 engineers): Lead time down from 3 weeks to 6 hours
E-commerce platform (200 engineers): Integration costs down 75%
I've watched three companies hit what I call "integration gridlock" in the last two years. They literally cannot ship anything significant because the cost of integration exceeds the value of the feature.
"Marcus, your best engineers, where will they be in six months if nothing changes?"
He knew the answer. Three senior engineers had already left, citing "too much process overhead" in their exit interviews. What they meant was: "I spend more time merging than coding."
The Path From Chaos to Continuous
Marcus was skeptical but desperate. We agreed to start with a pilot program—one team, eight engineers, working on their payment system.
"Give me four weeks with them," I said. "If it doesn't work, you go back to branches."
Week 1: The Foundation
I flew out to work with Marcus and his payment team in person. First day, I drew a simple diagram on their whiteboard:
Feature Branches: Code → Wait → Integrate → Test → Wait → Deploy (3 weeks) Trunk-Based: Code → Deploy (4 hours)
"That's fantasy," said Tom, their principal engineer.
"It's Tuesday," I replied. "By Friday, you'll be deploying to production hourly."
We started with the essentials:
Feature flags became law. Marcus had budget for LaunchDarkly, which was perfect. Every single change went behind a flag:
if (flags.isEnabled('new-payment-validation', user)) {
return validatePaymentV2(order);
}
return validatePaymentLegacy(order);
Tests had to run fast. We spent two days just optimizing their test suite. Parallelized everything, deleted flaky tests, made failures loud and clear. Got it from 45 minutes to 8 minutes.
Pair programming replaced pull requests. This was the hardest sell. I literally sat between two developers and showed them how to pair effectively. "Real-time code review," I kept saying. "No waiting for PR comments."
Week 2: The Discipline
I gave them three non-negotiable rules:
The 24-Hour Rule: No code lives outside main for more than 24 hours
The Always Green Rule: A broken build stops everything until fixed
The Small Batch Rule: Every commit is deployable and incremental
The resistance was immediate. "I can't finish this feature in a day!" one engineer complained.
I sat with her at her desk. "Show me the feature."
She pulled up a massive refactor. Probably three weeks of work in the old world. Together, we broke it into 15 tiny pieces. Each piece was valuable, testable, and could hide behind a flag.
"But this feels like more work," she said.
"Today it does. Next week it won't. Trust me."
The Shift That Changed Everything
Day 8, I get a Slack from Marcus: "Come to the team room. Now."
I thought something had blown up. Instead, I found the payment team celebrating. They'd just deployed their 50th change of the week. More importantly, they'd shipped three features that had been "90% done" for months.
Tom pulled me aside. "I haven't resolved a merge conflict in eight days. Is this what work is supposed to feel like?"
Marcus was watching his deployment dashboard like it was the World Cup. "They're deploying every hour. How is nothing breaking?"
"Smaller changes, smaller blast radius," I explained. "Plus, feature flags mean instant rollback."
The Success Metrics That Convinced Everyone
After one month, I presented the payment team's metrics to Marcus's entire engineering leadership:
Deployment frequency: From 2 per week to 30 per day
Lead time: From 3 weeks to 4 hours
Merge conflicts: Zero (can't have merge conflicts without merges)
Production incidents: Down 60%
Team happiness score: Up 40%
But the metric that sealed it? The payment team had started taking work from other teams because they had so much free time.
Scaling to the Entire Organization
Marcus was sold, but he was nervous. "Eight engineers is one thing. How do we do this with 120?"
I'd been through this transformation enough times to know the answer.
The Gradual Migration
"We use viral adoption," I told Marcus. "Success sells itself."
The roadmap I designed for him:
Month 1: Payment team proves the model (8 engineers)
Month 2: Two adjacent teams join (24 engineers total)
Month 3: Four more teams convert (56 engineers total)
Month 4: Remaining teams demand to switch (120 engineers total)
Each converted team became evangelists. They'd show their metrics at all-hands meetings. Other teams would see them shipping daily while everyone else was stuck in integration parties.
The Technical Requirements at Scale
I worked with Marcus's infrastructure team to ensure they could handle 120 engineers committing to main:
Build infrastructure that scales:
Invested in better CI/CD servers (budget: $50K)
Parallelized tests across 20 machines
Build time stayed under 15 minutes even at full scale
Monitoring that catches issues immediately:
Set up Sentry for real-time error tracking
LaunchDarkly dashboard on every TV in the office
Automated rollback on error threshold
Cultural shifts that stick:
Paired every skeptic with a trunk-based development convert
Made "deployments per day" the celebrated metric
Banned the phrase "waiting for integration"
The Resistance and How to Handle It
Every transformation has its skeptics. I coached Marcus through each objection:
"But we need code review!" Marcus's architecture team was the loudest here. I paired with their lead architect for a full day. After experiencing real-time code review through pairing, he became our biggest advocate.
"This will break production!" I showed them data from all my previous clients. Smaller, flagged changes break less than big branch merges. The head of QA was convinced after seeing incidents drop 60% in the payment team.
"Our compliance requires separation of duties!" This came from their security officer. I walked him through how trunk-based development actually provides better audit trails—every change is small, attributable, and immediately visible.
Now What?
Your First Step (This Week)
If you're a CTO with 100+ engineers still using feature branches, here's exactly what to do:
Pick your most frustrated team. Not your best team—your most frustrated. They're motivated to change. Give them:
Budget for a real feature flag system ($20-50K/year)
Permission to pair program instead of pull request
A clear goal: deploy to production daily
Optional: Bring in external help (someone who's done this before)
Measure everything for one month.
Your Three-Month Roadmap
Month 1: Pilot team proves it works. Expect 5-10x deployment frequency improvement.
Month 2: Add 2-3 more teams. They'll adopt faster seeing the pilot's success.
Month 3: Hit critical mass. When 40% of engineers are trunk-based, the rest will demand to switch.
What to Expect
I always warn my clients: Week one will feel like chaos. Engineers will break builds. Tests will fail. People will want to quit and go back to branches.
By week two, the rhythm emerges. Commits get smaller. Tests get better. Deploys become boring (in the best way).
By month's end, they can't imagine going back to feature branches.
The Feeling of Success
Marcus called me six months after our engagement ended.
"Etienne, I just realized something. I haven't heard the word 'merge conflict' in two months. My engineers don't talk about git anymore. They just... build things."
His deployment frequency graph was on his desktop background—a beautiful exponential curve that started the day they killed feature branches.
"My CEO asked me yesterday why we're shipping so fast now. I told her we stopped trying to be safe and started being disciplined instead."
The Hard Truth
Marcus burned $9.6 million annually on feature branch chaos with his 120-person team. After six months of trunk-based development, he recovered 35% of his engineering capacity. Not through hiring. Not through working harder. Just by stopping the insanity of managing divergent branches.
I've guided seventeen CTOs through this exact transformation. Every single one had the same objections initially:
"We're too regulated"
"Our system is too complex"
"Our engineers aren't disciplined enough"
Every single one now deploys to production multiple times per day.
Your 120-person engineering team isn't special. Your requirements aren't unique. Your concerns about trunk-based development are the same concerns Marcus had, that every CTO has.
The only difference between you and companies deploying continuously? They stopped talking about change and started doing it.
Start with one team. This week. Give them flags, require pairing, ban branches. Measure everything for 30 days.
When you see the results, you'll do what Marcus did. You'll accelerate the rollout because you can't afford not to.
That branch board Marcus showed me on our first call? It's still on their wall. But now it shows something different: a single thick green line labeled "main" with a number next to it—"2,847 deployments this month."
Underneath, Marcus wrote: "Never again."