The Escalator Problem : Metros and Customer Requirements

I grew up in Chennai where escalators weren't really part of public transport yet, though that's gradually changing as the metro system expands. Using escalators in metro stations was still a relatively new experience for most people there.

Then I moved to Germany in 2019, and Berlin's U-Bahn showed me something completely different. Everyone stood on the right without exception while people walked briskly up the left. I stood on the left once by accident and someone cleared their throat behind me. I moved immediately.

During a work trip to London, I saw the same behavior. Now in Munich, I do it automatically. At least 3-4 times a week, I pass through Munich Hauptbahnhof for work, sometimes on weekends too for missed grocery shopping at the Edeka. Every time, I take the escalators. Stand right, walk left. It's automatic now.

Watching Germans rush up the left side during rush hour, you understand why the convention seems to exist.

Or so I thought, until I watched a Veritasium video about escalators last month.

The Constraint That Disappeared

The video covered the 2018 Rome metro disaster where an escalator malfunctioned and injured 24 people. But what caught my attention was something more subtle: why we stand on the right and walk on the left.

It started in 1911 at London's Earl's Court station. The first Underground escalators had a diagonal partition at the top that physically shunted passengers to the left as the stairs disappeared beneath it. People walking up would collide with standing passengers at the exit.

The solution was simple: tell people who stand to stay on the right so walkers could use the left and exit smoothly. Problem solved. The convention stuck.

Here's what's fascinating: modern escalators eliminated that diagonal partition in 1924. We step off straight ahead now. The original engineering constraint no longer exists, yet the behavior persists globally in London, Munich, New York, Singapore, and Tokyo.

We built an entire social contract around a workaround for a constraint that disappeared 80 years ago.

The Research Nobody Wants to Believe

In 2015, Transport for London ran an experiment at Holborn station. TfL noticed that on long escalators, very few people actually walk. A 2013 study found 74.9% stood while only 25.1% walked, meaning the left side was mostly empty while the right side was packed.

So they tried something radical: asking everyone to stand on both sides.

The results were remarkable. An escalator that normally carried 2,500 passengers between 8:30-9:30am carried 3,250 when designated standing only. A 30% increase. Station congestion dropped significantly.

TfL launched a six-month trial in 2016 with behavioral messaging, talking holograms, footprints on steps, and announcements playing "I'm Still Standing."

People hated it. Londoners complained about losing their "daily cardio." Two-thirds opposed the change. Many ignored the rules entirely. The trial ended. The convention went back to normal.

Why? Because the behavior feels necessary even though research proved a better method exists. We've optimized around it, built expectations around it. The workaround became the system.

What This Means for Solutions Engineering

This is my 10th year in various Presales roles, starting back at Infosys. I see this "1911 thinking" everywhere.

Processes get built around what tools can do, not what users need to do. Users build processes around product features because that's what the tool allows. Over time, those workarounds become documented workflows, get trained to new hires, and become "the way we work." Not because they're optimal, but because they're what the tool made possible.

The original constraint disappears. The technology changes. But the workaround stays. It becomes the ghost of a problem that no longer exists.

Take design collaboration. Until 2017, design teams used Sketch, which saved files locally. So teams built elaborate workflows: Abstract for version control (15-minute syncs), Zeplin for developer handoff (always outdated), InVision for prototypes, Dropbox for "final_v2_FINAL_use_this.sketch" files. This wasn't "the design process." This was a workaround for Sketch's local-file limitation.

Then Figma launched in 2016. Cloud-native, real-time collaboration, automatic version history. Teams that switched eliminated entire steps. The daily standup to coordinate file access? Gone. The 15-minute Abstract merge? Gone.

Or project management. Teams tracked tasks in Excel with manual status updates in colored cells. Weekly meetings existed just to read through the spreadsheet together. Then Trello popularized Kanban boards. Visual workflow, drag-and-drop updates, bottlenecks immediately visible. Teams that switched changed their entire workflow.

The diagonal partition was eliminated. But most teams kept standing on the right because "that's how we do work here."

The Solutions Engineering Problem

This pattern shows up everywhere. Customers ask for features that replicate their current workflow, not realizing their workflow only exists because their legacy tool forced them into it.

As Solutions Engineers, we sit between customer requirements and product capabilities. Our job is asking: "Is this process actually right for you, or is this just what your legacy tool forced you to do?"

Sometimes the answer is: "Our tool isn't the best fit if you want to keep your current process." That's honest consulting. Because building features that optimize legacy workflows keeps customers trapped in prettier versions of their broken processes.

Three Questions That Matter

I now ask three questions in every discovery call:

1. Walk me through how you do this today, step by step. This reveals the workarounds, the manual steps, the places where someone exports data, reformats it, emails it, and waits for approval. These are your escalator conventions.

2. Why do you do it that way? Most answers are "because that's how our old system worked" or "we've always done it that way." Sometimes there's a real reason like regulatory requirements. Often it's legacy behavior where the diagonal partition is gone but they're still standing on the right.

3. What would happen if you couldn't do it that way anymore? This separates real constraints from assumed constraints. If they panic, there's real need. If they pause and say "we'd find another way, but this is what we're used to," that's cargo cult behavior.

Why Product Alignment Is Important

But you cannot do this with confidence alone. This is where most SEs fail.

You need deep alignment with Product. You need to understand the engineering choices, why it was built this way, and specifically why it wasn't built the other way. When you know the design intent, the entire conversation changes.

Instead of defending gaps ("we don't have that feature"), you lead with value ("we solved for the underlying need differently, let me show you"). Instead of losing deals on feature checklists, you win on business outcomes. Instead of replicating workarounds, you help customers see what's now possible.

This is the SE role: the bridge between product strategy and revenue.

When SEs and Product teams aren't aligned, SEs become order-takers. They match features on a checklist. They lose deals on gaps. They win deals that become implementation nightmares because the customer's workflow doesn't fit the product's design.

When SEs and Product teams are deeply aligned, SEs become consultants. They spot the ghosts. They guide customers to better outcomes. They close deals that actually transform operations.

The closer you are to the product and design, the closer you become to the solution.

The Takeaway

That escalator convention from 1911 persists because we've normalized the workaround. Research shows standing on both sides increases capacity by 30%, but we can't change because the behavior feels necessary.

I see the same pattern in every deal cycle. Customers describe their workflows in detail, and somewhere in that description is a workaround they've normalized. The spreadsheet they maintain manually. The daily standup that exists just to sync status. The approval chain that adds three days to every decision.

They'll ask us to replicate these workflows because that's what they know. And sometimes we do. Sales pressure, implementation timelines, "the customer is always right"—there are real reasons why we build what's requested instead of what's needed.

But the best deals I've closed, the customers who actually transform their operations, are the ones where we found the diagonal partition together. Where I could show them: "This process exists because your old system couldn't do X. We can. So this entire workflow becomes optional."

For product teams: When SEs keep hearing the same feature requests across deals, it's tempting to build them. But those requests often describe workarounds from legacy tools. The features you build today become the constraints customers work around tomorrow.

The diagonal partition was eliminated in 1924. You can step off in any direction now. But if no one points that out, you'll keep standing on the right because that's what you've always done.

As SEs, we're in the middle. Between what customers ask for and what they actually need. Between closing deals and delivering value. Between replicating legacy workflows and helping them see what's now possible.

Recognizing the diagonal partition when customers can't - that's where the real work happens.