The Conductor and the Dancers

Every engineering team I’ve managed eventually hits the same wall: growth breaks everything. More developers means more merge conflicts, more dependencies, more chaos. So we add more process, more gates, more rules. We hire release managers. We buy expensive (and sometimes useful) tools. But what if we’re solving the wrong problem entirely?

A few months ago, watching traffic in Bangalore changed how I think about scaling teams.

The Colossal Traffic Jam

I had the privilege of attending a friend’s wedding in India. A once in a lifetime experience, and a pretty big deal that came with tons of stereotypical advice:

• Don’t drink the water (turned out fine)
• Don’t eat from this huge list of forbidden foods (I ate everything; it was awesome)
• Get a SIM card, or don’t get a SIM card (still confused on this one)
• Traffic is insane and like nothing you’ve ever seen

That last one stuck with me. Shortly after arrival, we found ourselves in full-blown Bangalore traffic.

With nothing but time, I started observing more closely and noticed something remarkable.

The Dance Nobody Choreographed

Yes, there was explosive population growth straining the traffic infrastructure. But fascinating behaviors emerged:

• The honking wasn’t angry. It was communication. Unlike in the US where honking means “move, $%^*! idiot!”, here it meant “hey, I’m behind you, just letting you know.” Pure coordination signal.
• Traffic never completely stopped, it just flowed different than you’d expect. Every inch of road filled as volume increased. When congestion hit, drivers created “new roads” (dirt paths, sidewalks, whatever worked).
• Everyone seemed aware of everyone else. Like partners dancing a waltz they’d never rehearsed.

No one was in control. The few traffic lights I saw were treated as suggestions. Complex intersections worked smoothly as drivers danced around each other. It all just worked.

This is the opposite of US traffic, where we follow laws religiously. Even hardened criminals stop for red lights. We don’t trust other drivers; we trust the system. We follow an invisible conductor.

When I asked our drivers about this behavior, most said: “This is just what we do, I don’t really think about it.” No one seemed to know why the system evolved this way, but I suspect it’s an inevitable response to rapid growth that outpaced infrastructure.

The Engineering Parallel

I started seeing parallels everywhere in software teams.

As engineering teams grow, we get “traffic problems”:

• Merge conflicts blocking releases
• Dependency hell slowing deploys
• Developers “forgetting their SQL scripts” or botching feature flags
• Code review bottlenecks
• Endless and painful planning meetings

The default management response? More rules, more process, more gates. Hire a release manager. Buy better tools. Add more checkpoints.

But this creates cognitive overhead that seems to suck the joy out of work. Sound familiar?

Two Models of Scale

The Conductor Model (what most teams default to):

• Centralized control and coordination
• Detailed processes for every scenario
• Rules prevent problems before they happen
• Success depends on following the system perfectly
• Breaks down when the conductor becomes the bottleneck

The Dancers Model (what I saw in Bangalore):

• Distributed coordination through communication
• Principles over processes
• Rapid adaptation when problems arise
• Success depends on awareness and trust
• Scales naturally with the size of the group

What Dancing Looks Like in Practice

Instead of rigid merge windows, teams coordinate continuously:

• “Hey, I’m about to merge something big to xyz services”
• Slack/Teams channels for deployment coordination
• Quick sync-ups when conflicts emerge. Sync-ups that materialize WITHOUT management intervention.
• Deliberate self-awareness of our engineering teams. Everyone must be aware they are dancing. And those that are not dancing are causing degradation.

Instead of process gatekeepers, everyone owns the flow:

• Developers responsible for their code from commit to production
• Shared ownership of CI/CD pipelines and monitoring
• Teams that break it, fix it. Or if it’s broken, and no one knows who breaks it, everyone stops dancing until it’s fixed.

The Trust Problem

“But what about compliance? Quality gates?”

Good questions. The key insight: dancers need more skill, not less accountability.

Bangalore drivers are incredibly skilled because they HAVE to be. The system only works because everyone takes responsibility for their piece of the dance.

Same with engineering teams. Dancing requires better technical skills, because you can’t coordinate if you don’t understand the impact of your changes. It requires stronger communication, but not the endless spewing of emails nobody reads; think about how you honk! And it requires a mentality of shared ownership of your product (e.g. your story isn’t done when some agile tool says it’s closed, it’s done when it’s in a satisfied, paying customers hands).

The accountability is higher, not lower. But it’s distributed accountability, not centralized control.

Making the Transition

You can’t flip a switch from conductor to dancers. Here’s how to start:

1. Start with communication protocols

• Establish your team’s “honking”.. what, when, and how to coordinate. Determine what is noise and what is signal. Kill the noise, and pay attention to the signal.
• Create lightweight channels for awareness without overhead

2. Eliminate one process gate per quarter

• Pick your most painful bottleneck
• Replace it with a communication practice
• Measure what happens (probably nothing bad)

3. Push decisions closer to the work

• Let the people doing the work make more choices
• Provide principles and context, not prescriptive rules
• Accept that some decisions will be suboptimal (same as with process). These are opportunities to learn.

4. Build skills before removing scaffolding

• Teach people to see the bigger picture
• Create psychological safety for coordination failures

When You Know It’s Working

You’ll see the same signs I saw in Bangalore traffic:

• Problems get solved quickly by the people closest to them
• Communication increases but feels less formal
• Bottlenecks shift and adapt rather than backing up the whole system
• People take ownership beyond their immediate responsibilities
• The system flows even when growing rapidly

The Choice

Every scaling challenge forces a choice: do you trust systems or do you trust people?

Conductors trust systems. Dancers trust people.

Both can work, but only one scales gracefully with rapid growth. And only one preserves the joy that makes great engineers want to stick around.

Maybe it’s time to put down the conductors baton and join the dance.

---

What does coordination look like in your engineering team? Are you conducting or dancing? I’d love to hear your experiences in the comments.