Your Employees Can’t Read Your Mind
Before going further, I have put together a practical workbook to help you apply the ideas from this article directly to your own business. It will help you identify where your company still depends too much on you, decide what knowledge should be documented first, clarify decision rights and start building a more autonomous organisation.
Free Download — The Founder Independence Toolkit
Why a company becomes truly scalable when knowledge leaves the founder’s head
When we started Traiteur Géraldine, we were only two to five people. At that stage, we did not really need formal procedures because knowledge was transferred directly on the job. Géraldine or I would work alongside new employees, show them how things were done, answer their questions and correct mistakes as they happened.
We would usually spend several days training someone, but the most important part was that we were always there. If someone forgot something, we reminded them. If they had a doubt, they asked us. If a decision had to be made, we were standing nearby and could make it immediately.
For a small company, this system actually worked quite well. Not because we had created a particularly sophisticated organisation, but because our permanent presence compensated for the fact that very little had been formally documented.
The problem appeared when the company started to grow.
When we moved from one location to several buildings and eventually had more than 50 employees, it became impossible to keep working in the same way. I started receiving WhatsApp messages and phone calls throughout the day. Managers needed decisions, teams needed validation and people were constantly asking questions that, in a small company, we would simply have answered while standing next to them.
That was when I began to understand something that now seems obvious to me: your employees cannot read your mind.
Canva visual: The Founder Knowledge Trap
We were using the same words, but they did not mean the same thing
I remember telling the manager responsible for one of our central kitchens that I simply wanted the operation to “run properly”. In my mind, that sentence carried a huge amount of information. The schools had to receive their meals on time, production needed to be efficient, food costs had to remain under control, quality had to meet our standards, the team had to be organised correctly and the activity obviously needed to remain profitable.
In his mind, however, “running properly” mainly meant that all the meals were produced and every school was delivered on time. Technically, he was doing what I had asked. The operation was running, customers were being served and there was no obvious daily breakdown.
The problem was that some teams were buying too much, profitability was not being monitored closely enough and the quality did not always match what we had imagined. He and I were using exactly the same words, but the definition behind those words was completely different.
With hindsight, the mistake was not simply his. I had given him an objective without properly explaining what success looked like. My definition of “it works” was stored in my head, and I had assumed that another person would naturally arrive at the same definition.
That is one of the first major lessons I learned while growing the company: what seems obvious to the founder is often not obvious at all to the person receiving the instruction.
“Make me 100 tiramisus” is not a procedure
The same thing happened constantly in the kitchen. I could walk into production and say, “Make me 100 tiramisus,” and genuinely believe that the instruction was clear.
But once you think about it, there are dozens of decisions hidden inside that sentence. Which recipe should be used? What portion size? Which packaging? Glass or disposable container? What decoration? How much product goes into each portion? What should the final result look like when it reaches the customer?
If none of those details are specified, the cook has no choice but to make decisions. That is not necessarily a problem in itself, and the decision may even be perfectly reasonable. The difficulty is that their interpretation of the product may not be the one Géraldine or I had in mind.
I experienced the same problem when I managed a kitchen and then left for several days. Before leaving, I could explain a concept that had to be respected. When I came back a week later, part of that concept had sometimes disappeared because the team had concluded that “it didn’t work”.
I would then get involved, show them how I expected it to be done, and suddenly the idea worked again. The concept was not necessarily the problem. The real problem was that part of the knowledge required to execute it had never left my head.
At some point, the founder becomes the bottleneck
When you have five employees, answering questions is manageable. When you have several buildings, dozens of employees and different managers, the same behaviour becomes a serious organisational problem.
You simply cannot answer everything. Even worse, if you keep trying, you eventually become one of the biggest bottlenecks in your own company. Every unusual situation comes back to you, every uncertain decision requires your validation and every new employee increases the number of questions rather than reducing them.
At that point, the company may have managers on paper, but the founder is still effectively managing everything through them.
That was when I started formalising what we knew. At first, the tools were very basic. I created Excel sheets with purchasing limits, targets for food-cost ratios, portion sizes for certain products and standard delivery routes. Over time, the system became much more structured and we added production sheets, checklists, KPIs, decision rules, quality controls and training manuals.
The objective was not to build bureaucracy. I was simply trying to transform years of experience and intuition into information that another person could actually use without calling me every time.
Standardise what can genuinely hurt the company
One of the risks when you begin creating procedures is to go too far. I have never wanted to build an organisation where every minor action needs to be documented and where employees are afraid to use common sense.
Instead, I tried to identify the factors that could genuinely affect the success of the company. In our kitchen, for example, food cost has a direct impact on profitability. Taste has a direct impact on customer satisfaction. Hygiene can create serious legal and operational consequences. Equipment and cleanliness influence our ability to produce consistently.
Those are areas where I want clear standards.
For some critical products, we therefore use precise production sheets and grammages. On the other hand, for something with a relatively low financial or quality risk, such as certain vegetables, I am happy to leave more freedom to the team.
Over time, this became a fairly simple rule in my own management approach: standardise what protects the company, but leave freedom around what does not put the business at risk.
Canva visual: Critical Knowledge Matrix
Create guardrails, not permanent approval systems
I also try to avoid another common mistake: creating a process in which managers have to approve every action. If an employee needs validation for everything, the problem has not actually disappeared. The bottleneck has simply moved from the CEO to the manager.
In our event department, for example, we use departure checklists and equipment checklists. There are quality-control points before an event leaves our premises, but the objective is for the teams to be able to control themselves rather than needing a manager to validate every individual item.
I would actually prefer an employee to make an honest mistake, understand why it happened and learn to correct it than to create an organisation where nobody dares to make a decision.
For me, that is an important distinction. The goal is not to control every action; the goal is to make sure the system consistently produces the result the company expects.
When a KPI is bad, I first want to know why
This way of thinking also changed the way I manage people. When an indicator becomes bad, my first reaction is not to call the employee into my office and tell them they are not performing. I first want to understand precisely what happened.
Where did the result start to go wrong? Was there one particular day, one decision, one purchase or one process that created the problem? Once I have understood the cause, I can have a much more useful conversation with the person involved.
Instead of simply saying that their indicator is below target, I can explain what I found and why it had an impact. If I know that the person has enough experience and perspective, I will often ask them what they think should change. If they are not yet able to see the bigger picture, I will guide them more directly and explain what I would do.
Of course, if someone clearly understands the rules and deliberately refuses to apply them, that becomes a different conversation. But in most cases, management should first be about helping someone understand how to reach the expected result, not simply criticising the fact that they have missed it.
A written rule is not necessarily an understood rule
One of the biggest mistakes companies make with procedures is believing that writing something automatically means people will follow it. You can create a 200-page manual, but if nobody understands why those rules exist, there is a good chance that the document will eventually become useless.
People need context. If you tell someone that a particular tool must always be stored in one specific place, they may simply think that another location would be more convenient for them. But if you explain that the chosen location reduces unnecessary movements, saves time for the whole team, improves safety or reduces physical strain, the rule starts to make sense.
This is particularly important when you are changing habits. A rule without an explanation often feels like bureaucracy. A rule with a clear reason is much easier to understand and adopt.
That is why training remains essential even when the information is written down. At Traiteur Géraldine, depending on the position, a new employee receives between half a day and a full day of initial training. We also have small role-specific manuals that contain the organisation chart, hygiene rules, the history of the company, our mission, vision and values, mandatory training and practical information linked to the person’s role.
For kitchen employees, the documentation can go as far as explaining where certain equipment has to be stored. That may sound excessive, but when 20 people all have their own definition of “the logical place”, you quickly end up with 20 different systems.
A department should never win while the company loses
KPIs can create another kind of problem when they are designed in isolation. I once had a situation where someone had a target linked to the number of banquets sold. They became extremely focused on achieving that target, which initially looked like a good thing.
The problem was that some of those sales were very difficult, and sometimes almost impossible, for the production teams to deliver efficiently. From the commercial point of view, the KPI looked good. From the perspective of the company as a whole, the result was far less positive.
That experience taught me another rule I still use today: a department should never be able to win while the company loses.
Today, part of our performance management is connected to overall customer satisfaction. After an event, customers receive a questionnaire containing several questions scored from 1 to 5. We can analyse those results by department, but we also monitor the overall customer experience.
That forces every team to remember that they are contributing to the same final result. Sales, kitchen, logistics and service may have different objectives, but the customer experiences all of them as one company.
The CEO’s role has to change as the company grows
My own role changed significantly as the company became larger. When we were small, a large part of my day consisted of solving immediate problems. Later, I realised that this could no longer be my main responsibility.
I often compare the CEO to the captain of a ship. The captain cannot spend the entire journey repairing every small problem on deck. At some point, they need to take the binoculars and look ahead.
What is coming next? What could become a problem in three months? Where are we going? Are our indicators moving in the right direction? Do the teams understand the destination?
That is where I believe a CEO creates the most value. Their responsibility is not to answer every operational question but to anticipate, give direction and make sure the organisation is still moving towards the right objective.
This becomes particularly important during difficult periods. When a company faces financial pressure or uncertainty, the CEO has to absorb part of that pressure, but also give the teams a clear sense of direction. People need to know what is happening, what the plan is and what the next milestone looks like.
Without that visibility, uncertainty quickly turns into fear.
Information should circulate without constantly returning to the founder
For an organisation to become autonomous, information also needs to move properly. We therefore created several layers of communication inside the company.
Employees know who their direct manager is and are expected to communicate through that structure rather than always moving directly to the highest level of management. Departments have their own communication channels and meetings, and once a week our managers and department heads meet together so that information can move between functions.
We also use a central software system that allows different departments to access shared information. Several of our key managers work in the same open space, which may seem like a small detail but makes daily communication much easier.
The principle behind all of this is simple: information should circulate through the organisation instead of constantly climbing all the way back to the founder.
What should a useful procedure actually contain?
If I had to build a procedure for a critical task today, I would begin with something very simple: the date and version. People first need to know that they are using the most recent information.
Then I would explain the objective of the task and, importantly, why the process exists. I would identify the people concerned, explain the consequences if the rule is not respected and define any numbers that need to be monitored, whether that means a maximum budget, a margin, a quantity, a deadline or another KPI.
After that, I would describe the steps themselves, the most common mistakes, the main risks and, where necessary, the final control point.
For me, a good procedure should not only explain what someone needs to do. It should transfer part of the reasoning that previously existed only inside the founder’s head.
Canva visual: JM Conseils Knowledge Transfer Sheet
Procedures need to stay alive
A procedure written once and forgotten for five years will eventually become almost as dangerous as having no procedure at all. Companies change, tools change, customers change and teams naturally adapt the way they work.
That is why I believe a business needs a living knowledge base where the latest version of a critical rule is always easy to find. It is also useful to refresh certain rules with the teams regularly; depending on the subject, even a simple review every six months can help prevent gradual drift.
Because drift happens very naturally. One employee changes one small detail, the next employee learns from that version, and another person changes something else. Three years later, everybody may be doing something completely different from what was originally intended.
We are still working on this ourselves
I do not want to write this article as if Traiteur Géraldine had solved the problem perfectly. We have not.
A significant amount of our culinary know-how still exists in Géraldine’s head. Her recipes, her methods and the experience that allows her to taste something and know almost immediately whether it is right are the result of years of practice.
We are currently working on turning more of that knowledge into recipe sheets containing precise quantities, procedures and photographs showing what the finished product should look like. There is still more to do, particularly around some taste and texture standards that remain difficult to describe precisely on paper.
That is also part of the lesson. Knowledge transfer is not something a company completes once and then forgets. It becomes an ongoing part of building a business that can operate without depending permanently on one person.
The 30-day test
There is one question I think every founder should ask themselves: could your company operate for 30 days without you?
I do not mean a weekend, three days away or a holiday during which you still answer WhatsApp every evening. I mean 30 days during which the business genuinely has to function without your operational involvement.
Would managers continue to make the right decisions? Would the same quality standards still be respected? Would the KPIs still be monitored? Would information continue to circulate? Would customers notice a difference? Most importantly, would your phone remain quiet?
A month is long enough for weak points to begin appearing. If everything starts to fall apart because the founder is unavailable, then too much of the company still exists inside one person’s head.
Canva visual: The 30-Day Test
This is not only a growth issue. It is also a risk-management issue.
A founder can become ill, face a personal problem or simply need time away from the business. If the company becomes fragile every time the founder becomes fragile, then the organisation itself remains fragile.
The objective is not to make the founder unnecessary. I still believe the CEO should remain close to customers, close to the teams, attentive to quality and deeply involved in the company’s main performance indicators.
What should disappear, however, is the dependence on the CEO for daily operational decisions. The founder should not have to decide which small piece of equipment needs replacing, which product should be purchased for tomorrow or how every individual customer complaint should be solved.
At a certain size, the founder’s energy should be directed towards the future: major negotiations, long-term strategy, quality, performance and the direction of the company.
Lose time today to save time tomorrow
Writing down something you already know can feel painfully slow. When you have spent ten or twenty years doing something, explaining every detail may even feel ridiculous because the answer seems completely obvious to you.
Write it anyway.
The reason it feels obvious is often because you are carrying years of experience, mistakes, financial pressure, customer feedback and decisions in your head. The person who joined your company six months ago does not have access to any of that context.
So take the time to write it down, explain it and show people why it matters, even when another task seems more urgent.
Lose that time today. It is time you will gain tomorrow.
Because the real purpose of a procedure is not to create bureaucracy or control people. It is to protect quality, protect continuity and give other people enough information to make good decisions without depending permanently on the founder.
And ultimately, it allows the CEO to return to the role they should really have: looking ahead instead of answering every question behind them.