Your company brain is only as good as the knowledge your people put into it.
Company brains are topical at the moment, and rightly so. Some organisations are buying one, some are building their own. Some are just starting to explore the concept. The platforms are getting genuinely good.
But the other half of it, the half that makes it work really well, is barely being talked about. We learned this once with data. It took years and it cost a fortune.
Analytics dashboards are everywhere now, and most teams are good with them. Someone opens one, sees what has moved, works out what is behind it, and takes that back into what the team does next. That is unremarkable today.
It took a while to get there, and not only on the technical side. The engineering was genuinely hard and took years to settle. But even once the pipes were sound and the numbers reconciled, a great deal of the reporting went unused, because reading a number well turns out to be a skill, and nobody had been taught it yet.
So organisations invested in that skill deliberately, over years, and after the fact.
Being able to look at a movement and say what is actually driving it. Knowing which comparison is fair and which one is flattering. Recognising when the metric that moved is not the metric that matters. Having enough confidence in your own reading of it to change what you were going to do on Monday. We settled on data literacy as the name for it, put real budget behind it, and nobody now argues that better dashboards would have made it unnecessary.
Both halves were needed. They did not arrive together. The technology went first, the capability came along years later in most places, and it was learned the hard way, after a good deal had been spent on reporting nobody was acting on.
Some organisations are still working through it.
I have been thinking about that sequence rather a lot lately, because the same purchase is happening again, one layer up.
The conversation at the moment runs that the AI is not delivering, that what it needs is context, and that context, somewhere along the way, becomes knowledge.
The tooling is remarkable, and I want to be clear that I mean that. Systems that read across email and meetings and documents and the CRM, that hold the shape of an organisation and keep it current, that track when something became true and when it quietly stopped being. Ask a question, get an answer, with sources attached. Five years ago that was a slide in a keynote. It is now something you can buy, and I am glad people are building it, because the work genuinely needs it. Anyone who has tried to do this properly by hand knows how little of it scales without machines.
But there is a difference between the two eras that makes this one harder, and it is worth being precise about it.
Data came from systems. A transaction was logged, a meter recorded, a form was submitted, and a pipeline carried it somewhere useful. Whether or not a single person in the business understood any of it, the material accumulated, because machines were making it. The build was technical, and the capability that had to be developed afterwards sat at the far end, with the people reading the output.
Knowledge (and context) is not produced that way. It is made by people, continuously, in the ordinary course of doing the work.
Somebody reasons through a problem and arrives at a conclusion. Somebody weighs two options and takes one for reasons that were sound at the time. Somebody discovers, on the third attempt, why the obvious approach does not work in this business. That is knowledge being created, all day, in every part of the organisation, and the overwhelming majority of it is nowhere a system could ever reach.
So the capability sits at the other end. Not with the person reading the output. With the person making the material in the first place.
It matters, too, that these systems are sold as knowledge and what they are mostly holding is information.
Information is what has been captured. Knowledge is information that someone has wrestled with, reached a position on, and put their name against, in a form the next person can rely on.
The distance between the two is not volume. It is an act, and a person performs it (hopefully the right person). Two versions of the same document sit on the drive and they contradict each other. Which one is right? If the honest answer is "whichever was edited last", nothing in the system knows anything about authority.
The instinct is to close the gap with better machinery, and the machinery really is good. These systems do not simply read. They graph: mapping the people, the projects, the decisions, drawing the links between them, holding it all in something that behaves like an understanding of the business and stays current while you sleep. It is genuinely impressive engineering, and it does largely what it says it does.
What it cannot do is link to something that was never put anywhere. Read the channels, read the inbox, read the transcripts, and you will catch the decision somebody happened to type out.
You will not catch the reasoning they never typed, the constraint everyone in the room already understood, the option that was dismissed in four seconds without anyone explaining why. None of it was expressed, so there is nothing to connect it to. And a graph with holes in it does not look like a graph with holes in it. It looks finished.
What it does find is not automatically right either, which is the part that ought to worry anyone accountable for direction.
Three channels are discussing the same topic, from different angles, over weeks. A way of doing things settles by repetition, and by the fortieth mention it has the texture of policy.
Ask who agreed it and there is no one. Ask whether anyone checked it against where the business is actually trying to go and nobody did, because there was never a moment when checking would have been the obvious thing to do.
A system reading those channels finds a strong, consistent, well-evidenced signal and hands it back as what the organisation does.
A team settling on an approach in a channel is not the organisation deciding anything. It might be the right call. It might quietly contradict a commitment made somewhere else. It might be a sensible local answer to a problem the strategy had deliberately chosen not to solve. Nobody in the thread would know, because the people who would know were not in the thread.
Feed that into a system that reads consistency as evidence, and you have not made the organisation better informed. You have made a course of action nobody authorised look thoroughly well-supported.
Frequency is not endorsement. Recency is not authority. Authority gets conferred, by someone, deliberately, and where nobody conferred it the confidence in the answer is borrowed from the sheer weight of the material rather than from anything a person decided.
The sensible response is to check it against strategy, and some of the tools are moving that way, which is the right instinct. Then you have to ask what the strategy is, as an object you could actually point a machine at.
In most organisations, if you go looking, you find a deck. Five bullets and a diagram, from an offsite eighteen months ago. The bullets are true in the way headlines are true. What is not in there is any of the reasoning. Why that market and not the adjacent one. What was on the table and got put back, and what made it the wrong call at the time. Which constraint turned the sensible option into the unavailable one. The trade-off everyone in the room understood perfectly and nobody wrote down, because at the time it was too obvious to be worth writing down.
An agreed approach and an agreed approach with its reasons attached are two different objects, and only the second one lets anybody work out whether a new decision belongs.
Including the roads not taken, and why they were not taken, because most of the decisions that quietly go wrong are the ones that wander back onto a road somebody already ruled out.
So the check runs, the answer comes back aligned, and it is aligned to five bullets rather than to the thinking that produced them. That is not a flaw in the tool. The tool compared against the only artefact anyone gave it. A system can reference what is there. It cannot reference what is not there.
None of this is an argument for buying less software. I would buy the tooling. I use it, most days. The organisations that get somewhere over the next few years will be running good systems, and the ones hanging back waiting for certainty will spend those years falling behind quietly.
The people building this seem to agree, which is the interesting part. The strongest platforms in the category are no longer selling the product on its own. They are assembling networks of consultancies and integrators around it, to help customers work out what it should be pointed at, who governs it, whether anyone trusts it, and how it gets used in the actual work. That is a vendor saying, in the politest form available, that the technology is necessary, and not sufficient on its own.
It is worth thinking about. While the tooling was poor, poor retrieval explained every disappointing answer, and there was always somewhere for the failure to sit. As it gets better, that explanation runs out.
What is left is the part no system was ever going to do for you: deciding what should be authoritative, what belongs where, what was worth keeping in the first place, who owns it, and how it stays true.
So the assumption worth watching is the buyer's, not the tool's.
The vendors are not claiming the technology is enough on its own.
The buyer often is: that the only thing the team was short of was the tool, and once it is in, the rest follows. It does not follow.
We built data literacy because the numbers arrived and reading them well had to be learned. What is needed now is its counterpart, and it is worth naming plainly.
Knowledge literacy, if you like: the ability to recognise what your organisation is learning, shape it into something another person can use, and know when it needs authority behind it before anyone acts on it.
Much of it comes down to a single practical question, asked often enough that it becomes habit.
What actually needs to be in there for this to work, and how do I get it in?
In practice it is unremarkable. Recognising when a conversation has produced something that ought to outlive the conversation. Writing the reason and not only the outcome. Knowing when a decision is yours to make and when it needs somebody else's name on it, and going to get that name rather than proceeding. Owning a page and meaning it. Reading something a colleague wrote and saying, plainly and in the open, that it is out of date. None of that is talent. It is practice, and it can be taught.
It is also lighter work than it sounds, because the tooling that raised the question helps considerably with the answer. Turning a decision and its reasoning into something another person can use is largely a drafting job now, and drafting is precisely what these machines are good at.
What they cannot do is notice that a decision was made, judge that it matters, or put a name to it. That part stays with people, and it is the part worth building.
The difference this time is that we already know how the story goes. With data, the capability got worked out afterwards, at cost, by organisations that had bought the technology first and then spent a few years wondering why the returns were so thin.
Nobody is obliged to do it in that order again. The capability can be developed while the systems are going in, which is cheaper than discovering the gap eighteen months into a deployment that was meant to have closed it, and a good deal less demoralising for everyone involved.
The dashboards did eventually earn their keep, and not because the dashboards got better. They earned it once enough people had been taught to read them and were trusted to act on what they saw. Unglamorous work, and it was the thing that made everything above it worth having.
We are at the same point again, a floor up, with far better machines and the same half still to build. The question is only whether we leave it as long this time.
Comments