The engineers wanted the whole service behind a sign-in.
They were right to think about security. It is their job, and they are good at it. My job was to think about who a sign-in would stop.
A few years ago I would have walked into that meeting braced to lose it. I would have made the user's case from the outside. The engineers would have made theirs from the inside. We would have talked past each other until somebody senior decided.
This time I walked in steadier.
I have worked with Claude for years, but in the months before that meeting I had taken it further than ever: late nights building front ends and back ends, and architecting whole systems. I was studying for Anthropic's Claude Certified Architect, Foundations exam, and building as I studied, so the credential and the work held each other up. The model taught me as I went, in terms that fitted someone who came up through design and research.
I had also pushed changes to live services with my own hands. I know now what that means. When something breaks, your fingerprints are on it.
So I did not walk in thinking security was somebody else's worry. I was still learning the engineering side, and I knew it. What I had learned was enough to change the question.
A few weeks earlier I had asked Claude to go through the code and explain how the routes to sign-in worked. In the framework we use, sign-in is not switched on for a whole service. It is set page by page, on each route a person can reach.
None of that was news to the engineers, though the plan on the table was still a blanket one. It was news to me. It let me make the user's case in the unit they build in: the route, not the service.
So I said it in their terms. Without a sign-in, the parts we had built could be open to prompt injection, where somebody hides instructions for the AI in what they type, and the model follows them. It is the risk that makes a blanket call feel safe. It is also one a designer can reason about, once they can see where the model reads and where it only shows a page.
The guidance pages could be read safely without a sign-in, and people needed to reach them.
The question was always there to ask. I could ask it because I knew it was there. The question became which steps needed one.
We went through them together. One step let people send a request to the team that runs the service. That step got a sign-in, because it was the one somebody could use to send us something they should not.
The guidance stayed open, because we wanted everyone to be able to read it. We agreed to look again as the service develops.
The engineers took something from it too. Accepting a small, managed risk on the open pages is what lets a service be adopted at all.
The band
A conductor would have made one call for the whole service: sign-in on, or sign-in off.
That is how government has tended to run its digital teams. Like an orchestra: a section and a seat for each discipline, a score passed down the line, the conductor's decision at the end. It works, and it has made some beautiful things.
We decided page by page, which is how a band works. We faced each other and listened to the whole song. Authority went to whoever the others could hear.
The engineers listened because I could follow their reasons. What they listened to was the user's case, the same one I have been making for years. Speaking in routes got me a hearing. What I said with it came from years of watching people use services.
Knowing their part shrank the decision from the whole service to one step. A call for the whole service has one winner. A call made part by part lets each side keep what matters to it.
By the end we were reading from the same running order. In 1993 Janis Cannon-Bowers, Eduardo Salas and Sharolyn Converse described the shared mental model: a team works better when its members share an understanding of the task and of each other's part in it. In 2010 Leslie DeChurch and Jessica Mesmer-Magnus pooled the studies. That kind of shared understanding tracked how well teams performed.
Heads of profession will hear T-shaped people in this, and it is close. But a T is drawn around one person, and hired for. A shared mental model belongs to the team. It only exists when the people across the table can follow you too, so it lives in the conversation.
The engineers use AI models every day too, so the learning runs both ways. Nobody has swapped instruments. Each of us now hears more of the song around our own part.
Your own part
Learning another part from a model is not automatic.
In January 2026 Judy Hanwen Shen and Alex Tamkin at Anthropic ran an experiment with 52 developers learning a programming library they had not used before. Some had an AI assistant that would write the code on demand. Afterwards, the ones with the assistant scored 17 per cent lower on a quiz about what they had just used.
The split inside that group mattered more. Among the few whose sessions the researchers studied closely, those who had the model write the code averaged below 40 per cent. Those who asked it to explain how things worked averaged 65 per cent or more.
I learned by asking. That put me in the second group, and the page-by-page question in that meeting came straight out of it.
The user's case I made that day did not come from a model. It came from the people I have watched get stuck.
When a public service fails, it fails people with nowhere else to go. It is one reason government built deep disciplines. On a small team it is still the person who works on something every day who hears it first. They now also explain it to whoever built the page, in terms that get it fixed.
In their terms
We did not write anything down. There was no list of who had to approve what.
We had the same running order in front of us and played it through, each side able to follow the other. That is a shared mental model at work, and it cannot be handed out like a seat.
For a team, the move is to play it through together before anyone calls the whole thing. That is where our shared model came from: one running order, both sides reading from it.
For each of us, it is a habit. Bring your case in the unit the other side builds in. For the engineers that was the route. For a policy lead it might be the rule, and for a service owner the cost.
Asking a model to take you through their part first, the way I asked it to take me through the code, is the quickest way I know to learn that unit.
If you lead a profession, give your people the hours I found at night. Let them spend part of the working week learning the discipline next to their own, by asking a model to explain as they go. The meetings that follow will be shorter, and the decisions smaller and better.
The whole song
One step behind a sign-in. The guidance open to anyone who needed it. The plan went from one call for the whole service to a call on each part.
A few years ago I would have walked in braced to lose. This time I walked in knowing enough of the song to hear where it was going.
The conductor is not coming back. Learn the song.