What is the single-track problem at work?

The single-track problem is when two people or teams need the same shared resource that only one can hold at a time—one codebase area, one production environment, one decision, one customer—and there's no agreed rule for who goes first. Borrowed from single-track railways, where opposing trains share one line, it describes collisions that happen even when everyone is competent and well-intentioned. The cause is a missing protocol, not careless people, which is why it can't be fixed by trying harder.

Isn't the single-track problem just deadlock?

No—they're opposite failures. Deadlock is when both parties stop and wait on each other, freezing the whole line until someone intervenes. The single-track problem is a collision: both parties keep moving and run straight into each other, like a railroad "cornfield meet." Deadlock is paralysis you cure by getting someone to move; a single-track collision is a crash you prevent by deciding, in advance, who stops and takes the siding.

How is the single-track problem different from duplicate work?

Duplicate work is two people unknowingly doing the same task and discovering it later—a visibility gap. The single-track problem is sharper: it happens even when both people can see each other coming, because awareness isn't authority. Knowing a teammate is near the same code doesn't tell you which of you yields. The fix isn't more communication; it's a pre-decided rule for right-of-way on each shared resource.

Does adding more people fix coordination collisions?

Usually not. If the contended resource can be split—a queue two agents could each own half of—adding capacity helps. But most collisions happen on resources that can't be duplicated: one prod, one roadmap, one call. There, hiring makes it worse, because every added person multiplies the coordination pairs (Brooks's law). Most team coordination problems that look like understaffing are really under-dispatching, solved with clear ownership rather than headcount.

How do you reduce merge conflicts on a team?

Treat the codebase like a single-track line and signal the blocks. Make it visible the moment someone starts work on a shared area, keep batches small and integrate often (trunk-based development), and name an owner for hot files so two people don't quietly occupy the same block. The goal is to surface the meet before it becomes a collision—coordination decided upstream, asynchronously, instead of discovered at merge time.

The Single-Track Problem: Why Adding People Won't Help

For most of railroad history, two trains heading toward each other on one line had nothing between them and a head-on crash but a paper schedule and the nerve of two crews. Railroaders had a grimly cheerful name for what happened when the paper was wrong: a cornfield meet—"an accidental head-on collision or near head-on collision of two trains." The name stuck because in the early days such railway accidents were quite common, out in the country where two locomotives met nose to nose with nowhere to go.

You have cornfield meets too. Two of your best engineers push to the same files within an hour of each other; one force-push later, "it will overwrite your coworkers work with yours." Two people quietly build the same internal tool. Two leads give a customer two different answers. Nobody was lazy. Nobody was careless. They just both needed the same stretch of track at the same time, and there was no rule for who went first. Call it the single-track problem: when two parties have to use one shared resource that only one can hold at a time, and the system never decided who yields.

And it's getting more expensive. Atlassian's 2026 research found that even teams who say AI is making them faster are still "losing about six hours a person per week to coordination chaos—unclear goals, duplicated work, shifting priorities." The instinct, when work keeps colliding, is to add capacity—more people, more parallel workstreams, a second lane. Railroads had that instinct too, and mostly chose something cheaper and smarter. This piece is the comparison: lay a second track, or dispatch the one you have. We'll cover what the single-track problem really is, why it isn't deadlock or simple duplicate work, and which of the two fixes actually moves trains.

What the single-track problem actually is

A single-track railway is exactly what it sounds like: a line where "trains traveling in both directions share the same track." It isn't a defect or a budget failure. It's the default for any line "where the level of traffic is not high enough to justify the cost of constructing and maintaining a second track"—which is most lines. The single track is fine. The problem is geometric: two trains, opposite directions, one segment, and as the same article notes dryly, "head-on collisions are a particular risk."

Here is the part almost everyone gets wrong about a cornfield meet. We read a collision as a competence story—someone wasn't paying attention, someone got sloppy, someone should be fired. But on a single track, two crews can each be fully competent, each be following valid orders, each be doing their job exactly right, and still drive straight into each other. The collision isn't caused by the presence of carelessness. It's caused by the absence of a protocol. That distinction is the whole article: the single-track problem is structural, not behavioral, and you cannot train, hire, or motivate your way out of it.

You can watch it happen in plain language. One developer describing shared resource conflicts in version control put it as bluntly as the railroaders: "If two people accidentally worked on the same file, both were screwed." Both. Not the careless one—both. That's the signature of a single-track collision: it punishes two people who each did nothing wrong, because the wrongness lived in the system that let them both onto the track.

Why it isn't deadlock—or duplicate work

It's tempting to file this with two problems it resembles, but it's a distinct, sharper thing, and the difference tells you how to fix it.

It isn't deadlock. Deadlock is when both trains stop—each waiting for the other to move, neither able to, the whole line frozen until someone intervenes. The single-track problem is the opposite failure mode: both trains keep moving, straight at each other. Deadlock is paralysis; a cornfield meet is collision. They feel similar from the outside—work isn't getting through—but they have opposite cures. You break a deadlock by getting someone to move. You prevent a cornfield meet by getting someone to stop.

It also isn't ordinary duplicate work on remote teams, though they're cousins. Duplicate work is two trains that never knew the other existed—you discover months later that another squad shipped the same feature, and the cost is wasted effort you find in hindsight. The single-track problem is worse, because it shows up even when everyone can see each other. Two engineers staring at the same Jira board, both aware the other is near that code, can still collide—because awareness isn't authority. Knowing a train is coming doesn't tell you which of you takes the siding. That's why "just communicate more" so often fails as a fix: the trains in a cornfield meet frequently did communicate. What they lacked was a rule.

Option one: lay a second track

When trains keep meeting head-on, the obvious move is to double-track the line—build a second set of rails so traffic in each direction gets its own. And it genuinely works, on paper. A single-track line that takes fifteen minutes to traverse "would have capacity for only two trains per hour in each direction safely," while "a double track with signal boxes four minutes apart can allow up to 15 trains per hour in each direction." More track, more throughput. So the team version is irresistible: more collisions on the codebase? Hire more engineers. Customers getting crossed wires? Add a second account manager. Too much contention? Add lanes.

The trouble is that double-tracking is the expensive answer, and often an impossible one. Railroads single-track most of their network precisely because a second track rarely pays for itself. On a team, the equivalent bill comes due fast. The most contended resources usually have no second track: there is one production environment, one pricing decision, one customer relationship, one section of the code that everyone's feature happens to touch. You can't parallelize a thing only one party can hold.

And adding people to relieve a collision often adds collisions. This is the lesson of Brooks's law on remote teams: every new person multiplies the number of pairs who have to coordinate, so past a point each extra engineer creates more places for two threads of work to cross, not fewer. More trains on a poorly dispatched line don't mean more throughput—they mean more meets to manage. Most team coordination problems that look like a staffing shortage are actually a dispatching shortage wearing a staffing costume.

Option two: dispatch the track you have

Railroads ran enormous traffic on single track for a century without a second rail, and they did it with three cheap inventions worth stealing.

First, the block. Under absolute block signalling, the line is divided into sections and the rule is mechanical: "only one train to occupy a defined section of track (block) at a time." Software has a name for exactly this discipline—mutual exclusion, "one thread of execution never enters a critical section while a concurrent thread of execution is already accessing said critical section," the problem "first identified and solved by Edsger W. Dijkstra in his seminal 1965 paper." Railroads were enforcing it in steel and signal lamps long before anyone formalized it in code. The point is identical in both: a shared resource that only one party may hold at a time needs a hard rule, not a hopeful one.

Second, the superior train. Authority has to be decided in advance, and railroads were ruthless about it: "a train which had the right of way over another train was said to be the superior train," and "it would be the responsibility of the inferior train to clear the main track a safe time before the superior train is scheduled to pass." Someone has the main; someone takes the siding. There is never ambiguity about which. Clear decision ownership is the management word for the superior train—when two people contend for the same call, one of them, named ahead of time, has right-of-way and the other yields.

Third, the meet, arranged before anyone leaves the station. On single-track lines, the timetable specifies "the points at which two trains would meet and pass"—where one waits in a passing loop "where trains travelling in opposite directions can pass each other." The meet is planned. The siding is built before it's needed. That's the move "be more careful" can never give you: not better reflexes at the moment of collision, but a coordination point decided so far upstream that the collision can't form.

Single track vs. double track: which fix to reach for

So when do you add a track, and when do you dispatch? A simple test: ask whether the resource can be split. If the contention is genuinely a throughput ceiling on something divisible—a support queue two agents could each own a half of—then adding capacity is the right call, the honest double-track. But if two people working on the same thing keep colliding because there's only one of that thing—one prod, one roadmap, one decision—no amount of hiring builds a second one. That's a dispatching problem, and you solve it with signals and right-of-way, not headcount.

The reason this matters more every quarter is that we are all running faster trains. The 2025 DORA report found "90% of survey respondents report using AI at work" and "more than 80% believe it has increased their productivity"—yet it also warns that "AI adoption does continue to have a negative relationship with software delivery stability," because "an increase in change volume leads to instability." Faster trains, more of them, same single track. If you speed up every individual and never dispatch the meets, you don't get more throughput; you get more violent cornfield meets. It shows in the mood, too: Microsoft's 2025 Work Trend Index found nearly half of employees (48%)—and more than half of leaders (52%)—say their work feels "chaotic and fragmented."

How to dispatch your team's single tracks

You don't need a second track. You need a dispatcher's habits. Here's the playbook, and it's mostly async coordination for distributed teams—decisions made upstream so no one has to negotiate at the moment of impact.

Map your single tracks

List the resources on your team that only one party can hold at once: the deploy pipeline, the on-call pager, the shared schema, the customer of record, the call only one person gets to make. These are your single-track segments. Everything that collides will collide here, so name them before they bite.

Name the superior train

For each single track, decide ahead of time who has right-of-way and who takes the siding. This is decision ownership made explicit—not "let's align," but "on this resource, Maya has the main; everyone else clears it before she passes." Ambiguous authority is how two valid trains end up on one block. A named owner is a signal that's already green or red before anyone arrives.

Signal the blocks

Make occupancy visible the moment work starts, not at merge time. The whole discipline of trunk-based development—small batches, claim-before-you-start, integrate often—exists to keep two trains from quietly occupying one block, which is to say, to prevent merge conflicts before they form. "Who's touching this?" should be answerable in seconds, asynchronously, without a meeting. The block is only safe if its signal is lit.

Schedule the meet

Where two streams of work genuinely have to cross, plan the passing point in advance instead of hoping they miss. A standing fifteen-minute sync at the integration boundary is a passing loop. Coommit is built for exactly this kind of planned meet—a shared, persistent canvas and contextual AI mean two people resolving a contended decision can see the same picture in real time and leave behind a record of who took the main, so the meet happens in the open rather than as a surprise at merge.

The fastest way through is the siding

Every instinct in a fast-moving team says keep everyone rolling—idle people are waste, momentum is sacred, never make a builder wait. On separate tracks, that instinct is right. But the moment two people need the same single track, "keep everyone moving" quietly becomes "send two trains at each other," and the cost lands later, doubled: not only the redone work but the twenty-five minutes it takes to recover focus after a collision yanks you off course. On a shared line, the counter-intuitive truth holds—the fastest way through is for one train to stop and take the siding. Deliberate, scheduled waiting beats the crash every time.

The payoff is measurable. The teams in Atlassian's study that adopted real coordination practices cut their fragmentation tax "nearly in half (46%)"—not by laying more track, but by dispatching the track they had. As AI loads more, faster trains onto the same shared resources, the edge won't go to whoever hires the most engineers or runs the most parallel lanes. It'll go to whoever can still dispatch the meet—and that starts with a place where the whole team can see the line. Pick the one resource your team collides on most this week, name its superior train out loud, and watch how many cornfield meets simply stop forming.