Reflective practice

Some projects end twice. The first time is on delivery day: the system is up and running, the final demo takes place, the loose ends are tied up and everyone goes back to their usual work. The second comes much later, when someone finally understands what happened. Sometimes that understanding arrives while reviewing a decision that seemed minor at the time. Other times it appears in front of a new problem, in another organization, when a familiar scene returns with a clarity it lacked while it was unfolding.

That kind of revelation is rarely spectacular. It has little in common with the bright moment of a presentation and much in common with discovering that two teams, years and entire industries apart, invented the same manual workaround to protect themselves from systems they did not trust. In the first case, the workaround looked like an eccentricity. In the second, it was hard to call it coincidence. By the third it becomes a pattern, and a pattern forces a revision of the method.

That is where reflective practice begins: the work of returning to an intervention once the urgency has passed, reconstructing its decisions and separating what belongs to that case from what is likely to show up again. The phrase sounds academic, but the gesture is concrete. It means pausing, for a moment, the compulsion to move on to the next project and asking what was learned, what was merely believed to be learned, and what evidence supports each claim.

That last distinction matters. Accumulating years of work does not guarantee accumulating experience: one can repeat the same year of practice for ten years. Experience begins when work leaves traces that can be compared, discussed and, when necessary, made to contradict the intuition of the person who gathered them.

Going back to where it was decided

A useful review does not settle for noting that the project went well or badly. Those labels are too coarse. A project can meet its scope and, at the same time, install a dependency that makes it fragile. It can run late and leave behind an internal capability that justifies the wait. It can be celebrated by management and quietly avoided by the people who work with it. What matters is less the isolated outcome than the way it came about.

That is why one has to go back to the decisions. When was a warning from the team dismissed? What assumption allowed the work to move forward? Who formulated it, and who was missing from the conversation? What signal was visible from the start but only understood at the end? Was there a moment when changing course was still cheap?

The reconstruction has something of an investigation about it. It draws on interview notes, versions of the scope, shifting priorities, incidents and support conversations. But it also requires remembering the climate in which things were decided. Minutes record that the sales area approved the pilot; they rarely record that it did so after its manager spoke for half an hour and no one wanted to contradict them. Technical documentation keeps what was built. Field memory has to keep why, for whom and under what pressure.

Distribuidora Norte shows the difference. Its first prototype of alerts for at-risk customers was a hit at the demo. The sales manager, curious and patient with new tools, understood every indicator and tolerated a few extra steps. Had the story ended that day, the conclusion would have been simple: the pilot worked. But the salespeople out on the street did not work under demo conditions. Between one visit and the next they had a few minutes, a small screen and no appetite for interpreting a dashboard. The same product was clear to the person who had championed it and laborious for the majority who had to take it on.

The lesson was not “make simpler interfaces”, a conclusion so general it is almost useless. It was more precise: a pilot can be validated by people whose tolerance for friction does not represent its future users. From then on, the question of who takes part in the trial stops being logistics and becomes part of the diagnosis.

The log as working memory

Human memory edits the past. It smooths over hesitations, connects decisions that were separate at the time and attributes intention to outcomes that owed a good deal to chance. That is why reflection needs a log written while the work is happening. There is no need to turn every day into a report; it is enough to record the changes that might later explain why the project took the shape it did.

A useful entry contains a few concrete things: what was observed, what interpretation was made, what decision it led to, and what would have to happen to show that the interpretation was wrong. That last question keeps the log from becoming a diary of self-justification. If one notes that a team rejects a tool out of fear of losing autonomy, one must also note what behavior would be expected if the hypothesis were true: parallel spreadsheets, requests for authorization for actions that used to be informal, correct use during demos and almost none when no one is watching. If none of that appears, another explanation is needed.

Over time, the log serves three purposes. First, it helps steer the project under way, because it makes it possible to notice that a signal is repeating before it becomes an incident. Second, it preserves the reasoning for the team that will receive the system. Finally, when several interventions are compared, it feeds the method’s corpus. That is where an observation can move from a single case to a recurring hypothesis.

That move should not be automatic. Something that happened once is memorable, not general. If it happens twice, it becomes suspicious. Only when it appears in different contexts and can be described through observable signals does it deserve to be called a pattern, and even then it keeps a provisional status: it guides the eye, but it does not replace reading the case.

The same caution applies to IMIA. Field notes may suggest that an indicator weighs too much or that a dimension is missing, but they are no substitute for empirical calibration. They help frame the question better, a question that will later have to be tested against a larger sample. Mistaking accumulated judgment for statistical validation would repeat, inside the method, the very shortcut the method criticizes.

When failure warns in advance

Projects rarely fail all at once. They drift through small signals, many of them tolerable on their own. A leader stops showing up to demos. A spreadsheet that was supposed to be retired keeps circulating “just in case”. The team learns to fill in the new system at the end of the day, after doing the real work through another channel. The AI policy is postponed to a later phase that never arrives.

What this book calls failure patterns are those recurring configurations: combinations of behavior that tend to lead to a predictable outcome if no one reads the situation again. The word failure is not looking for culprits, nor does it announce that all is lost.

One of the most common is the pilot designed for innovators, the same one that nearly caught Distribuidora Norte. The enthusiast who agrees to try something new is invaluable for getting started and a poor sole representative of the future user: they tolerate errors, mentally fill in missing instructions and grant the product a patience that the ordinary workday will not. The fix is to bring in, early on, the people who need the tool to be obvious, fast and reliable. The aim is not to dampen the innovator’s enthusiasm but to find out whether it can become a collective habit.

Another pattern appears when automation comes before the data is cleaned up. At first it looks like an argument about figures: the dashboard says one thing and the operator another. The easy way out is to assume the operator is resisting the evidence or that the model needs tuning. Sometimes the opposite is true. The system is aggregating data whose definition changes from branch to branch, or it takes as the sale date what one area considers the shipping date. Automation did not create the error. It made it faster, more visible and harder to dispute, because it now arrives with the authority of a screen.

Sponsorship without operational roots is also common. A convinced leadership can approve budget and clear obstacles, but it cannot adopt on other people’s behalf. If those who work with the process feel that the change adds control, takes away their room to maneuver or ignores a known exception, approval from above only postpones the conflict. Passive sabotage tends to be undramatic: incomplete data entry, intermittent use, a return to the informal channel. Each of those behaviors carries information about an actor map that was left incomplete.

Postponed governance belongs to the same family. The team promises to define permissions, responsibilities and appeal mechanisms after the pilot, because it wants to prove value first. The sequence was already debatable when software only made suggestions; with agents that can execute actions, it is dangerous. The ratio between agentic potential and governance capacity that IMIA proposes exists to make that imbalance visible before the incident, while it can still be corrected without harm.

Finally, some failures arrive disguised as successful deliveries. The system is handed over with manuals but without the reasoning behind its design. Whoever receives it knows which button to press but not which assumptions support the decision, so at the first exception they open a ticket or improvise a workaround. That handoff without judgment produces dependency and sociotechnical debt at once. And if the transformation also depended on a single person (the champion who secured permissions, translated between areas and remembered why each thing had been done), their departure sends the project back to square one.

Not every pattern has a technological root. An organization can declare that it wants to innovate and punish every attempt that does not work out. It can buy a solution designed for a company ten times its size and then blame its people for not following the process. It can invest in intensive training for a workforce with seasonal turnover, as if the problem were the quality of the course rather than the impossibility of retaining what is learned. In these cases technology works as a screen: it lets people argue about tools instead of incentives, scale or working conditions.

Rules born on the ground

A heuristic is a practical rule for deciding with incomplete information. It does not claim to be a law and should not be used to avoid judgment. It serves to halt inertia and force an uncomfortable question at the right moment. The ones that follow are written in the first person, for a reason explained at the end of this section.

If the area leader does not take part in the demo, I do not consider a pilot ready to scale. The absence may have innocent explanations, but it may also indicate that the project lost its sponsor or that management delegated something that still requires its own decision. The rule does not order a cancellation; it orders finding out before committing more resources.

I do not automate a process whose owner cannot explain why it is done that way. The rule does not demand a perfect procedure. It demands recognizing whether one is facing an understood practice or a sequence of habits no one dares to touch. When three people describe the same process in incompatible ways, building right away amounts to choosing one of those versions without admitting it. Shared meaning has to come first.

Something similar happens with data. Asking “which number would you use to make an irreversible decision?” usually reveals more than reviewing twenty dashboards. If each person in charge picks a different figure, the problem is not yet a predictive one: the organization has not agreed on what it considers true. The work has to go back to definitions, lineage and responsibilities before offering a model.

Resistance deserves a rule of its own: when it brings a valid operational reason, it becomes a design requirement. The supervisor who refuses to drop a verification step may be defending a privilege, but may also know the exception that prevents the wrong goods from being shipped on Fridays. Only observation can tell the two apart. Labeling every disagreement as resistance to change saves time in the meeting and charges it back with interest in production.

These rules are written in the first person because they involve professional responsibility. “I never automate” weighs differently than “it is advisable not to automate”: it makes clear that someone is making a decision and will have to answer for it. It also admits revision. If future experience shows a rule to be too rigid, it will have to be rewritten.

Reflecting with others

Every solitary reflective practice runs a risk: building a personal mythology in which the professional always saw the problem coming. To avoid it, the review has to include other participants. Not only the technical team and whoever commissioned the work, but also the people who carried the day-to-day change.

A good after-the-fact conversation does not only ask what went wrong. It asks what was surprising, which part of the system was appropriated in an unexpected way, which task got worse even though the overall indicator improved, and what decision each participant would change if they could go back to the beginning. The answers do not always match, and that divergence is valuable: it shows that the same project produced different experiences depending on where each person stood in the organization.

Reflection also has to be kept apart from the ritual of blame. If every incident ends in a search for who got it wrong, there will be less information available next time, because people will learn to hide doubts and workarounds until they can no longer be concealed. A serious postmortem reconstructs conditions and decisions. It does not erase individual responsibility; it places it within a system that made some actions more likely than others.

From the case to the corpus, and from the corpus to the case

The corpus should not grow like a warehouse of notes. Its job is to keep thinking that can return to the work. To get there, each finding goes through a small editorial test: is it described precisely enough? Is observation distinguished from interpretation? Did it appear in more than one context? Does it change any decision in the method? If it does not pass those questions, it can stay in the log without yet becoming doctrine.

When it does pass them, the movement reverses and the concept returns to the field as a new question. Champion dependency, for instance, was born from watching projects lose momentum when a key person left. Once named, it makes it possible to ask from the first diagnosis who can take over, where the judgment is documented and what happens during an absence. The concept does not magically explain the new case; it helps to see it sooner.

That is how the bridge learns: the field corrects the corpus and the corpus sharpens the gaze that returns to the field. In that exchange, the method avoids two extremes. One is becoming a recipe that forces every problem to look alike. The other is remaining a personal sensibility that cannot be passed on. Reflective practice holds an intermediate space, more demanding and more fertile, that recognizes each organization as singular without resigning itself to losing what one experience can teach the next.

Working this way requires a certain modesty. It means accepting that a correct delivery can contain a bad decision, that an elegant hypothesis can fall apart in a hallway conversation and that some lessons arrive too late for the project that produced them. That modesty does not weaken the craft. It is what allows it to mature.