The Best Technology Doesn’t Start With Technology

You wouldn’t build a road through a farm field and only then ask where people need to go. Yet that is how we introduce a lot of new technology into organisations.

A tool arrives promising to make something faster, easier, cheaper (you name it). It looked good in a short demo. We tell people to use it and expect great things.

But people don’t work according to feature lists. A few years ago I sat through a demo of a housing management platform that had ‘added a development module.’ It ticked lots of boxes on the feature list. And almost nobody used it.

If you don’t understand how people work, you can build an excellent tool for a job nobody does.

The cost of not understanding the work

My first software business built viability tools for organisations developing affordable homes. The kind of software that works out whether a site stacks up once you account for the fact that a housing association isn't selling land; it's borrowing against thirty years of rent. Every major housing platform then built something similar, bolted onto their core system.

Technically, these bolt-ons did what the spec said. What they didn't do was understand the job: the workarounds, the judgement calls, the things a development officer does automatically that never make it into a requirements document. This shows up in a technology review, eighteen months later, when you find out no one is using the tool.

When you optimise guessing

The more complicated the work becomes, the easier it is to mistake the system for the work itself. And there are plenty of examples of what happens when that distinction gets lost.

Start with the Building Safety Regulator. In July, it admitted that two-thirds of building assessment certificate applications this year were refused: nearly 2,000 buildings were directed to apply, and 66% were turned away. Not because the buildings were unsafe. Because, in the regulator's own words, organisations “couldn't clearly demonstrate how safety was being managed.”

Compliance and demonstrating compliance turned out not to be the same thing. Most of those organisations were probably doing the work. What they couldn't do was show it, because the evidence of their understanding was scattered across systems nobody had connected. That's not a paperwork problem as much as it is an understanding failure.

Or take Crimson's research from Birmingham, which found use getting ahead of understanding with AI. 47% of housing associations are already using AI day to day. 87% admit they have low knowledge of what they're actually using. Only 42.2% of housing professionals trust the accuracy of their own organisation's data. Put those three figures together and the shape is obvious: adoption is running well ahead of understanding, and understanding is the one thing none of the adoption dashboards track.

You cannot build predictive repairs, proactive compliance or tenant-facing AI on data that fewer than half your own staff trust. It doesn't matter how capable the tool is. If nobody understands what's feeding it, or believes what it's telling them, you haven't solved anything. You've just optimised guessing.

This is worth asking

Social housing carries a genuinely brutal amount of complexity: a patchwork of systems, each built to satisfy a different requirement at a different point in time, most of them not talking to each other, all of them still needing to be reported against. Layer on the regulatory pace of the last year (Awaab's Law, the revised consumer standards, STAIRs) and you get organisations spending most of their capacity just keeping up, with almost nothing left to fix the underlying spaghetti junction.

It would be easy to respond to that with a feature list. AI that “does compliance.” AI that “connects your data.” AI that “summarises anything.” All true in the abstract; all useless if it doesn't match how a repairs officer, a compliance lead, or an asset manager works through their day.

So we start by understanding the job, properly, with the people doing it, in the same slow, unglamorous way that separated the software people adopted from the software that just sat there. Only then does it become worth asking what AI should do inside that workflow, and just as importantly, what it shouldn't.

Stonewater's pilot with the Dutch AI specialist SPOTR is the version of this I'd point to as getting it right. Full stock condition surveys happen every few years, not annually, so most landlords genuinely don't know the condition of most of their homes most of the time. The obvious feature-list answer is to train everyone to spot hazards properly.

That's not realistic across 40,000 homes, and to their credit, nobody involved pretended otherwise. So the tool works with what people can already do: take a photo during a visit they're making anyway, instead of asking them to become surveyors on top of their day job. As SPOTR's own chief exec put it, the tool will never replace human eyes and judgement. It's designed around the actual shape of a routine visit, not an idealised one. That's understanding, built into the product, not bolted on afterwards.

What happens when residents aren’t convinced

Understanding only counts if it runs both ways. Granicus published research this July showing that 76% of housing staff say AI is already embedded or being trialled in their organisation, and 80% believe their digital services are fully accessible. Meanwhile, 49% of citizens say they don't trust, or are uncomfortable with, public services using AI at all, and 42% don't believe housing organisations will meet residents' digital expectations by 2028.

That gap is the same failure as the bolt-on development modules. An organisation can understand its own tool perfectly and still build something the person on the other end doesn't understand. If a resident doesn't know what's being used, why, or what happens when it gets something wrong, success on the internal dashboard means nothing.

The part you can't shortcut

I'd rather build slower and understand something properly than move fast and understand nothing.

That's a lesson from twenty-plus years in this sector I've never seen disproven. Not by a development module nobody opened. Not by a 66% rejection rate. Not by an AI rollout loved only by the IT team.