Operating consultancy for transit and mobility

Transit lives at the intersection of physical, digital, and civic. Three grains, one organisation.

Three grains, one organisation

Walk into most operating businesses and you're dealing with one clock. A SaaS company ships on a sprint cadence. A manufacturer ships on a production cadence. Pick the rhythm, build the operating model around it, done.

Transit doesn't get that luxury. A bus operator, a metro authority, a mobility-as-a-service platform: all three are running hardware, software, and public trust through the same organisation at the same time, and each of those runs on a completely different clock. Get the org chart wrong and you don't get friction, you get outages, safety incidents, and press coverage that costs you the franchise renewal.

Most operating consultants walk in and try to fix the org chart. Wrong move. You fix the cadence mismatch first. The org chart is downstream of that.

Hardware moves in years

A new rolling stock order takes three to five years from spec to first passenger service. A depot retrofit for a new fleet type is a two-year civil engineering project before a single train touches the rails. A fare-gate replacement across a network runs on a procurement cycle measured in parliamentary terms, not product terms.

This isn't inefficiency. It's physics and money. Steel doesn't get faster because you run a retro. A £2bn rolling stock contract doesn't get de-risked by moving to two-week sprints. The hardware side of transit is, correctly, conservative, slow, and allergic to iteration. That's the grain. Don't fight it.

Software moves in weeks

Sit next to the hardware programme and you'll find the app team shipping a new payment flow every fortnight, the real-time arrivals feed getting a data-pipeline fix on a Tuesday, and the ops dashboard picking up a new alert type because last week's platform overcrowding incident showed a gap.

This is correct too. Software should move at software speed. The problem starts when the organisation tries to run software governance on hardware timelines (a six-month change advisory board for a bug fix) or hardware governance on software timelines (deciding platform-edge sensor specs by sprint retro). Both directions of mismatch are common. Both are avoidable.

Public trust moves in generations

This is the grain most operators underweight, and it's the one that actually constrains everything else.

A fare change proposal needs a public consultation period measured in months. A single high-profile safety failure, a door malfunction, a driverless-train trial gone wrong, sets confidence back further than the incident itself would suggest, because transit trust compounds slowly and drains fast. London still talks about the 2015 New Year's Eve Tube overcrowding crush. Operators still cite it in risk committee papers a decade later. That's the half-life of public trust in a transit brand: it doesn't reset on the next financial year, it sits in institutional memory across change of leadership, change of franchise, change of political administration.

Civic trust is the slowest and most expensive of the three grains to rebuild, and the easiest to spend without noticing. A product team optimising for weekly release velocity will, left unchecked, ship a change that trades a sliver of public confidence for a small usability win. Multiply that by fifty releases a year and you've quietly bankrupted the trust account nobody was tracking.

Where the seams break

Nearly every transit failure that makes the news happens at the seam between two domains, not inside one of them.

Take contactless payment rollouts. The software is ready. The hardware, the gate readers, the onboard validators, isn't, because it's still two years into its five-year replacement cycle. The organisation ships the app anyway because the software team is measured on release cadence, not fleet readiness. Result: a customer taps in on a bus with old hardware, gets charged twice, posts about it, and the story that runs isn't "hardware upgrade in progress", it's "operator can't get basic payments right." That's a seam failure between hardware cadence and public trust, mediated by a software team that had no visibility into either.

Or take a fare-structure change designed by finance on a quarterly cycle, handed to product to ship on a two-week sprint, without the six-month consultation period civic trust actually requires. The software ships fine. The public reaction doesn't care that the code worked.

The operating system's job is not to make the three grains agree on tempo. They never will. The job is to build the governance and communication structure that lets a hardware decision, a software release, and a public commitment all reference the same underlying model of the network, without forcing any one of them to move at another's speed. That means shared data models between engineering and product (so the app knows which gates are upgraded and which aren't), staged rollout gates that check public-trust readiness as a first-class blocker alongside technical readiness, and an escalation path that routes seam-level decisions to someone empowered to see all three grains at once, not just the one they were hired into.

The operators who hold it together

The most valuable hire in a transit organisation is rarely the best engineer or the best product manager. It's the person who has sat in a depot procurement meeting, then a sprint planning session, then a public consultation evening, and instinctively knows which grain is load-bearing for the decision in front of them.

These people are rare because the career paths that produce them don't exist by design. Civil engineers stay in civil engineering. Product people stay in product. The operators who cross all three usually got there by accident, a secondment, a crisis that forced cross-functional exposure, a career restart after a franchise change. Deliberately building that exposure into how you develop people, rotating a rising product lead through a depot placement, putting an engineering director in the room for consultation planning, is one of the few interventions that pays off on all three cadences at once.

Get the operating model right and the three grains don't need to move at the same speed. They just need to know about each other before the decision, not after the incident.