Uninstall Capital
“Boomer” triggers me. I wrote The Second Stanford to understand why. That work is unfinished.
I am not coming to grips with my age very well. I want to participate in too much. I read the longevity updates.
I want the time.
The label lands right there. It places me in the past while I am trying to help make what comes next. Almost every day, I work with increasingly capable systems, follow what others are discovering, and imagine what we might attempt together. My expectations keep changing. So do the work and the outcomes.
I see frontier and specialized models collaborating in ways that could produce extraordinary discovery and invention. Some of what I want to do is only beginning to become imaginable. The possibilities keep drawing me further into the work.
And I intend to be part of it.
I cannot tell you exactly what my contribution will become. I can tell you what I am willing to put into it: my work, my judgment, my IP, and my bets. Some experiments may fail publicly. Some convictions may have to change. I intend for that contribution to count.
That appetite has me paying close attention to what we are implementing now. Some of what gets described as agentic looks to me like first-level automation with hilariously better tools. The tools deserve the enthusiasm. What we decide to build with them deserves close examination.
I expect many of these implementations to be reimagined as people gain experience and trust in the technology expands. Users will discover things they want to delegate that they cannot yet imagine, while the technology itself keeps changing.
Increasing trust could make us more demanding. As we learn what these systems can reliably do, we may ask for more than an early implementation was designed to support. We may want to entrust the technology with more, yet still decide a particular implementation needs to go.
At one point, our firm developed a practice to uninstall automation.
Stop here and imagine a CFO paying a snot-nosed consultant to uninstall a major technology investment they had just begun to depreciate. It’s okay to giggle a little. Not too loudly. We may find ourselves having that discussion again.
Clients grew so frustrated with automation downtime that they paid us to remove it and return to manual processes. There was still production to deliver. Taking the technology out meant rearranging the work and accepting the consequences. Someone had to make the transition work while the operation continued.
An earlier failure doesn’t determine what we should attempt now. Today’s capabilities deserve to be examined on their own terms. But that experience taught me something about the work left behind when an implementation became intolerable.
I expect some premature implementations will require what I call uninstall capital. The write-down is only part of it. Recognizing the lost value does not pay for changing course. There will still be work to do, people depending on it, and a transition to pay for.
I wonder how much of that is in the financial forecast.
People will also remember what they were promised and what they gave to make the implementation work. They may have learned new processes, carried extra work, or raised concerns that went unanswered. Removing the system does not settle those obligations. I think of that as cultural debt.
Leaders who withdraw automation and return promising intelligence will have to account for the earlier experience. What did people carry? What has actually changed? Why should they commit themselves again? Acknowledging what happened and supporting the transition can begin to rebuild trust. Expecting another round of enthusiasm without addressing it adds to the debt.
In No Single Midnight, I said I wanted to begin where a concern becomes somebody’s responsibility — and follow what happens when addressing it costs the organization something. An implementation that needs to change gives us a concrete place to begin. The investment has been made. People have committed their work and reputations to it. Then experience tells us something we would rather not hear.
Who can raise that concern, and who has the authority to act? What resources are available to keep the work going while the implementation changes? I would trust an organization more if it could answer those questions — and demonstrate its willingness and ability to act when doing so became expensive.
If changing course requires money nobody has provided, time nobody has allowed, and authority nobody can exercise, the person who hears the concern has inherited a problem they may be unable to address. Naming someone responsible does little for the person waiting for a response unless that responsibility comes with the means to act.
I want to build that capacity because I want to entrust these systems with consequential work. Doing so will require decisions about which failures we can safely learn from, what would require intervention, and who will make that call. We will need to revisit those decisions as we learn. A plan made before deployment cannot anticipate everything that experience will reveal.
Changing course might mean modifying an implementation, limiting its use, replacing it, or withdrawing it. Continuing may also be justified. The person responsible needs enough evidence, authority, and support to decide and carry it out. Otherwise, continuing can become the default simply because nobody has made another course practical.
We will also have to examine what happens beyond the immediate result. Who else is affected? Where does the work go, and who inherits the cost? A narrow success can be useful. It can also conceal a larger failure when we draw the boundary conveniently enough. People outside the operating arrangement may bear consequences they never agreed to accept. Their concerns must be able to change what we do.
That is where my enthusiasm becomes an obligation. I want to make these capabilities useful and dependable enough that people have good reasons to rely on them. I will have to examine the costs and consequences of things I want to succeed.
I cannot do that alone. I want collaborators committed to the work and willing to challenge it, who stay engaged when the evidence requires us to change course. I owe them the same. I’ll lead where I am best placed to lead and follow with loyalty where I can contribute more in support.
If you tell me we need to reconsider, I owe you a hearing even when I have money, pride, or months of work invested in continuing. You should be able to hold me to that.
Whatever your age, there is work here. Before committing to an implementation, ask what would make you reconsider, who has the authority to decide, and how the work will continue as things change. Include the people who will bear the consequences. Ask what previous implementations have already required of them and what remains unresolved. Then put resources behind the answers.
Bring what you know, be willing to learn what it cannot yet tell you, and put something you care about into the effort.
You can expect the same from me.
On process and disclosure: How I make this →