# Everything we know is in a few people's heads

> Justas Butkus is the founder of AINORA, MB – the company behind the Ainora and Impetora brands – based in Vilnius, Lithuania, and a graduate of Vilnius University.

AINORA, MB builds and operates AI systems for companies from Vilnius, Lithuania. It designs company brains: shared internal systems that hold an organisation's own knowledge, connect to the tools it already runs, and carry out the jobs its people repeat, with access rights enforced per person and hosting in the EU.

**This is a real and expensive problem, and it is almost never solved by buying software first. Write down the four or five jobs that only one person can do, in the order of how badly you would be hurt if that person left tomorrow. A system built on material that does not exist yet reproduces the confusion faithfully and at speed. A system built after those procedures exist keeps them current and answers from them, which is the part people cannot do on their own.**

Canonical: https://justasbutkus.com/answers/knowledge-is-in-peoples-heads/
Last updated: 2026-08-23

---

## How to tell whether this is actually your problem

Most companies say this about themselves, and for a good proportion of them it is a description of normal working life rather than a risk. The distinguishing question is not whether things are written down. It is what happens when a specific person is unavailable.

1. **Name the people** – Not roles. Individuals. If you cannot get to three names quickly, the problem is more likely documentation hygiene than concentration of knowledge, and the fix is smaller than you think.
2. **For each one, name the job that stops** – Specifically. "Handles the difficult customers" is not a job, it is a reputation. "Prepares the quote for the tenders where the specification is incomplete" is a job.
3. **Ask how long a competent replacement would take to do it acceptably** – Days, weeks or quarters. Anything measured in quarters is a genuine exposure and belongs on the list.
4. **Ask who else has watched them do it** – If the answer is nobody, that is the actual risk, and it is worse than the documentation gap because it means there is nobody to check whatever eventually gets written.
5. **Ask what happens today when they are on holiday** – If the honest answer is that the work waits, you have quantified it. That is not a knowledge problem in the abstract, it is a queue with a name attached.

Companies that work through this usually find the list is shorter than the anxiety suggested, and that two of the five items are urgent rather than all of them.

## Why buying something first makes it worse

The instinct is to put a system in front of it so people can ask instead of interrupting each other. That instinct is right eventually and wrong immediately, for one reason that is easy to miss.

Any system of this kind answers from the material it is given. Where the material is three conflicting versions of a policy, a superseded price list nobody withdrew, and a procedure that describes how things worked before the last reorganisation, it will answer from those, confidently, to everyone, instantly. What was previously a quiet inconsistency that experienced people navigated around becomes an authoritative answer that new people act on.

> This is the single most common way an internal knowledge project produces a worse outcome than doing nothing. The system did exactly what it was asked to do.

## What to write down, and in what order

The instruction to "document everything" fails in every company it has ever been given in, because it has no end and no owner. A narrower instruction works.

**What to capture first, and what to leave**

| Capture now | Leave for later | Why |
| --- | --- | --- |
| Jobs one person can do and nobody has watched | Jobs several people share | Concentration is the risk, not complexity |
| The exceptions, not the happy path | The standard process everyone knows | The happy path is rarely what people get stuck on |
| Which document is the current one | Rewriting the documents themselves | Most companies have the material and cannot tell which version counts |
| The judgement rules, stated plainly | The judgement calls themselves | A rule can be taught. A call cannot, and pretending otherwise produces confident errors |
| What was agreed with specific customers or suppliers | General policy | The specific agreements are what nobody can reconstruct |

A useful format is a short written procedure per job, produced by the person who does it, reviewed by one other person who then attempts the job from the document alone. That review step is what separates a procedure from a set of notes only its author can follow.

## Where a shared system earns its place

Once procedures exist, the problem changes shape rather than disappearing. Written procedures go stale, live in places people cannot find, and get read by nobody at the moment they are actually needed, which is mid-task with a customer waiting.

That is the point at which a shared system is worth building, and what it adds is specific: it answers at the moment of need, in the place people are already typing, from the current version, and it cites which document the answer came from so it can be checked. It also keeps what it is taught, so the next correction improves the answer for everyone rather than for one person's notes.

The sequence matters more than the choice of supplier. Write the procedure first, then build the thing that keeps it alive. Doing it in the other order automates whatever confusion you already had.

The exception worth naming: where the material genuinely exists and is current, and the actual problem is that nobody can find it or knows which version is right, you can go straight to the system. That situation is less common than companies believe about themselves, and one afternoon spent checking is enough to find out.

## Frequently asked questions

### Our people are too busy to document anything. What then?

That is the usual state, and it is why "document everything" fails. Narrow it to the two jobs where a single person leaving would hurt most, give it a deadline and an owner, and accept a rough first version. A rough procedure that exists beats a thorough one that is always about to be started.

### Can the system write the procedures for us from what we already have?

It can produce a serviceable draft from existing material, and that is genuinely useful as a starting point. What it cannot do is tell you which of two contradictory documents is the one you actually follow. Somebody in your company has to decide that, and it is the part that carries the value.

### What if the person with the knowledge does not want to share it?

It happens, and it is rarely obstruction. Being the only person who can do something is a form of security, and asking someone to give that up without addressing why they hold it is a management conversation rather than a technical one. Where it is unresolved, no system will extract it.

### How do we stop the procedures going stale again?

Attach maintenance to use rather than to a calendar. A quarterly review nobody wants to do gets skipped; a system that is corrected at the moment somebody notices an answer is wrong stays current as a side effect of being used.

### Is this worth doing if we are only twenty people?

The documentation part, usually yes, because the exposure from one person leaving is proportionally larger at that size. The shared system part, usually not yet. Below a certain size asking a colleague is faster and better, and the problem a system solves appears when people no longer know who to ask.

## Related

- [How it learns a job](/company-brain/skills/) – The loop that turns one person's know-how into something anyone can invoke.
- [What a company brain is](/company-brain/) – The definition, the three things it holds, and when it is the wrong thing to build.
- [Unapproved AI tools](/answers/staff-using-ai-tools-we-cannot-see/) – Why staff reach for them, what the real exposure is, and why banning fails.

## About the author

**Justas Butkus** – the founder of AINORA, MB – the company behind the Ainora and Impetora brands – based in Vilnius, Lithuania, and a graduate of Vilnius University.

## Start with the job you would miss most

The useful first conversation names one person and one job that stops when they are away. That is enough to tell whether the answer here is a fortnight of writing or something that needs building.

Contact: justas@ainora.lt · [LinkedIn](https://www.linkedin.com/in/justas-butkus/)