Experience Does Not Automatically Produce Learning
A project that went wrong twice
At the end of a demanding project, the team held a lessons-learned meeting. The launch had slipped, several decisions had been made too late, and people had worked around conflicting priorities. The meeting was candid. Everyone agreed that roles should be clearer, risks should be escalated earlier, and communication should improve. The conclusions went into a shared folder.
Six months later, another project encountered the same problems. The people involved were experienced. Some had been in the first review. They knew what had happened, yet they found themselves waiting for the same decisions, negotiating for the same scarce resources, and improvising the same workarounds.
This is a familiar organizational puzzle. How can a team have considerable experience and still repeat its mistakes? The answer is that exposure to events and learning from them are different things. Experience supplies material for learning. It does not, by itself, change what people notice, assume, decide, or do.
The point matters for middle managers or
project managers because they often sit where experience accumulates. They see customer reactions, missed handovers, team tensions, successful experiments, and decisions that later prove costly. Whether these signals become useful knowledge depends on what happens after the event—and on whether the organization is willing to change its own practices.
Why experience can leave our thinking intact
When something goes wrong, the quickest explanation is often the most comfortable one. The project manager should have escalated sooner. A colleague lacked commitment. The team needed more training. Each explanation may contain some truth. But it can also protect the assumptions behind the original decision: that the deadline was realistic, that priorities were compatible, or that someone actually had the authority to resolve a conflict between departments.
Past success creates a related problem. A manager may have used a particular method effectively for years and continue to apply it when the context changes. Repetition then builds confidence in a habit rather than an ability to adapt. Experience can make someone faster at recognizing familiar patterns while making unfamiliar evidence easier to dismiss. The question is not simply how long someone has worked; it is whether their interpretation of events has been tested and revised.
Context also matters. In a stable situation, following a proven procedure can be exactly the right response. In a new situation, the same procedure may become a poor guide. A project involving new technology, a changed customer need, or an unfamiliar partnership carries uncertainties that cannot be removed by repeating yesterday’s solution. What looks like a failure of execution may be information about an assumption that was wrong from the start.
Organizations often compound the problem by treating experience as an individual possession. One person learns that a client interprets a requirement differently; another discovers that a handover routinely loses information. If those observations remain in private conversations, the next team starts from the same false picture. A report can preserve a conclusion, but storage alone does not make it part of future decisions.
The missing step between an event and a changed practice
Learning begins when people reconstruct what happened closely enough to challenge their first account of it. What did we expect? What did we observe? Where did the two diverge? Which facts do we have, and which explanations have we inferred? These questions sound simple. Under pressure, they are easily replaced by a search for a quick fix or a person to blame.
Consider the delayed project decision. A review might conclude that the project manager needs to be more assertive. A closer conversation could reveal that two executives had given incompatible priorities and that neither the project manager nor the steering group had a clear rule for arbitration. The first conclusion asks an individual to behave differently. The second asks the organization to change how it makes decisions. Both may be relevant, but only the second reaches the condition that will affect the next project manager too.
This requires dialogue across perspectives. Finance may see an overrun, operations a shortage of capacity, and the project team a sequence of unanswered requests. Each view is partial. Before the group decides what to do, it needs a period of inquiry in which people can explain what they saw and test the assumptions behind their interpretations. That inquiry has to be safe enough for someone to say, “I thought this decision had been made,” or “I did not know I was allowed to challenge the deadline.” Discussion and decision then have their place, but they work better after the situation has been understood.
Success deserves the same scrutiny as failure. A successful launch may owe something to extraordinary effort, an unusually available expert, or a favorable customer response. Calling the approach a “best practice” without examining those conditions can turn a contingent success into an unreliable rule. The useful question is which features of the context made the approach work and whether they will be present next time.
Training has a role here, especially when people lack a method or a skill. But sending a team to a course does not resolve contradictory priorities or redesign an ineffective handover. Training can increase what individuals know. Organizational learning becomes visible when what the organization does next changes in response to experience.
A practical framework: experience, inquiry, change, test
The first move is to capture a specific experience, close to the work. Choose a decision, incident, customer signal, or unexpected success while the details are still available. State what was expected and what actually occurred. A vague lesson such as “communicate better” is hard to use; a precise observation such as “the operations representative was consulted only after the delivery date was fixed” gives the team something to examine.
Next, inquire into the gap. Bring in people who saw different parts of the situation, including those who will live with the proposed change. Separate observations from interpretations. Ask how the team made sense of the information available at the time, which constraints shaped its choices, and what evidence would support another explanation. The manager’s contribution is to keep inquiry open long enough to uncover a useful cause, without turning it into an endless meeting.
Then decide what must change. Sometimes the answer is an individual skill: someone needs to learn how to frame a risk or conduct a difficult conversation. Sometimes it is a team routine, such as a weekly decision review. Sometimes it is a rule about who can arbitrate priorities, or a measure that rewards short-term delivery at the expense of cross-team cooperation. A lesson is not complete when it is written down. It needs an owner, a change in practice, and a point at which the effect will be checked.
Finally, test the change in the next comparable situation. Did the new review bring decisions forward? Did the handover reduce rework? Did the client experience improve? If not, the team has learned something about its first diagnosis. The cycle continues: experience, inquiry, changed action, new experience. It is a disciplined way to learn without pretending that every event yields a universal rule.
The framework is deliberately modest. It does not require a large knowledge platform or a formal review after every meeting. It requires a habit of connecting evidence to decisions, and decisions to observable changes. Digital tools may help teams retrieve patterns across projects, but they cannot settle a conflict of priorities or make a manager welcome a challenge to a cherished assumption.
Make room for learning in ordinary work
For a middle manager, the most useful starting point may be a short conversation after a decision has had time to show its effects. Ask what surprised the team, what it had assumed, and which small adjustment it will try. Listen for repeated workarounds. They may signal that people are compensating for a system problem rather than failing to follow a process.
For a project manager, a review is more valuable when it is timed to influence the next decision, not merely held at closure. If a recurring resource conflict appears in the first month, waiting for the final retrospective gives the organization months to repeat it. Bring the pattern to the people who can arbitrate it, document the decision, and check whether the conflict recurs.
None of this means that every setback is a valuable learning opportunity. Some errors are preventable and some cause real harm. Teams need standards, preparation, and accountability. The question is whether accountability ends at assigning responsibility or also helps identify the conditions that made an outcome likely. Equally, a team need not celebrate failure to investigate it honestly.
Experience becomes learning when it changes the next action—and when that change can be tested. A team with ten years of experience may have learned less than one that has examined a difficult year carefully and altered how it works. The next time a review ends with “we must communicate better,” ask a more demanding question: what, exactly, will we do differently in the next decision, and how will we know whether it helped?
S'il ny a pas de citation exacte, il reste que j'ai emprunté aux auteurs suivants :
Peter M. Senge, The Fifth Discipline: The Art & Practice of the Learning Organization, 1990
Amy C. Edmondson, Right Kind of Wrong: The Science of Failing Well, 2023
Linda A. Hill, Becoming a Manager: Mastery of a New Identity, 1992
Chris Argyris et Donald A. Schön, Organizational Learning: A Theory of Action Perspective, 1978
Chris Argyris, « Teaching Smart People How to Learn », Harvard Business Review, 1991
Comments