The processing error had affected six hundred and twelve accounts. The CEO knew this by the end of the first day. By the end of the second day the CEO also knew the following: that the error had originated in a routine update to the billing system, that the update had been tested according to the agreed protocol, that the testing had not caught the error because the specific combination of account types affected was not included in the test cases, and that the test cases had been designed by the provider using documentation provided during the knowledge transfer phase. The CEO asked Joel about the test cases. Joel pulled up the original testing framework that the company had used before the transition and compared it to the provider's version. The difference was not dramatic. It was not the kind of difference that was immediately visible as a gap or an omission or a failure of due diligence. It was the kind of difference that is only visible to someone who knows why the original framework was built the way it was built, which is to say someone who had been present for the specific incident, eighteen months before the transition, that had caused the original framework to include the specific combination of account types that the provider's version did not include. "This test case exists in our original framework because of something that happened before you arrived," said Joel. "A billing error, smaller than this one, that affected a subset of accounts with a specific combination of legacy settings. The incident was resolved and then the framework was updated to include that account type combination in all future billing system tests. The update was documented in the testing framework itself. But the reason for the update, the incident that produced it, was not documented. It was institutional memory. The person who added the test case knew why they were adding it. Anyone who came after them and read the documentation would see the test case but not the reason." "And the provider's team?" said the CEO. "The provider's team reviewed the documentation during the knowledge transfer phase," said Joel. "They saw the test cases. They did not see the reason for this specific one. When they built their own framework they made a reasonable judgment about which test cases to include based on the documentation. This one did not make it into their version because without the context it looked like an edge case rather than a learned lesson." "Is this documented anywhere?" said the CEO. "The original incident?" "In Sandra's files," said Joel. "She kept incident records going back to the beginning. Detailed ones. They were included in the knowledge transfer materials." "And Diane's team?" said the CEO. "Received them," said Joel. "Reviewed them. Did not have Sandra to explain them. And did not know to ask." "Because they did not know what they did not know," said the CEO. "Correct," said Joel.

This is the specific way that knowledge leaves an organisation. Not through the dramatic exit. Not through the resignation letter or the retirement party or the restructure announcement. Through the quiet accumulation of undocumented context that exists only in the understanding of the people who were present when the context was created, and that disappears, incrementally and invisibly, every time one of those people leaves without passing it on. The green notebooks had been Maya's attempt to slow this process. To make the invisible visible. To create a record of not just what the knowledge was but why it existed and what had produced it and what would happen if it were not applied. Maya had understood, instinctively, that knowledge without context is information, and information without context is data, and data without context is noise, and that the difference between an organisation that learns from its experience and an organisation that keeps repeating the same mistakes is almost entirely determined by how much of the context survives the transitions. The green notebooks had survived the transition. They were in a cabinet in the support area. They had been indexed and annotated and made as transferable as a document can be made. What had not survived was Maya. The person who could open any entry in any notebook and tell you not just what it said but what had happened the week before it was written, who had been in the room when the decision was made, what had been tried first and why it had not worked, what the customer had actually said as opposed to what had been recorded, what the real lesson was as opposed to the lesson that fit neatly into a paragraph. That was not in the notebooks. That was in Maya. And Maya was at a small company in an early stage, helping them think about how they captured and shared knowledge before they grew past the point where it happened naturally. On the provider's side, Gil had identified the test case gap three weeks before the processing error occurred. He had not identified it as a test case gap specifically. He had identified it as a pattern in the calls his team was receiving, a subset of account types that were producing unusual resolution pathways that the script did not fully cover and that his agents were handling through improvisation rather than through defined process. He had raised it with his manager. His manager had said it was a matter for the client's operational team. Gil had written it in his own notes. He wrote things in a small brown notebook with squared pages that he kept in the left drawer of his desk. He had been keeping similar notebooks for six years. The current one was the ninth. He wrote: account type combination, legacy settings interaction, resolution pathway unclear, potential error risk. He underlined potential error risk and drew a small arrow pointing to the left margin, where he wrote: escalate. He escalated. The escalation went to Jonathan. Jonathan forwarded it to the client's account liaison. The account liaison logged it as a process query. The process query sat in the queue. Three weeks later, the processing error occurred. Gil read the incident report and found the account type combination in the third paragraph. He sat with this for a long time. Then he opened his brown notebook to the page with the underlined note and the arrow pointing to the left margin. He looked at the word escalate. He had escalated. The escalation had been correctly processed and had sat in the queue. The queue had not been reviewed before the update was pushed. The update had produced the error. He had done everything the structure allowed him to do. The structure had not been built to catch what he had seen. He closed the notebook and went back to his agents, who were handling the callbacks from the error notification, and coached them through the calls with the same focus he brought to everything, the focus of someone who cannot change what has already happened and who is therefore directing all his attention to what is happening now.

The CEO called Maya. Not to ask her to come back. Not yet. To ask her a question. "The processing error," said the CEO. "The billing system update. The test cases." "I heard," said Maya. "Dom sent me a message." "Joel has identified the gap. The provider's framework was missing a test case that existed in ours because of an incident eighteen months ago. The incident was in Sandra's files. The context was not." "I know which incident you mean," said Maya. "I thought you might," said the CEO. "It was before my time here but Sandra told me about it when I was building the knowledge base," said Maya. "I added an entry. I thought I had made the context clear but it is possible I made it clear to someone who already knew the story and not clear to someone who was reading it without that background." "Can you look at the entry and tell me what you think?" said the CEO. "Yes. Give me a day," said Maya. She called back the following morning. "The entry describes the incident and the lesson," said Maya. "It does not describe why the lesson matters. Someone reading it without context would understand what happened and what was changed. They would not necessarily understand that the same type of failure would recur if the change was not maintained in future testing frameworks. I wrote it for someone who understood the system. Not for someone learning the system from scratch." "Is that a common problem with the documentation?" said the CEO. Maya was quiet for a moment. "Yes," said Maya. "Not because the documentation is bad. Because documentation is always written by someone who already understands the thing being documented, for someone who they imagine understands it too. The gap between that imagined reader and the actual reader is where the context lives and where it gets lost." "How much of the documentation has that gap?" said the CEO. "I do not know exactly," said Maya. "A significant amount. The parts I wrote myself I could probably identify. The parts written by other people over the years, by Sandra, by the original team, by the people who have left, I cannot tell you without going through all of it." "Would you be willing to do that?" said the CEO. "You mean review the entire knowledge base for context gaps?" said Maya. "Yes," said the CEO. "That would take months," said Maya. "I know," said the CEO. "And the provider's team would need to be involved," said Maya. "There is no point identifying the gaps if the people who need to fill them are not part of the process." "I know that too," said the CEO. "Can I ask what this is leading toward?" said Maya. "I am not ready to answer that question yet," said the CEO. "But I would like to know that you would be willing to be part of whatever it leads toward." Maya was quiet again. Longer this time. "I would want to know more before I committed to anything," said Maya. "That is fair," said the CEO. "But yes," said Maya. "In principle. If it leads toward something that I think is worth leading toward." "Thank you Maya," said the CEO. "Can I ask one more thing?" said Maya. "Yes," said the CEO. "Are you thinking about the knowledge base specifically or are you thinking about everything?" said Maya. "Everything," said the CEO. "Good," said Maya. Nora had been on treatment for three months. She was still coming in. Not every day. Three days a week on the weeks when the treatment allowed it, two days on the weeks when it did not, and once, in the second month, not at all for a full week when the side effects had produced a tiredness that was beyond what the word tiredness usually describes. The company had adjusted around her without being asked to. The people in her immediate team had redistributed the customer relationships that needed the most consistent attention. The people in adjacent teams had offered, individually and without coordination, to cover specific tasks on the days when she was not there. Owen had been the first to organise this. Not as a formal arrangement. As a conversation he had with three people in separate brief meetings over a Tuesday morning. He had explained the situation, with Nora's knowledge and at her request, and had asked if anyone was willing to take on specific pieces of work on a rolling basis. Everyone he asked had said yes. He had not told anyone above him that he had done this. It had not occurred to him to report it. It was a thing that needed doing and he had done it. The CEO found out from Nora. "Owen organised it," said Nora, in one of their conversations about how things were going. "He didn't make it a project. He just made it happen." The CEO thought about this. Then went to Owen. Owen was at his desk. He had a mug of tea, gone cold by the look of it, on the corner of his desk and the pen behind his left ear that he often forgot was there. "I heard about what you did for Nora," said the CEO. Owen looked up. "What I did for Nora," said Owen, in the tone of someone who is not sure what is being referred to. "The coverage arrangement." "That is just what you do," said Owen. The CEO stood there for a moment. "That is exactly what Priya said," said the CEO. "What?" asked Owen. "Nothing," said the CEO. "Thank you Owen." Owen nodded and went back to his work. The CEO thought: how many times has he done this kind of thing that nobody above him knows about.

The knowledge that left was not only in the documentation. This was what the CEO was beginning to understand in the weeks after the processing error, sitting with the problem in the way that the CEO had learned, early in a career that had included many problems that looked simple and were not, to sit with problems before deciding what to do about them. The documentation was the visible part. The green notebooks. The incident records. The testing frameworks. The product knowledge articles. These were things that could be identified and reviewed and found to have gaps and had those gaps filled, slowly and carefully, by people who understood both the knowledge and the context. The invisible part was harder. The invisible part was the knowledge that had never been in any document. The knowledge that had lived entirely in the understanding of specific people and that had been applied, unconsciously, in every decision those people made about how to handle a situation that the documentation did not cover. Priya's knowledge of when to stay on a call and when a customer needed something beyond what the script could offer. Sandra's knowledge of which agents were ready for more responsibility and which needed support on certain call types and which were struggling in ways that were not yet visible in the performance data. Maya's knowledge of why the knowledge base was organised the way it was and what the decisions behind the organisation revealed about the history of the product and the customer base and the nature of the problems the support function was designed to solve. Owen's knowledge of when a team needed organising before the need was visible in any report. None of this had been in any document. All of it had left, or was leaving, or was present and invisible, which was its own kind of loss. And the thing about knowledge that leaves in this way is that it leaves completely. It does not leave gradually, a little at a time, in ways that are noticed and compensated for. It leaves all at once, on the day the person who carries it walks out the door, and it is only after it has left that the shape of what is missing becomes visible, in the moments when it is needed and is not there. The processing error was one of those moments. Elena's email had been another. The CEO thought about Joel's theory of two kinds of distance. The kind you can see and the kind you cannot. The knowledge that had left was the same. The part in the documentation you could see, identify and address. The part that had lived in Priya and Sandra and Maya you could not see, could not fully identify and could not fully address, not from where the company was now, not with the tools available to it. You could only rebuild it. And rebuilding it required the conditions that had produced it in the first place. The room. The proximity. The accumulated experience of people who were present for the things that produced the knowledge and who stayed long enough to pass it on to the people who came after them. The CEO sat with this understanding for several days. Not acting on it. Not yet. Letting it become as clear as it needed to be before deciding what to do with it. There is a version of this process that leaders skip, the sitting with it, because sitting with something uncomfortable is itself uncomfortable and there are always other things that can be done instead, things that feel like progress and are sometimes progress and are sometimes the equivalent of rearranging the furniture in a room where the ceiling is coming down. The CEO did not skip the sitting. After several days the understanding was clear enough. The CEO called a meeting with Joel. Not a formal meeting. A conversation in the meeting room with the whiteboard and the four chairs, which the CEO had noticed was where the important conversations always happened, the ones where something real was being decided rather than something already decided being managed. "I want to talk about what going back would actually mean," said the CEO. "In terms of?" said Joel. "In terms of what it would take," said the CEO. "The board. The contract. The timeline. The people." "You have made the decision," said Joel. "I am making it now," said the CEO. "While we are talking. I want to understand what it requires before I finish making it." "It requires ending the provider contract," said Joel. "There will be penalties. I can look at the exit clauses but we should assume it is expensive." "I know," said the CEO. "It requires rebuilding the support function internally," said Joel. "That means hiring. Training. Building the knowledge base back up to a state where it can actually support the team. That takes time. Probably a year to get to a functional state. Two years to get to where we were before." "Two years," said the CEO. "Minimum," said Joel. "If we do it well. If we rush it we will have a support function that looks like what we had and does not work like what we had, which is a different kind of problem." "And the people?" said the CEO. "That is the harder question," said Joel. "I know," said the CEO. "But I want to ask it anyway." "Some of them will come back," said Joel. "Not all of them. Maya might. Sandra might. The others, the ones who took the severance or the provider positions, some of them will have moved on in ways that are real and cannot be easily reversed. And Priya." "Priya," said the CEO. "Priya is at a small company doing exactly what she is supposed to be doing," said Joel. "I do not know if she would come back." "I would like to ask her," said the CEO. "I thought you might say that," said Joel. "What else?" said the CEO. "The board," said Joel. "Marcus will want to understand the financial case. The penalties for exiting the provider contract plus the cost of rebuilding internally plus the transition period where you are running two operations simultaneously or running one operation below the previous standard. That is a significant number." "I know," said the CEO. "You are going to need a different number to put against it," said Joel. "Elena," said the CEO. "The processing error. The churn trend. The six hundred and twelve accounts. The distance between three point six and four point two on a five-point scale and what that distance costs in customer lifetime value over three years." "That is the case," said Joel. "Can you build it?" said the CEO. "Yes," said Joel. "It will take two weeks to do it properly." "Do it properly," said the CEO. "And while I am building it?" said Joel. "I am going to call some people," said the CEO.

End of Chapter 10

Writer's Thought:

Are you thinking about the knowledge base specifically or are you thinking about everything said Maya. Everything said the CEO. I was glad someone finally asked.

Here is What is Broken. The CEO. The Knowledge That Left.

MarvinPro | March 2026

marvinpro.com

Think Simple.