For a long time, “leave no one behind” meant something very concrete to me, and nothing particularly political. I worked in IT, in the world of large software products that customers had often been using for years. At one point we had to move from an old generation of products to a completely new suite. From inside the company this looked, at first sight, like progress. The new products were better, more modern, easier to develop further. But customers do not experience progress in quite the same way as the people building the replacement. They have systems that work, more or less, and businesses built around them. They have local adaptations, procedures nobody remembers having invented, connections to other systems, operators who know where the oddities are hidden. Once software has been in use for a decade or more, the neat architecture diagram has long ceased to describe reality.
So the instruction was simple enough: no customer left behind.
That was good business, obviously. You do not spend years selling software to a customer, encourage him to build important parts of his operation around it, and then one morning explain that his problem is now that he has failed to keep up with your product strategy. But the interesting part was not the slogan. It was what happened once real customers started migrating.
Some moved with very little trouble. They had clean installations, competent people, not too many dependencies and enough time to prepare. Others needed help. And then there were the customers that everybody in support gradually came to know by name. Their configuration had some historical oddity in it, or several products interacted in ways nobody had really planned for, or a piece of software that was supposed to have disappeared years earlier was still doing something essential every night at two in the morning. You could not handle those customers by sending them the manual again.
That was when the organisation became interesting.
People who did not normally work together suddenly did. Support pulled in development. Someone from another product group joined because the failure was probably not in our component after all. A technical manager got involved because the customer was getting nervous. Sometimes people several levels apart in the hierarchy ended up talking directly because there was no point in allowing the organisation chart to slow down a problem that was already costing the customer money.
Nobody called this agile working. I do not even remember whether that word was fashionable then. It was simply what you did when the normal route stopped working.
And that, much more than the software itself, has stayed with me.
We had rules, of course. Procedures, ownership, escalation levels, support contracts, priorities, responsibilities. Large organisations need that. But there was still room for somebody to say: this case does not fit. We need to look at it differently.
That sentence matters more than it appears.
I think about it now when governments and public institutions use the same language: no one should be left behind. The intention is admirable, and I do not doubt that most people working in those institutions genuinely believe in it. We also spend extraordinary amounts trying to make it true. There are social benefits, housing programmes, educational support, health services, employment schemes, disability assistance, subsidies, allowances, special tariffs and many things I have forgotten while writing this sentence.
And yet people still get left behind.
Sometimes because there is not enough money. Sometimes because policy is bad. Sometimes because bureaucracy really is absurd. But I suspect quite a lot of it happens for a less dramatic reason: the system works exactly as it was designed to work, while the person in front of it does not happen to fit the design.
Real problems have an irritating habit of crossing boundaries. Somebody does not arrive with a housing problem on Monday, an employment problem on Tuesday and a family problem on Wednesday. It all comes at once. The unstable housing affects the job search, the joblessness affects the family, the family stress affects the child at school, and somewhere in the middle of that there may be poor health, debt or simply exhaustion.
Public institutions, meanwhile, are usually organised the other way round. One office deals with the income. Another with housing. Another with the child. Another with health. Each may do its job correctly. That is the uncomfortable part. Nobody has to be incompetent for the result to be poor.
I recognise this from software.
We occasionally had situations where every team could explain, quite convincingly, that its own product was behaving correctly. That was wonderful news for the teams and completely useless to the customer, whose system still did not work.
Someone eventually had to stop asking whose fault it was and start asking what had to happen next.
That sounds almost embarrassingly obvious when written down. In practice it is not obvious at all, because large organisations are very good at protecting the structure that was created to make them manageable. Public institutions probably have even stronger reasons to do this than companies. They are handling public money. Citizens must be treated fairly. Decisions must survive appeals, audits, political scrutiny and sometimes courts. You cannot simply tell every frontline employee to use common sense and hope for the best.
But there is a point where the protection against arbitrariness becomes a protection against judgement.
A teacher can know perfectly well that the prescribed approach is not working for a child and still have very little room to try something else. A social worker can see that the official support available to a family misses the real problem. Someone in an employment office can probably tell within ten minutes that sending a person to the standard programme will achieve almost nothing, yet the standard programme is what exists.
The strange thing is that these people are often the ones who see reality most clearly, because they meet it every day. They see which rules work, which rules fail, which exceptions are becoming routine and which clever policy idea from above produces nonsense once it reaches a real kitchen table.
But large institutions have always been much better at sending instructions down than at sending experience up.
That, for me, is the more interesting problem.
Top-down organisation has a certain appeal. It looks orderly. Somebody sets policy, somebody else turns it into procedures, people are trained, targets are defined, results are measured. On paper this is very comforting. The trouble begins when reality starts answering back.
In IT, if engineers in several countries independently invented the same workaround for the same problem, we eventually had to admit that perhaps the users were not the problem. At some point development had to hear about it. You did not want twenty support engineers becoming more creative at working around the defect. You wanted somebody to fix the defect.
Public institutions seem to have more difficulty with that move. A problem produces a rule. An abuse produces another rule. An inconsistency produces a standard. Somebody discovers a loophole and another control is added. Every addition may be perfectly reasonable when viewed on its own. Years later you have a system that nobody would ever have designed from scratch, but every part of it has a history and somebody can explain why it is there.
This is usually the moment when people start demanding deregulation or simplification. I am not sure that is enough. You can simplify the rules and still keep exactly the same culture.
What matters more is whether people in the field are allowed to take some responsibility for outcomes rather than merely for procedures.
That does not mean giving officials a blank cheque. It means allowing them enough room to say that a case is going wrong, enough authority to raise it, and enough access to people elsewhere in the organisation to do something useful about it. There can be checks. There should be checks. If somebody makes an unusual decision, let it be reviewed. If a lot of money is involved, require approval. If similar exceptions keep appearing, compare them and ask why.
But do not design the controls so tightly that the safest behaviour is always to do nothing unusual.
That is not accountability. It is self-protection.
The more I think about this, the less convinced I am that public institutions mainly suffer from a shortage of intelligence or goodwill. They probably suffer more from the way responsibility is sliced into pieces.
Everybody owns something. Nobody owns the problem.
That was exactly what we tried to avoid when a difficult customer migration got stuck. Somebody still had to feel that the customer was ours, not merely that ticket number 74631 belonged to another queue.
There is another element from those years that now seems important. The difficult customers did not receive the same amount of help as the easy ones. Nobody even considered that a problem. We were not distributing fairness in units of engineering time. We were trying to achieve a result. One customer might need a few hours. Another might need people from three teams and several weeks of attention.
Public systems are understandably nervous about that kind of inequality. If one citizen receives far more help than another, somebody will ask why. Sometimes that question is entirely justified. But identical treatment can also be unfair when people’s problems are radically different.
This is where “leave no one behind” becomes more demanding than it sounds.
It is easy to create a programme. It is relatively easy to count how many people used it, how much money was spent and how quickly applications were processed. Those numbers matter. But they can also hide the question that matters most: did the person get anywhere?
Not everybody needs rescuing. Most people, most of the time, manage perfectly well with standard services and straightforward rules. That is good. A functioning state should not interfere more than necessary.
But the people who really are getting lost in the system are often exactly the ones for whom standardisation works least well. They need somebody to notice that the normal answer is not enough, and an institution capable of doing something after noticing.
This is not a plea for government to become a giant personalised concierge service. Nor is it an argument that companies are clever and governments are stupid. Companies have more than enough bureaucracy of their own, and I have worked in organisations capable of producing wonderfully elaborate nonsense.
It is simply one lesson that stuck with me.
When we said no customer should be left behind, we did not mean that every customer had to be treated in exactly the same way. We did not pretend that every migration could be planned in advance, and we certainly did not assume that the people furthest from the customer always knew best.
We meant that when the normal process stopped working, the organisation still had to work.
Someone had to notice.
Someone had to care enough to take responsibility.
And, occasionally, the people higher up had to listen to the people who were actually looking at the problem.
That sounds modest. In a large institution, it may be quite radical.