Deprivation

That was the name of the route. It was the centerpiece of a slideshow that captured my attention when I was deep in my climbing years and in the middle of a math major in college in the mid-1990s. The climbers were Mark Twight and Scott Backes. The route was Deprivation, a new line on the north buttress of Mount Hunter in Alaska. They climbed it in 1994 in a 72-hour round trip, including a 41-hour continuous climbing period.

What fascinated me wasn't simply that they climbed something extraordinarily difficult. It was how they chose to do it. The dominant image I had grown up with of expedition mountaineering was siege tactics. Establish a base camp. Carry equipment higher. Establish another camp. Fix ropes. Move supplies. Retreat. Rest. Move higher again. It was methodical, deliberate, and built around creating infrastructure on the mountain.

Twight and Backes came from a very different school of thought. They stripped away almost everything they could. Their packs, excluding ropes and climbing hardware, weighed less than thirty pounds. They carried only what they believed they needed to move extraordinarily fast and survive the consequences of doing so. The route's name wasn't metaphorical. They accepted deprivation as part of the system.

Thirty-two years later, that memory surfaced unexpectedly while I was talking with an intern at the Center for Rural AI about organizational memory. We weren't talking about mountains. We were talking about the tension between delivery and durability.

The short-order cook

Every young organization has reasons to move fast. A customer has a problem. We can solve it. Another customer wants something slightly different. We build that too. Someone sees what we've done and asks whether we could do it for them. Absolutely.

There is something intoxicating about this stage of an organization, and artificial intelligence has poured gasoline on it. A capable person with modern AI tools can prototype in hours what might once have required weeks of requirements gathering, development, testing, and deployment. The feedback loop has become extraordinarily short: problem, build, deliver, learn, repeat.

I've described one version of this as the short-order cook. The order comes across the counter and we sling out exactly what the customer wants, as quickly as we can make it. If we're good at it, people start talking. Customers arrive. Revenue follows. A reputation begins to form. There is absolutely nothing wrong with this. In fact, at the beginning, it may be exactly what an organization needs.

The problem appears when there are no recipes. Customer number two is easy. Customer number ten is harder. By customer twenty, nobody remembers why one implementation works differently from another. Decisions live in someone's head. Customer requirements are buried in meeting notes. A field exists in a database because someone needed it six months ago, but nobody remembers who or why. Then the original builder gets busy, leaves the organization, or simply forgets.

The thing that made us successful, our ability to move incredibly quickly, begins working against us. Delivery without durability eventually becomes fragility.

The expedition at the other extreme

There is another way to fail. Before serving the first customer, we decide to make sure everything will scale. Every form gets filled out in triplicate. We establish governance, metadata standards, architecture, documentation requirements, intake processes, approval gates, development standards, naming conventions, and change controls.

Base Camp. Camp I. Camp II. Fixed ropes. Supply caches. We haven't climbed anything yet, but we have built an extraordinary infrastructure for climbing.

I spent enough of my career in large organizations to understand why these structures exist. Most of them were created in response to something that actually went wrong. Durability matters. But applied too early, durability has its own failure mode.

The beautifully governed solution never leaves the building. The customer went somewhere else. The opportunity passed. The team exhausted itself designing infrastructure around a need that hadn't even been proven.

The system may have been scalable. Unfortunately, there was nothing to scale.

Carry what keeps you alive

This is where my memory of Deprivation became interesting again. Twight and Backes weren't reckless because they traveled light. They were making deliberate decisions about what they could remove.

Their system depended upon speed. Less equipment meant less weight. Less weight meant faster movement. Faster movement meant less time exposed to the objective hazards of the mountain. Speed itself became part of the safety system.

But they didn't carry nothing. They carried the equipment they believed they needed to survive, climb, and, up to a point, retreat. That distinction matters.

The lesson isn't to go fast instead of building something durable. It is to carry exactly enough durability to survive the speed you intend to travel.

Carry exactly enough durability to survive the speed you intend to travel.

I think that's an important distinction for organizations entering the AI era.

Architecture should be earned

One of the principles that has emerged from my own experiments building with AI is simple: match complexity to demonstrated demand. Don't build a large system for a need that is still being tested.

If one customer needs something, solve it for one customer. Run it by hand. Watch what happens. Learn where it breaks. If the second customer needs something similar, pay attention.

By the fifth customer, perhaps a pattern has emerged that deserves standardization. By the twentieth, configuration may need to separate from code. Customer-specific decisions may need durable records. Monitoring may become essential. Deployment probably shouldn't depend upon one person remembering how everything works.

Each of those structures may eventually be necessary. But they should enter the pack because the terrain demonstrated that they were necessary, not because someone imagined every possible mountain before leaving the parking lot.

Documentation and architecture should follow evidence. Not precede it.

Memory may be what allows us to keep moving fast

That brings me back to the conversation that started all of this. We were talking about organizational memory.

At first glance, memory sounds like durability infrastructure. Another database. Another governance exercise. Another thing the fast-moving people have to maintain while they're trying to get actual work done. Done poorly, that's exactly what it will become.

But I am beginning to wonder whether organizational memory could serve a very different purpose. Memory may be what allows an organization to continue moving fast without becoming fragile.

Imagine that the organization doesn't need everyone to stop and document everything. Instead, the important pieces of the journey are preserved as part of doing the work. Why did we make this decision? What did this customer teach us? What failed? What changed? What did we promise? Which assumptions turned out to be wrong? Where did this solution come from? What would another person need to know before changing it?

Not everything deserves to be remembered. That's as dangerous as remembering nothing. But some things are extraordinarily expensive to lose. Those are the things we need to identify and preserve.

AI changes the weight of the pack

There is another reason I think this question matters now. Historically, durability was heavy. Documentation took time. Governance required meetings. Institutional knowledge had to be manually captured, organized, maintained, and retrieved. Every additional control increased the organizational weight being carried up the mountain.

AI has the potential to change that equation. Meetings can be captured. Decisions can be extracted. Code changes can retain context. Customer conversations can enrich organizational knowledge. Lessons from one project can become discoverable during another. Some of the weight that humans previously had to carry themselves can potentially be carried by the system.

But there is a trap here too. AI doesn't just make it cheaper to preserve useful structure. It makes it incredibly cheap to create unnecessary structure.

More documentation. More metadata. More agents. More workflows. More automation. More governance. More everything.

We can now construct Base Camp, Camp I, Camp II, and Camp III before we've even determined whether the mountain is worth climbing.

The ability to build something cheaply doesn't make it necessary. Sometimes it just makes the wrong decision cheaper to make.

Delivery and durability

I don't think there is a perfect balance between delivery and durability. Balance suggests there is some point in the middle where the pendulum eventually stops. I don't think organizations work that way. The terrain keeps changing.

There will be moments when the opportunity requires an extraordinarily fast push. There will be moments when the organization needs to stop, look behind itself, and make sure the route it just established can actually be traveled again.

The skill isn't finding the midpoint. It's recognizing which terrain you're standing in.

Move fast enough to discover what deserves to endure. Build enough durability that you survive long enough to discover it. And before putting one more thing in the pack, ask why you're carrying it.

Deprivation was never about carrying nothing. It was about understanding what could be left behind.