Point-solution

In this episode, we explore a design-habit that can often cause huge challenges across a broader scope

In my ‘day-job’, I work as an enterprise-architect - which in essence means that I help people get things to work together in some kind of unified big-picture way. Things work better when they work together, on-purpose: so make sure that this supports that, and that this thing here plugs into that thing over there, and then it all connects up as a whole, even when things move around a bit all over the place and over time. That kind of idea, anyway.

Which, for the most part, works quite well, except for a common problem that can easily cause any kind of continuity to come to a grinding halt and stop everything in its tracks: something that we call a point-solution.

A point-solution is something that’s designed for just one purpose, often in just one place or department or whatever, and has no connection with anything beyond its immediate scope, nor even any awareness of anything beyond its immediate scope. We see this pattern in all manner of different forms, as local dialect or jargon or methods or by-laws, or that myriad of specific-to-this-department spreadsheets and small apps and so on. In metaphoric form, it looks a bit like this:

Yes, sure, there’s no doubt that each point-solution can work really well in that specific place, at that specific time, to meet the respective local need. But like the contents of each glass in that photo, each of them is kind of walled-off from anywhere else; and it can quietly fall apart over time, too, as people forget why they built it in the first place, or the person who built it moves on and no one knows how to fix it when it breaks down or when things change. Each of those issues is a potential problem in itself.

Yet imagine a system, a big-picture story, that’s made up of hundreds or thousands or millions of these little context-specific point-solutions. Sure, it sort of doesn’t matter whilst none of these point-solutions need to work together with anything else - but all kinds of chaos can pop out of the woodwork as soon as we do need things to work together across a broader whole. For example, up until the early 19th century, almost every town in every country had its own local time, which didn’t really matter all that much when people weren’t going anywhere at any significant speed. But once the railways came along, all those local inconsistencies suddenly mattered a lot - hence the imposition of ‘railway-time’, every town’s time linked that of some regional centre, and eventually giving us the standardised time-zones of today. (That’s on land, of course: those at sea had already long since learnt the hard way about the need for standardised time…)

Or, to give a more everyday example, imagine a business that’s made up of a myriad of localised point-solutions. (Okay, you probably don’t have to imagine it, because most organisations are still run this way…) Sure, there may be a few standardised software-apps and HR-procedures and the like that are knocking around the place, but otherwise every silo and sub-department and sub-unit will do pretty much everything in their own sweet near-random way, each with their own local jargon and processes and checklists and everything else. Which sort of wouldn’t matter as long as none of these places need to work together with anything else - except that, yes, they do need to work with everything else, to make up the end-to-end processes that connect across the organisation and all that. All of those point-solutions can make end-to-processes staggeringly inefficient and ineffective, because they don’t join up cleanly at the edges, and use different standards to measure time and quality and everything else. And when people move around from one place to another in the organisation - which they do, following promotions or job-opportunities or whatever - they then have to learn the new local way of doing things, which slows things down horrendously all over again. Or they try to do things the same way they did at the previous place, in which case all hell can break loose without warning and without people being able to understand how it’s happened.

In short, a point-solution may give us a good local-optimisation, and useful local-adaptation too; but they are most definitely not our friend when we need to keep things working smoothly across a larger whole…

---

Don’t get me wrong, there is definite value in having something that’s optimised for a specific context or place. The weather-app on my phone is a good example of that, though it’s perhaps not so much a point-solution, as more like a solution for a particular point in place and time: it tells me what the weather is, was or will be, for right here, relative to right now. Very helpful.

Or that’s how it’s supposed to work, anyway. Except this morning it decided that I was half a thousand miles miles away from where I actually was, and gave me the detailed real-time weather-report for a place I haven’t been anywhere near for near-on half a decade. And its point-of-reference is auto-selected, and there’s no manual override to let me choose the point-of-reference that I need. So for the entire day, until it finally disentangled its sense of place, I couldn’t get the weather-report that I actually needed. Not so helpful.

Sigh…

---

There’s a trade-off here, of course. There is value in having a point-solution that’s optimised for one place or context, yet that local value also needs to be kept in balance with the bigger picture: ‘act local, think global’, to invert an old catchphrase from my youth. And that local-value can be reduced to nothing or worse-then-nothing if it’s optimised for the wrong place or context anyway - as we saw with that weather-app, and as we also see so often with so many so-called ‘best practices’ and the like. Sure, standards do provide one useful way to help us get the balance right - but not so useful when the supposed ‘standard’ turns out to be someone-else’s point-solution arbitrarily imposed on everyone else, in a classic ‘one size fits none’ way.

So yeah, the only way that works is that we need to understand what each trade-off of this kind will depend on, and adapt accordingly to place and time and everything else. What doesn’t work is to pretend that there’s no need for a balance between local and global, and that our own preferred point-solution won’t have any impact on anyone else.

---

All of this also applies to our broader theme about small changes - that the way to tackle those really-scary really-big changes is to get better at doing the small ones. We need to remember that every small change that we do is also a kind of ‘point-solution’ to what’s in front of us right here right now - which means that every small change also needs to be aware of and in context of that bigger picture of those big changes that we face. Small changes need to be aware of everything else, and also connected with everything else. That’s perhaps the most useful lesson here from this point about point-solutions.

---