{{ title }}

Ihave been trying to name a habit of mine, because I think it explains more about how I work than any job title would. The habit is this. I cannot sit inside a process for long without quietly asking what could be done better here. Not louder, not faster, but better, in the sense that someone’s day actually gets lighter. For a while I got to do exactly that for a living, owning systems and leading projects inside a large company, and also leading the rollout of AI into the internal services at headquarters. The combination suited me more than I expected, and the reason it suited me is the thing I want to write down.

I am an anthropologist by training. I am also, and I say this without irony, a technologist by temperament, almost manic about staying current on how artificial intelligence can make a project better. That pairing sounds contradictory until you have lived inside it. The anthropologist watches what people actually do, not what they say they do, and the technologist asks what could be built to fit that reality. Most organizations have plenty of one or the other.

The two in the same head turns out to be a useful and slightly restless instrument.

Two of the things I built there started as nothing more than my own irritation with a situation, moved through an idea, and ended up as global pilots across the group. I am genuinely proud of that, less because of the outcome and more because of what the path says about a way of working. You see a situation. You ask what could be done more efficiently or better here. And then, crucially, you do not just build the obvious fix. You use design thinking to find out what actually serves the user, so that you are not improving the process for the process’s own sake. That last clause is the whole thing. It is very easy to optimize work that should not exist, to make a bad form faster instead of asking whether the form should be there at all.

The first project was almost embarrassingly simple to describe, which is often the sign of a real problem. The people function, P&O, had no ticketing system. Every request from across the company arrived as a Teams message or an email, scattered across inboxes and chat threads. Nobody could see the shape of the whole. You could not tell which requests came most often, which division they came from, whether it was group or collection or recycling or food, or how much time each case was actually costing. And without that, you cannot do the things a mature function needs to do. You cannot allocate cost fairly per case per person. You cannot build KPIs. You cannot keep honest statistics. So I built the ticketing flow that gave the function its own nervous system, a way to see what was coming in and from where.

But the part I care about is what the system made possible once it existed, because this is where the anthropology quietly does its work. Once you can see what people ask most often, you can write good documents that answer those exact questions and publish them before they are asked. The function stops being purely reactive and starts being proactive. That shift, from answering the same question forty times to answering it once in a way that travels, is the small structural change that frees a team. The ticket system was never really about tickets. It was about making the invisible pattern of a team’s work visible enough to act on.

Which led straight into the second project, and the one that connects to almost everything I think about now. With a ticketing system in place, you can see the recurring questions clearly enough to template them. And once you have templates, you have the raw material for AI to help answer routine requests. But, and this is the part most people skip, those templates have to be current, correct, and ready for audit. P&O handles sensitive information, so an AI assistant cannot be allowed to reach out and pull from anywhere. It has to draw only from a closed, governed system. That meant setting up a real structure in SharePoint and Teams, the right attributes on every document, a security model around the whole thing, and the slow unglamorous work of reviewing and categorizing all the historical documents so that nothing stale or wrong could leak into an answer. If that sounds familiar to anything else I have written about, it should. It is the same conviction that a clinical tool must answer only from a closed, verified source. The principle does not care what industry it is in.

An assistant is only as trustworthy as the boundary you draw around what it is allowed to know.

There was a human layer to that project that I have come to think matters as much as the technical one. A change like this can easily land on people as more work, another system, another rule. So part of the job, maybe the harder part, was the communication. Leaders and employees had to hear about it in a way that felt like relief rather than burden, like something being lifted off them rather than added. You can build the cleanest pipeline in the world and still fail if the people it is meant to help experience it as a tax. The anthropologist in me knew that the rollout was not finished when the system worked. It was finished when people wanted to use it.

There is a dimension to all of this that is easy to leave out of a tidy story, and it deserves its own honest paragraph, because it was often the hard part. None of this happened in a single room. A large company is not one organization but many, stacked and overlapping, group and collection and recycling and food, each with its own leaders, its own priorities, its own sense of what matters this quarter. A change that looks obviously good from where you sit can look like a threat, or simply like noise, from where someone else sits. So a great deal of the work was not technical at all. It was learning to read a map of stakeholders, to understand who owned what, who had to be consulted before anything moved, who would quietly sink a thing if they felt it had been done to them rather than with them. And it played out across time zones, which sounds like a logistics footnote until you have tried to hold momentum on an initiative where the people who must agree are awake on three different continents and never all at once. You learn to design the conversation as carefully as the system, to write things down so they survive the gap between one region waking and another going to sleep, to build consensus asynchronously because synchronous was rarely an option. The complexity was real, and I came to see it not as friction to be resented but as part of the actual problem to be solved.

A solution that cannot survive an organization’s politics and its geography is not really a solution. It is a prototype that never left the room.

When I look at why those two initiatives traveled as far as they did, I keep landing on the same answer, and it is not that the technology was clever. The ticketing flow was not clever. The governed AI structure used ordinary tools, Teams, SharePoint, the everyday Microsoft stack, the same software thousands of companies already have. What carried them was the order of operations. Watch first. Find the real problem, not the loud one. Design for the person who has to live with the result. Only then build, and build with the discipline to keep it honest and safe. Design thinking, at its core, is just the insistence on understanding the actual problem and the actual user before reaching for a solution, and that is the part organizations skip most often (IDEO, Tim Brown). Ethnography, the anthropologist’s tool, exists precisely to reveal what people do and need rather than what they claim (Institute of Product Leadership).

I think that is the real thread, and it is the one I carry into everything now. Owning a system rather than just operating it means you are responsible not only for keeping it running but for asking whether it should run the way it does at all. The anthropologist watches. The technologist builds. And the most useful work tends to happen in the narrow space between those two, where you have understood a problem deeply enough to be sure that the thing you are about to build is worth building. I am still, somewhat helplessly, the person who cannot sit in a process without asking what could be better here. I have just learned that the question is only worth anything if you answer it for the user, and not for the work itself.