Raw dictation: concepts and metaphors for how we organise work (2026-10-15)

Dictation from Rufus, given live to the team on 15 October 2026, lightly tidied (filler, repeated words and transcription slips removed; wording otherwise kept). Source for the concepts guide, Post-its and filing cabinets on Way Into AI, with the Life Itself part in guides/our-office.md (beads lip-d4l.6, lip-d4l.8). Skeleton: concepts guide skeleton.

Part 1: post-its, documents, rooms and filing cabinets

I think we need a guide that explains some concepts in advance, about our project management system and even the idea of git and things like that. And I think we need to order our guides a little more. To start with, I want to go through some metaphors with everyone here.

First, we want to think of two kinds of material that we have. We want to think of post-its. People know post-it notes: these little square coloured pieces of paper that are not very big. Does everyone know that? And then you could think of big documents, legal documents on A4 or something like that. These are the two kinds of information we generally have: document material and post-its.

By the document material, I mean reference information. Reference information is our insurance contract, or a guide or instructions to do something, or even a project plan. The post-its are like tasks. The good thing about that metaphor is that post-its are small, and tasks in general are quite small. They might be chained together. You might have a post-it at the top, a master post-it that says "I am the epic", and below it, you can even stick them on the wall, there are sub-post-its to that post-it and even sub-sub-post-its. There's a structure to tasks. But in general any given task is quite small. And then we have these documents. So that's the first metaphor I want us to have in mind, and almost draw visually.

The other thing we want to think about is that we have filing cabinets and rooms. Imagine we're working in an office together, and there are different departments. We could debate how these departments are broken up, but roughly there's maybe a department for content work, a department for operations, a department for whatever. Those might be nested. Maybe you have a room which is just for the podcast: there's a department and a room for the Media House, but there's even a sub-room because the podcast has its own thing. We could debate exactly how these are nested, and there's some question about that. But the idea is that we organise what we're up to by initiatives or sub-initiatives.

Then we have filing cabinets in those rooms that we file our paper in, and potentially even our post-it notes. Post-it notes are more likely to go on a board on the wall, so the filing cabinet is more for the paper. We've all seen filing cabinets. I know we're going to get to a world soon where no one growing up has seen a filing cabinet, but we know from the old days there were these things you put paper in.

One debate we could have in our organisation is: where are the filing cabinets? Do we put all the filing cabinets in the CEO's office, because the CEO, or whoever the managers are, want to be able to see all the different projects we've filed? Each project gets a little entry, a little folder in the filing cabinet: think of a manila folder. Management want to see all the projects we're doing, so one idea could be to put all the filing cabinets in the one office. That means if you're working in the podcast department, you have to walk over to the manager's office whenever you need paper. That's kind of annoying. So you probably want the filing cabinets in the room where you're actually working. If you're in the podcast department, you have the podcast filing cabinet, with all its information, in the podcast room.

But there's a problem for management, who want to know what the projects are. We don't want a duplicate of the files, because then they go out of sync: before you know it, Rufus has updated something about the podcast project, Amanda has also updated it in her office, and they're out of sync. This is a classic problem in an organisation. I do need to know about the projects that exist. So what we might do is that in Rufus's office there's a stub: a folder with only one piece of paper, which says there is a project called Podcasts Autumn 2026, but all the information about it is over in Amanda's office. So I know it exists, I've got an entry, and I know where to go and look. Such a thing is called a pointer file: a file that doesn't hold any information itself. It simply notes the existence of, for example, a project, and says where to go and look for its contents. And meanwhile each office also has a big sticky chart or corkboard on the wall, where they stick all their sticky notes and organise their plan of work.

To finish this analogy (it's not always perfect): per project, you have a manila folder, a place where you hold all your notes together. That folder may even say where to look for the stickies related to this project. Because a project normally has two things. It has important reference documents, like the plan you came up with, a description of the purpose of the project, who's in charge of it, and other information you might need. And it has some tasks: sticky notes. You don't want to put the sticky notes in the manila folder, because you can't see them easily, you can't move them around on the board, and they'll get messed up. So the sticky notes are normally somewhere else, and you'll probably have a pointer in the manila folder saying "if you want the sticky notes, they're on the top left of the board", or wherever they are.

You can always add new levels of hierarchy. You might say our organisation is so complicated, or the podcast department doesn't need one filing cabinet, it needs three: "we've got so many projects, we're running three podcasts now, so we need a filing cabinet for each podcast". You can always imagine new levels, where you've created a whole room inside a room to hold new things. You can add intermediate levels to this hierarchy of filing cabinets. But very crudely, this is the level of nesting I'm describing.

Part 2: the digital version, and git

Then we need to make these things real, virtually. I've given physical examples, but the obvious virtual equivalent is a folder in Drive. There's a folder for the project, literally a folder, and probably a parent folder that's more like the filing cabinet. You've probably all done this on your disk: for example, you just created a Life Itself folder on your disk that will hold all the repositories you clone from the Life Itself organisation. This is a common nesting structure: one level per project, and something above it. We're all familiar with it.

Whether you're doing it in Google Drive, on your hard disk, or in git on GitHub, you just want to work out the mapping. On GitHub, what we call a repo is roughly like a filing cabinet. A repo, like a filing cabinet, can hold as much file system as you want. Just as with a Google Drive folder: if I said this Google Drive folder is the filing cabinet for the podcast, you could have as much nesting of folders as you like. I'm not going to limit you to one level of manila folders. But a filing cabinet has some conveniences: it's one thing, you can take it around. Similarly, we create git repos for something that looks like either an initiative or an area. We have one repo for planning, and it corresponds to what sits in the management office at the moment. It contains a list of projects: it has a folder called projects and a folder called initiatives. And then we have one for podcasts, and so on. So roughly a repo corresponds to either an area or an initiative.

Often what happens is that you start off with one repo for an area, say all of the Media House, and at some point you say the podcast has got so big that I want to put it in its own thing. Mainly because it's convenient: it's got bulky, it takes a long time to search through, there are so many manila folders in there that it's painful to find things. That's true for AI too: if there's a folder with a lot in it, it's hard to search through everything and find what you want quickly. And there are other conveniences: our task tracking roughly maps to our repositories, so if I have loads of tasks across everything, it's bewildering.

So when I say git repo, map it in your head to this kind of filing cabinet. Inside it is a file system. A git repo is just a way to move file systems around. You could put any kind of document in a git repo. It's most convenient to put text files, sometimes other kinds of files, because git was designed for text files, for reasons to do with how it was developed. But that's a detail for now. We're using git because it's good for AI and it's a good way to synchronise and collaborate: it's good at synchronising things back and forth between two places.

Git also provides a change log, so you can go back in time. Most changes are committed. And it's not just changes to an individual file: you can commit a whole bunch of changes in bulk. Say you're renaming a file, and lots of other files refer to it. If you can only make and commit changes one at a time, you make a change that breaks something: you rename the file, all the links are broken, and then you fix the links one by one. With git, you change everything and then say this is one change, one atomic change, so when you move through the history of your system it's consistent. But this is getting into the detail of git.

What you're looking for in any filing cabinet and folder system is: versioning, so we can go back and forth; easy synchronisation; and knowing who made which changes. It used to be that we also wanted a good UI. That's why we like Google Docs. But now with AI we don't care as much about the UI. We'll come to that. So when we say clone a repo, we're cloning a filing cabinet onto our machine, and it tends to correspond to one of our initiatives or areas. And what's then cool is you can go into it and ask.

Part 3: the drafting table and the filing cabinet, and why AI needs the cabinet

(Second dictation, same day. It picks up mid-thought from an example of asking the AI to save something.)

…and say: "turn this into Markdown, put it in the planning repo, in such and such a folder", so that it stays stored in the correct place.

If I were to go to an analogy, there's a question about collaboration and developing work, particularly documents. Say you and I are writing a contract, or an important planning document. We might get our Sharpies out, all kinds of paper on the table, and we'd sketch and write and discuss things. At that moment we want a system that's as supportive as possible, in whatever way helps us collaborate and create. At the end of that process we want somewhere where the result is recorded: the contract is drafted, or the plan of work is done. We may still take it out again and adjust it, but it's recorded.

Whatever system we use to represent our filing cabinets and our paper, whether our individual papers are Google Docs or Markdown files doesn't matter so much. The point is that there's a difference between the moment when we're creating and doing all kinds of stuff, and the moment when we have a polished document. That's what's most important.

I'm also suggesting that if we adopt Markdown files in git, that is the place where the polished documents go. What you use for the brainstorming and creation is up to you. If you love Google Docs and it lets you collaborate in real time, that's great. In my own experience, there are options for collaborating in real time in Markdown, but they're not as good as Google Docs. If I'm writing a long essay, I might start in Markdown, but at some point I want to collaborate with someone and I might move it into a Google Doc. But I've more and more got a tendency, even if something isn't final, to move it into Markdown, because then I have a commit. For example, with Rosie, I'm writing a white paper. I get a draft and commit it to Markdown. It goes back into Google Docs, we work on it some more, and I move it back into Markdown. I'm not prescribing this flow. What I'm saying is that overall you can work however helps you create material. What's important is that we agree that checkpoints of that work, even if not totally finished, get saved.

The reason for that is twofold. One is that we know where to go and look. The other is that even in the intermediate time, if things are in our regular filing cabinets, especially when we're working with AI, the AI knows where to look. We're working on a new project and say "oh yes, I've got that half-finished draft, I can reference that". We know where to find things. And that's a key point about AI: AI needs context.

[Someone leaves the call.]

To finish up with the two of you: this material is so helpful because it provides context. Whenever we start an AI session, remember, the AI starts clean. It starts as if there was no yesterday. People are building systems to improve that, called memory and so on, but essentially, and in a good way, an AI session starts clean. It doesn't know anything. That's why in Claude you often want to start by giving it a repo: in the repo it already knows where to look, rather than looking all over your hard disk. You start with a folder of your work.

One more thing to finish. In the repo there is a file called AGENTS.md, which you never need to read yourself. It's the equivalent of a README, but for AI. AGENTS.md is what the AI reads when it's booting up, and it's what we often update so that the AI knows where to look. For example, it knows that projects go in projects/; otherwise how would the AI know that? It would have to figure it out every time. It knows initiatives go in initiatives/. It knows there are recipes, called skills (we'll come to those): recipes for how we do certain things. We have a recipe for how we create a plan, a recipe for how we create tasks, and so on. Those are called skills, and the AI has a place to look for them. And we have other documentation, for example about what metadata we add to a project: where do we list the owner of a project, where do we say when it's due, all these kinds of things.

We've done a lot today, and particularly Amanda and Asdra, you don't need to remember all of it. Don't worry, this will be written up and we're going to practise it several times. But I think what will stick with you is visualising the filing cabinets, the pieces of paper and so on, and even recipe books on the wall: templates, if you like, or rules, or recipes for how we organise our filing cabinets.