Goal Beyond the Goal
By Nathan Waterhouse · 2026-11-05
The tool that got me through a four-year VAT audit had become so confusing that I could barely use it. Fixing it meant relearning a management lesson I had written about in January.
For three days I had been working on my expenses tool with Claude Code, and for three days not much had changed. I would complain to Claude Code that the interface was confusing, that there were too many pages and I didn't know where to start, that the important numbers didn't stand out. Claude Code would make changes. I would look at them, feel no better, and complain again in increasingly frustrated tones.
Then in a semi-out of body moment, I decided to tell Claude Code what my ultimate goal was from the tool: for me life to be admin-free: every bank transaction has a receipt and is coded in a way that complies with HMRC's rules, my books are up to date and accurate, I don't get audited again, and none of it takes much of my time.
What shocked me was Claude's reaction. It said this was a completely different brief. Three days of complaints had produced a series of small adjustments, and one paragraph of intent changed the direction of the whole piece of work. How could a single sentence change so much?
A lesson I had already written down
The slightly embarrassing part is that I wrote about exactly this in January. In What Managing Taught Me About AI I described treating agents the way I treated people as a junior manager, handing out tasks and staying busy because I was still doing all the thinking. "Make me an interview guide" is a task, I wrote, whereas "Ensure I'm ready for my interviews" is a goal. Nine months later I was back to giving instructions about page layouts.
The expenses tool isn't a toy. I have been building it bit by bit for about a year, and this year it got me through a pretty hard-core VAT audit. An HMRC algorithm had spotted an anomaly in my records, so HMRC went back four years, quarter by quarter, and every coffee and every train ticket had to be justified. The work was mammoth, and it arrived just as I was about to have heart surgery, so the tool did a huge amount of heavy lifting when I most needed it. Coming back to it afterwards, though, I found it hard to use, and its original purpose, to stop admin eating my time, had got lost under a year of additions. A couple of colleagues would like to use it, so I have been thinking about open-sourcing it, which raised the stakes: if I found it confusing, they certainly would.
Why I slipped back
Why did I forget that management lesson? Why did I slip back to complaining and tactical demands, rather than goal oriented instruction? My hunch is that frustration produces tasks, and psychologists described something very like it in the 1980s. Robin Vallacher and Daniel Wegner's action identification theory starts from the idea that any action can be described at different levels. "Moving the totals to the top of the page" and "never being caught out by HMRC again" describe the same piece of work. People prefer to think at the highest level they can, but when something keeps going wrong, they drop down to the mechanics to work out how to fix it.
When something keeps going wrong, we drop down to tactics to work out how to fix it.
That was my three days. Each time the dashboard annoyed me, I described the symptom in front of me, and Claude Code fixed exactly what I named. The pull downwards is automatic and strongest when you are stuck, which is why writing the lesson down in January didn't protect me.
Felix Rieseberg, an engineering manager at Anthropic, calls the way out "altitude" in his post How to be more ambitious: going up a level and asking what the goal beyond the goal is. He used to ask Claude to fix individual crashes, and eventually he asked it to keep his apps crash-free. "Make the dashboard less confusing" was my crash fix. "Make sure HMRC never catches me out again" is my crash-free app.
Goals for people, goals for agents
Experienced managers know all this, and most of us still slip under pressure. When a project is late, the instinct is to reach in and direct the details, which is exactly what I did with Claude Code. In Managing Models, Managing People I wondered whether the habits we form with AI leak back into how we manage people. My expenses tool suggests the leak runs the other way too.
The military has dealt with this for a long time. Under mission command, an order carries commander's intent, defined in US joint doctrine as "a clear and concise expression of the purpose of the operation and the military end state." Plans rarely survive contact with reality, and people who understand the purpose can adapt without waiting for new orders. My complaints were orders without intent. The paragraph I eventually wrote described the end state and left Claude Code to work out the route.
Changing behaviour: if x, do y
The open-source question keeps pulling me back to this. Had I shared the tool as it was, my colleagues would have inherited a year of my complaints, set in pages and buttons. "Every transaction has a receipt and is coded correctly for HMRC, and the books stay accurate without taking much of your time" makes sense to anyone running a small business, and it is what a new contributor, human or otherwise, would need to make good decisions about the code.
The habit I am trying to build is a small one, borrowed from Peter Gollwitzer's research on implementation intentions, which found that plans in the form "when X happens, I will do Y" are followed through more reliably than general resolutions. The obvious trigger is the frustration itself. When I notice I am about to describe a symptom for the third time, I stop and write the commander's intent: the goal beyond the goal, put as plainly as I would put it to a new colleague on their first day. It took me nine months to drift away from what I wrote in January, and I expect I will need reminding again.