Optimizing Your Subway System

Photo by squirrel

I woke up the other day to the headline that BART – the local subway system in the San Francisco Bay Area – fixed a software issue that was causing 34,000 delays every year.

Turns out that for some decades trains have been programmed to slow down “at any hint of moisture in the air”. Which, ya know, is quite often here in the Bay. That adds up to a whole lot of slowed down riders over the years.

Probably that was an intentional design choice at the time it was implemented. Probably made perfect sense for safety reasons. But since then things have changed. There’s a new fleet of trains, and the tracks have been upgraded, and engineering techniques have improved, so the same level of caution is no longer needed.

Meanwhile, year after year, trains have kept right on slowing down every time the dang fog rolls in. Fixing it was on the radar, but the price tag wasn’t trivial. So they punted it and punted it. Eventually they got so worried about losing frustrated riders they felt like they couldn’t put it off any longer.

It’s a great metaphor for most organizations. We often compare an excellent “platforms ecosystem” to a sophisticated subway system, whizzing your organization’s important people and cargo and information here and there, zillions of times a day. If things are working well, everything is delivered to its destination on time, on target, with a minimum of extra manual effort. People have the tools and info they need to quickly read and react. They are spending their time and effort and skills ever more wisely, as those systems improve around their work.

Whereas when systems aren’t optimized, you’re slowing down the whole transit system. People’s time isn’t as effective, the quality of work isn’t as good, and percentages of effort are wasted. The exact numbers are difficult to measure, but step back and think about it. Do you have any doubt that some major wasting of effort and potential is happening at your organization?

Of course it’s rare that you get a tradeoff that’s as clearly defined as, “Should we fix this software issue that’s causing 34,000 rider delays every year?” That would make the ROI argument much easier to understand.

Nonetheless, your issues are probably having a similar level of impact. They’re a rate limit on everything everyone can accomplish.

You can certainly choose to keep it old school. Budgets are as tight as ever, so you might decide you have to just live with those inefficiencies. You might have no choice but to deal with everyone and everything continuing to move more slowly than it should. If you happen to be a municipal subway system, riders will probably keep showing up, since their alternative options are limited.

But if you’re a modern organization fighting for relevance and market-share in an increasingly fast-moving world, how long will you be able to compete while everyone on your team is working at a fraction of their potential speed and creativity? How long can you turn a blind eye to your version of those 34,000 rider delays that are happening every year? 

More inspiringly, what could you do with all of that freed-up time, capacity, energy, and innovation?