The tool worked until everyone saw what else it could become.
Picture a hypothetical team meeting. Your small internal tool lists the tasks waiting for a decision. It shows what is stuck, who can unstick it, and a link to the relevant project record. Someone already owns it. The team actually uses it.
Then the suggestions start.
“Can it also hold all the project notes?”
A calendar would be handy. A weekly summary would be nice. Could the notes get turned into that summary automatically?
The builder says each change looks manageable. You are the leader who pushed for this tool in the first place. You want the team to keep finding useful ways to improve it.
So you say yes to the notes.
You have approved another place to write things down. You have not yet asked whether that makes a stuck decision any easier to make.
The easy part just got your approval
In an August 19 essay, Simon Willison draws a distinction that matters here: generating software faster does not give people an equal increase in their ability to understand and maintain it. When additions get easier, the discipline to keep a tool making sense has to come from somewhere else.
Here’s the thing. In your business, some of that discipline belongs to the person saying yes.
The builder can tell you how the notes might work. The person running the team has to decide whether keeping them there serves the team.
“It would be nice to have everything together.”
Nice for whom, doing what?
If you are opening the tool to find a decision you owe someone, the useful result might be a short list you can act on before the next meeting. Adding every project conversation could help you understand a difficult item. It could also bury the decision under material you already keep somewhere else.
Those are different outcomes from the same apparently helpful request.
Cheap to build is not a reason to add it.
What is supposed to come out of this thing?
If you worked through the piece about the wish on your shelf, you already did the work of turning an unmet need into a small, useful tool. This is the next conversation, after the first version works.
You need to protect the job it earned its place by doing.
There is a useful ingredient in The Professional Recipe called Format. It describes the finished work and the shape it needs to take. Think of a recipe that shows the finished plate, so the cook knows what the meal is supposed to be.
For our imaginary tool, that finished work is a decision list. Each item tells the leader what is waiting, who needs the answer, and where to find the information behind it.
That gives you something concrete to judge an addition against.
Would a short explanation of why each item is stuck improve that list? Quite possibly. Would a second copy of every project note improve it? We have not established that.
Right?
You cannot judge both requests by the enthusiasm in the room. One may sharpen the work the tool produces. The other may quietly give it a second job.
That second job might be worth doing. It deserves its own reason.
Follow the notes past the demonstration
Stay with the proposed notes feature. In the demonstration, someone types a note, it appears beside the task, and everyone can see how convenient that would be.
Now carry it into an ordinary working day.
A project lead changes the next step in the existing project record. Someone else adds a clarification inside the decision tool. By the afternoon, the two records say slightly different things.
“Which copy am I supposed to trust?”
The new notes field does not answer that. You need a rule, and someone needs to keep the rule working.
Maybe the project lead copies important updates into both places. That is more work every time the situation changes. Maybe the tool pulls notes from the existing record. Then someone has to check what happens when that connection misses an update. Neither approach is automatically wrong. Both come with a job attached.
Yeah. The feature has an afterlife.
This is where the original request gets interesting. Ask the person requesting notes what they were trying to do when they felt the gap.
Suppose the answer is that opening the project record does not tell them which paragraph explains the hold-up. They spend time looking for the reason a task is waiting.
Now you have a different problem to solve.
Perhaps each waiting item needs a brief explanation and a link to the exact note supporting it. Perhaps the current links simply need to point somewhere more useful. You can investigate that without deciding to move the whole project record.
The person asking for the feature may have named the first solution they could picture. Your job is to hear the difficulty underneath it.
And the upkeep cannot belong to “the team.” Someone has to accept it with enough room in their working day to do it. If the answer is the person who already updates the project record, ask that person what they would now have to do twice.
It is literally another place to check until you prove otherwise.
Add it, replace something, or leave it for now
You have three reasonable ways forward with this one request.
Add it because it makes the existing job easier. Maybe a short explanation beside each waiting item solves the actual problem. Keep the main project notes where they are. Name who keeps that explanation current, and check whether the decision-maker can now understand the hold-up without hunting through the record.
The extra field earns its place through what it helps someone do. It does not need to remove a field somewhere else to qualify. Sometimes a small amount of additional work is worth a clear improvement.
Replace an existing step. Maybe this discussion reveals that the team prepares a separate decision summary before every meeting. The tool could produce the same useful summary, and the team could stop preparing the separate version after the replacement has been checked.
That is a possible replacement to examine. It is not permission to delete a record people still need. Be explicit about which step would end, who uses its output, and how you will know the replacement covers that need.
Defer it because the reason is not clear enough yet. The proposed notes area may sound useful while solving no difficulty anyone can describe. Keep the request with the reason for deferring it and name what would bring it back for a decision. For example, repeated cases where a leader cannot find the information needed to answer a waiting item.
“Not yet.”
That is a complete management decision when it has a reason attached.
Does that make sense? Restraint does not mean every idea dies. It means an addition has to survive a conversation about the work it changes.
The person who can build it cannot make this call alone
Here’s the thing. If you celebrate every addition and never ask about its upkeep, you teach the builder what gets rewarded.
More visible features. More impressive demonstrations. A longer list at the next meeting.
Then the person using the tool has to work around all that generosity.
I would change the question you ask when someone shows you an improvement. Ask them to walk you through the same ordinary task before and after the proposed change. In this case, finding a waiting decision, understanding it, and giving the answer.
Where did the work get easier? Where did a new obligation appear? Who has agreed to carry it?
You are slowing the builder down. Let me be more precise. You are giving the builder a decision they cannot responsibly make for the person who lives with the result.
“I can build that” answers whether a change is possible. The leader still owes the team a reason to live with it.
Your Monday Move: decide one addition
Pick one proposed change to an internal tool that already works. Take the request to the person doing the work and the person responsible for keeping the tool useful.
Write the tool’s current job in one sentence. Then write what this addition improves for the person doing that job. List the new information, checking, or upkeep it would create, with a name beside each responsibility. Ask whether an existing step could end. If nothing ends, explain why the extra burden is still worth accepting.
Record one decision: add, replace, or defer. Include the reason and the owner. That decision is the output of this exercise. You do not need to build anything, buy anything, or change anyone’s access to complete it.
For a change you later implement, set a review point after the team has used it on ordinary work. Revisit the original job and the burden you expected. Did the decision become easier? Did the extra upkeep land where you said it would? Revise the decision if the evidence disagrees with the pitch.
Your team does not need you to personally design every button. It needs you to care what the whole tool asks of the people using it.
Keep the ideas coming. Make each one earn the yes.
Translated from Simon Willison, “Conceptual integrity and counting lines of code,” August 19, 2026.
