In this excerpt from Episode 14 of the Hi podcast, Jim hosts David Allen, author of the 2001 best seller, "Getting Things Done"; Marie Kondo, organizing guru whose KonMari method has spawned a best-selling book and popular Netflix show; and Hasso Plattner, the co-founder of enterprise software giant SAP, for a conversation about Hi's Harness OS. Full episode is 67 minutes; what follows is an excerpt. Jim has just finished walking through what Harness OS is and how it came to be.*


Before this...

Jim described what he calls Harness OS, the operating environment that Hi runs on. It's a plaintext vault as single source of truth, a 24x7 instance of Claude Code that processes inputs continuously, and Claude Cowork as virtual assistant, writer, coder, thought-partner, and more. This system is Hi's force multiplier, allowing Richard and Jim to manage a 2-person consultancy handling an opportunity pipeline, program design, a portfolio of products, live client sessions, marketing, the website and blog, in-house software projects, partnerships, finance, admin, and more, all with zero employees.


JIM: OK, so that's the tour. The system sweeps email, meeting notes, scratch files and more every fifteen minutes. The Guide, the vault of markdown files, is the single source of truth. Two Macs - one, called Hitchhiker, travels with me. The other one, Deep Thought, sits at home and never sleeps.

HASSO: The supercomputer.

JIM: The supercomputer.

HASSO: And it answers all the questions of life, the universe, and everything.

JIM: Eventually. We’re still running the multi-million-year compute on the "Ultimate Question." (laughter)

HASSO: You see, what is interesting to me is that on a laptop you can fit in a backpack, you have built what at SAP we would call a small enterprise system. There is ingestion. There is governance - your "tier one, tier two" file rules. There is a system of record. The vault. This is not a toy.

JIM: Coming from you, that means a lot.

HASSO: Now. Whether one Mac in your kitchen should be the system of record - that is a different conversation.

(laughter)

DAVID: Ha! That's the one I want to have.

HASSO: I am sure you do, David.

DAVID: Look, I've been doing this for forty years, and the thing I keep coming back to is this. The system you trust is the system that works. It doesn't matter if it's a Moleskine and a kitchen timer or twelve thousand lines of Python on a Mac that thinks it's named after a Douglas Adams character. If you trust it, your head can rest. If you don't, your head can't rest, and nothing else matters.

MARIE: May I ask a question?

JIM: Please.

MARIE: Jim, when you open your laptop in the morning, does it spark joy?

(silence, then laughter)

JIM: I knew this was coming. Honestly? It does. Most mornings.

MARIE: Most mornings.

JIM: Most mornings. There are days when the dashboard is a wall of red and I feel…

DAVID: Compressed.

JIM: Exactly. Compressed.

MARIE: Then perhaps the dashboard is keeping things that have already served their purpose.

JIM: That's the diagnosis.

MARIE: When something has served its purpose, we thank it, and we let it go. Even an open loop. Especially an open loop. If it has been waiting for three weeks and you have not closed it, perhaps it is asking you a different question. Perhaps the question is not "when will I do this," but "is this still mine?"

HASSO: This is the part where I disagree, gently.

MARIE: Please.

HASSO: I have spent fifty years building systems that remember everything. Every transaction. Every change. Every audit trail. Because when something goes wrong - and something always goes wrong - the question you ask is not "did this spark joy." The question is "what happened, and when, and who knew about it."

MARIE: Yes.

HASSO: So I would not so quickly let go of an open loop. I would put it in the archive. I would tag it. I would say, this is finished, but it is not gone.

MARIE: Hasso-san. Is your archive full?

HASSO: (pause) ...Yes.

MARIE: Has anyone looked at it?

HASSO: (longer pause) The auditors.

(laughter)

MARIE: I think we are saying the same thing, just in different rooms.

DAVID: That's exactly right. The point isn't whether you keep things or throw them out. The point is whether they're in your way. If something is in your archive and you don't think about it, it doesn't matter that it's there. If something is in your inbox and you do think about it, even when you don't want to, that's the problem. Get it out of the way. Either by archiving it or by doing it or by deciding it doesn't need doing. That's the whole game.

JIM: Which brings me back to this thing we've named Harness OS -

HASSO: A bold name, by the way.

JIM: A bold name.

DAVID: I noticed you didn't go with "Jim's File System."

(laughter)

JIM: No. Look, calling it Harness OS is somewhat grandiose, I know. There are five of us, including spouses and a mostly volunteer contractor, and one of us is an AI. We don't have a thousand engineers. But the name does something for me. It tells me what kind of thing this is supposed to be. It's not a folder. It's not a doc. It's the environment we work inside. So I'm not sure I'd un-name it, even though the name is arguably bigger than its content.

HASSO: The name is a goal post.

JIM: Right.

HASSO: This is good. At SAP, every system began as a goal post. SAP itself - "Systems, Applications, Products in data processing" - this is, you know, ambitious for a small company in Walldorf in 1972.

DAVID: I named my book "Getting Things Done." It could have been called "Some Things, Sometimes." But nobody buys "Some Things, Sometimes."

(laughter)

MARIE: I think the name is appropriate. To harness is gentle. You do not break the horse. You direct it. The intelligence, the people, the work - it is already moving. You are guiding.

JIM: That's nice.

MARIE: Thank you.

DAVID: Now I'm jealous. I want you all to be talking about my system this way.

JIM: Want to do an episode?

DAVID: Already there.

JIM: Let me ask you something specific. We have this thing we call "documentation hooks." Right after a decision or a status change, not at the end of the day, we capture it. Right then. Inline. In the Guide.

DAVID: That's the two-minute rule with a different sweater.

JIM: Is it?

DAVID: If it'll take less than two minutes, do it now. Two minutes is the friction line. Past two minutes, your head starts negotiating. Below two minutes, you just do it and it's done. You're applying that rule to documentation, which, frankly, most people don't think to do.

HASSO: And from my side, this is just real-time data. We have a name for the alternative. We call it "batch." Batch is what you do because real-time is too expensive. If real-time is free, you do real-time. There is no virtue in batch.

MARIE: And you do not have to remember to clean up at the end of the day.

JIM: No.

MARIE: Because there is nothing to clean up.

JIM: Because there is nothing to clean up.

MARIE: This is the most important sentence on the show today.

JIM: I'll cut that and put it on a t-shirt.

HASSO: Please send me one.

(laughter)

JIM: OK, one more before we go to break. The grandiose part of this, the slightly Promethean part - we built it, in large part, with Claude. The AI is not a feature. It's a co-author of the system. Some of these skill files were written by Claude reading my own behavior and proposing improvements. Does that change what you're hearing?

DAVID: (long pause) For me, no. The principles don't care who writes them. They work or they don't. If Claude is helping you stay clean and clear, Claude is doing the same thing a good assistant has always done. The skill is in the relationship, not the silicon.

HASSO: I will give you the engineer's answer. The architecture is interesting because the loop is short. You write a behavior. Claude observes. Claude proposes. You adopt or reject. This is the development loop SAP would have killed for in 1990. Now you have it on a Mac in your kitchen.

JIM: Is that good or bad?

HASSO: It is mostly good. The risk, you know it. The risk is that the system becomes complicated faster than you can understand it. Then one day Claude proposes something, you accept, and you do not realize what you have agreed to.

MARIE: May I -

HASSO: Please.

MARIE: I do not know the technical part. But I will say that when I work with a client, I am not trying to make their home look like my home. I am trying to help them see their own home more clearly. If Claude helps Jim see his own work more clearly, that is good. If Claude is making Jim's work look like Claude's work, that is not good. Only Jim can know which is happening.

JIM: That's a useful test.

MARIE: Hold the system in your hands. Does it still feel like yours?

JIM: Most days, yes.

MARIE: Most days.

(laughter)

JIM: OK, we're going to take a break. When we come back I want to talk about Richard, my partner. Because everything I've described works for one person, and we're about to find out whether it works for two. David, I have a feeling you're going to enjoy this section.

DAVID: I came specifically for it.


  • This episode is, of course, fictional. Hi doesn’t have a podcast (yet). None of these distinguished guests have heard of Harness Intelligence (yet). But the system they’re discussing is very real, and it’s how a two-person company is running like a small enterprise.

← Back to Insights