Best Practice is Someone Else's Context

fifteen years, four very different builds, one repeating lesson: every playbook quietly carries the assumptions of the place it came from, and the real work is figuring out what your place actually needs.

The office had no natural light. Our window faced the side of the next building, a few metres of flat grey wall, so midday looked the same as four in the afternoon: the same fluorescent hum, the same grey. A colleague walked over with a stack of A3 printouts, organised by section of the facility, and handed them to me to look through. An ammonium nitrate plant, to be built in Karratha, Western Australia. My job, as a process safety engineer, was to work out what could go wrong with it before it was built.

I flipped to the prilling tower. Molten ammonium nitrate falls from a height inside the tower and solidifies into pellets on its way down, landing on conveyor belts that carry them off to storage. I knew the drawing before I had properly read it. Years earlier, in Sydney, I had worked through the same process step for a facility on Kooragang Island in New South Wales. Same equipment, same arrangement, nearly the same lines on the page. The work had followed me across the country, almost identical, except now my title was more senior.

That was the first weight: the realisation that even chemical plants are cookie-cut. I had assumed that facilities handling explosive material would be bespoke by necessity, each one engineered from its own ground up. They are not. Designs travel. Templates get reused. The A3 in my hand was proof.

The second weight arrived more slowly, through a pattern in the work itself. Clients would return three to five years later, needing reassessment for their regulatory approvals, and we would find our old recommendations sitting exactly where we had left them: in the report, unacted. The reports had been produced, submitted, and shelved. They satisfied a regulator. It was hard to argue they had made anything safer.

Two discoveries from the same chair. The world is more templated than it looks, and a technically correct deliverable that changes nothing is its own kind of failure. Around that time I started gravitating toward our Singapore team, who built software, and I never really gravitated back.

The other side of the table

Years later, in Brunei, I caught myself holding the cookie cutter.

I was building Mana Makan, a dining directory for a country of about 400,000 people. I had the photos, the menus, the opening hours, the locations. Reviews were next on the list, and they barely felt like a decision. Every platform on earth had reviews. Google had reviews. The playbook was unanimous.

I skipped it entirely.

Not out of insight. Out of listening. When I brought reviews up with the restaurant owners, the pushback was immediate, and one of them put it in a way I have never forgotten: "Do you remember what happened to that restaurant that closed down? Someone posted very bad reviews on social media, and ever since then they could never quite get back to where they were. Eventually, they closed."

From inside their world, the logic was airtight. In a country this small, word travels instantly and customers are finite. A good review might help at the margins. One bad review, genuine or fabricated, could be terminal, and there is no second market to retreat to. Review systems are built on an assumption nobody states out loud: that the pool of customers is large enough to absorb the damage of unfair feedback. Brunei does not have that pool.

Food photos taught me the same lesson a second time. I had assumed that showing the dish was obviously best for users. The owners knew better. Some told me a photo killed the element of surprise. Others said it made things worse when the plate that arrived did not match the picture. My obvious best practice was wrong twice, and both times it was the people running the restaurants, not me, who caught it.

In Perth, the template had been done to me: I was the one handed the cookie-cut drawings. At Mana Makan, I was doing the cutting myself, importing Google's patterns into a small country without once asking how people here actually decide where to eat. Best practice, I started to understand, is someone else's context, fossilised. It encodes the constraints of the place where it was invented, and it carries those constraints silently into every place it is copied.

Starting from the pain instead

So what does it look like to design from context instead of from a template?

During COVID, I built a volunteer management system, working directly with the operations manager who would live inside it. The pain points were not hypothetical, and I did not have to guess them. Signup data was inconsistent: duplicates, errors, hours of cleanup just to establish whether someone was already in the system. A handful of operations staff had no realistic way to consolidate activity across volunteers whose involvement ranged from once every three months to every day for a month straight. Then His Majesty decided that volunteers would be remunerated for their effort, and suddenly attendance tracking had real money riding on it.

The first version of the interface did not work smoothly. That mattered less than I expected, because the feedback loop was tight enough to fix it fast. We iterated until the system could onboard a volunteer quickly, assign them to both repeated and ad-hoc tasks, and produce every volunteer's remuneration slip within thirty days of month end. The system was trusted to pay people on the King's behalf. That is the outcome metric I keep, because it is behavioural: not a satisfaction score, but money moving on time through a system a small team could actually run.

Nothing about that build came from a playbook. It came from sitting with one person's operational pain until the shape of the solution fell out of it.

Adding friction on purpose

Starting from someone's pain is one thing. The harder test came when the context told me to break the rules outright.

YB Queenie, who serves in our legislative council, fields a steady stream of complaints, inquiries, and suggestions from citizens. The Citizen Engagement Portal was her own initiative to streamline that flow: a tool for the conversation between a representative and the people she represents. Nothing like it had been done digitally here before. We were designing in a blue ocean, with a triage team you could count on one hand.

Every UX guide I had ever read said the same thing: reduce friction.

So I added more.

The form was deliberately not frictionless. It asked the citizen to think before submitting: gather evidence about the problem, work out which ministry was actually responsible, and only then send it in. We supplemented it with an online guide and social posts teaching people how to report a problem to a legislative member, because the form had to educate as much as it collected. Frictionless design assumes an informed user and a large team to absorb whatever arrives. We had neither, so friction was the user-centred choice.

I won't recount any of the individual submissions here. What matters is what their structure made possible. Because each one arrived categorised instead of raw, we could do something a pile of free-text complaints never allows: read across them. Issues that came in separately, from different people at different times, turned out to be the same problem wearing different clothes. The friction that asked each citizen to gather evidence and pin down the responsible ministry was also what let us link those threads — to trace recurring complaints back to a shared root instead of triaging each as an isolated fire, and to see the trend rather than just the latest grievance. A little deliberate friction at the front door was what made the whole stream legible.

That, I think, is what mastery of a best practice actually looks like: knowing the rule well enough to know precisely which of its hidden assumptions your context violates, and breaking it there, on purpose, and nowhere else.

The question before the AI question

These days, organisations come to me wanting AI. I ask all of them the same thing.

What are you actually trying to solve?

More often than not, there is a more fundamental problem sitting underneath the request. Where is the data? Is it digital? Can anything access it programmatically? Asking for AI before the data is ready is the 2026 edition of a pattern I first met in that Perth office: the shiny deliverable resting on fundamentals nobody did. A risk report in a drawer and an AI pilot on top of inaccessible data are the same artefact, fifteen years apart. Both satisfy the people watching. Neither changes how anything works.

The template has simply updated itself. It used to say "every facility needs a risk assessment" and "every platform needs reviews" and "every form should be frictionless." Now it says "every organisation needs AI." The sentence changes; the fossilised context underneath it does not.

A slide at Setia Point

In August 2025, I was sitting in the audience at a digital transformation workshop at Setia Point when a speaker's slide came up citing an article sourced from EverythingBrunei.com, the Brunei search engine I had built. I had watched its traffic numbers for years, but I had never physically seen a use of it in front of me like that: my own project, on someone else's slide, doing work in a room I happened to be in.

I will be honest about the numbers, because the numbers are two different kinds of evidence and I do not want to inflate either. EverythingBrunei peaked at around 400 visits a day, fell as low as 20, and hovers around 100 now. The citation does not prove growth. It proves the thing escaped me and entered the world. Meanwhile Mana Makan, which I have not touched in six years, still draws about 1,500 visits a month. That zombie traffic does not prove excellence. It proves durable demand: the directory nobody maintains still has a queue at the door.

I keep both numbers on the same shelf, labelled accurately. That feels like the same discipline as everything above: the value of a thing is not what the playbook says it should be worth, and not what I wish it were worth. It is what the context, observed honestly, keeps telling you.

Best practice is someone else's context. The work, every time, in every domain I have touched, is asking what this one needs.