Unlearn a habit that no longer fits your role

A habit can be sensible in one role and troublesome in another. The mistake is not that you learned it. The mistake is assuming that its original conditions still apply when the team, system, or responsibility has changed.

Find the assumption that made the habit useful

Barry O’Reilly’s Unlearn focuses on behaviours that once helped but can later obstruct progress. His public description of the unlearning framework separates letting go of an old approach from learning a replacement. This is a useful prompt to examine a habit, not proof that every established practice should be discarded.

Start by explaining why the habit existed. Perhaps you kept decisions informal because everyone who needed them was in the same room. Perhaps you fixed small issues yourself because you were the only person who understood the component. Perhaps you optimised for speed because the experiment was deliberately disposable.

Naming the original benefit prevents a shallow reaction such as “informal communication is bad” or “experienced engineers should stop coding.” The question is which assumption changed, not which behaviour sounds modern.

Try the decision

A senior engineer keeps rewriting teammates’ solutions before review.

Try harder to give perfect fixesAsk questions first and test when direct edits are needed

The old habit may keep reducing ownership even if the fixes are technically sound.

Next step: Name the assumption that once made the habit useful.

This is an illustrative decision with stated assumptions. It cannot establish your employer’s policy or predict an individual career outcome.

Trace what happens in the new setting

In an illustrative example, an engineer maintains a service that began with one consuming team. They have always clarified changes in a direct conversation and implemented them immediately afterwards. The service now has several consumers, but the engineer still treats the original conversation as sufficient agreement.

A new change surprises another team. The engineer explains that the decision was already discussed, which is true but incomplete: it was discussed with only one affected party. The old habit depended on a smaller audience than the current system has.

Follow the consequence carefully. The problem is not that a conversation happened. It is that the decision’s reach became wider than the conversation’s reach. The replacement should address that mismatch rather than introduce paperwork everywhere.

A useful design document makes the decision understandable to people who were not present. The guide to influencing a design helps with the discussion that follows when those people raise a real constraint.

Test a replacement without abandoning judgement

For the next bounded interface change, the engineer proposes a small replacement routine: identify affected consumers, record the intended behaviour and compatibility assumption, and ask the relevant owners to review the part that affects them before implementation.

This is not a rule that every edit needs a committee. The engineer and team define which changes need the wider check. A private refactoring with no externally visible effect may follow the usual local review process. The decision boundary matters more than the document’s length.

Agree what would count as useful evidence. Did the right people see the decision in time? Did a previously missing constraint emerge? Could someone who missed the meeting understand what was agreed? Do not use “nobody complained” as the only measure; silence can also mean people did not know where to look.

Keep the experiment small enough to revise. A replacement that introduces unnecessary waiting may need adjustment. The aim is to preserve the useful speed of direct conversation while fixing the information gap, not to replace one rigid habit with another.

Do not blame a habit for a structural problem

Check whether the desired behaviour is supported. If nobody knows who owns the consuming systems, the engineer needs an ownership decision, not a lecture about communication. If deadlines reward immediate delivery while penalising coordination time, the team needs to address that conflict.

Likewise, a newcomer may be following the process they were explicitly taught. Do not turn a missing organisational agreement into a personal character defect. Explain what changed and supply the authority, information, or time needed to act differently.

Some established habits are safety constraints, not mere preferences. Do not remove a review, access control, or compliance step on the theory that “unlearning” is always progress. Understand the purpose and obtain the appropriate decision before changing it.

Keep the part of your experience that still works

After the trial, state the revised rule with its condition: “For externally visible changes, I check affected consumers and record the agreement. For local changes within the established boundary, I use the normal review path.” That is more useful than declaring that you have become a different kind of engineer.

Your previous experience still helps you ask good questions and recognise trade-offs. You are updating where and how you apply it. Use a concrete feedback conversation if you need help identifying the habit, and a development one-to-one to agree the support for changing it.

The practical test is whether you can explain what the old habit was optimising for, what changed, and why the replacement fits better. Without that explanation, “unlearn” risks becoming another vague instruction to improve.