============================================================ nat.io // BLOG POST ============================================================ TITLE: The Things I Was Wrong About: Thirty Years of Updating My Mind DATE: July 27, 2026 AUTHOR: Nat Currier TAGS: Engineering, Leadership, Career, Systems Thinking ------------------------------------------------------------ I recently found an old architecture diagram. It was dense, symmetrical, and clearly made by someone who wanted the viewer to understand that serious thinking had occurred. Boxes were nested inside other boxes. Arrows crossed boundaries with the confidence of international shipping routes. Every concept had a place, every place had a name, and the whole thing carried the visual authority of a system that believed it had anticipated the future. I remember being proud of diagrams like that. The technology is now mostly obsolete, but that did not bother me. Technology ages, and architecture should be judged inside the constraints that produced it. What stayed with me was the certainty. I could see more than a design in those boxes. I could see a career learning what the world rewarded. Write the code nobody else could write. Work until the problem yields. Enter the room with an answer. Anticipate the failure. Carry the uncertainty. Make the complicated thing look controlled. Those beliefs were not random mistakes. They helped me become useful, then senior, then trusted with decisions that affected systems, organizations, and people. Each one produced evidence that it worked before experience revealed the cost of applying it everywhere. Failure is often easy to question. Success is harder. Success turns a method into a reputation, then quietly turns the reputation into an identity. I left the file open longer than the diagram deserved. The artifact had aged honestly. The beliefs that shaped it had once felt too useful to question. That was the part I had been wrong about. > **Thesis:** The hardest beliefs I have had to outgrow are the ones that first made me successful, because revising them meant questioning not only an answer but the identity and authority I had built around it. > **Why now:** Technical change keeps shortening the life of our answers while experience, status, and responsibility make those answers feel increasingly personal. > **Who should care:** Experienced technologists, emerging leaders, founders, and anyone whose most rewarded habits may have outlived the conditions that made them useful. > **Bottom line:** Mature judgment requires more than learning from failure; it requires noticing when a strength has become a constraint and changing it without denying either its value or its consequences. This is the first essay in a series called _The Things I Was Wrong About_. It is not an inventory of embarrassments. I do not believe growth requires insulting the person who had less evidence. Many of my earlier beliefs were reasonable responses to the work, incentives, and responsibility in front of me. The more difficult question is what happens when a reasonable belief keeps operating after its boundary has moved. By updating a belief, I mean changing the model I use to make decisions after new evidence, repeated consequence, or a better explanation shows that the old model no longer accounts for enough of reality. My oldest models did not fail all at once. They formed a sequence. The beliefs that made me competent prepared the beliefs that made me senior. The beliefs that made me senior prepared the beliefs that made me indispensable. By the time the pattern became visible, I had nearly thirty years of reasons to trust it. [ What made me useful eventually narrowed what I could see ] ------------------------------------------------------------------ Early in my career, code offered a clean relationship between effort and value. I could think about a problem for hours, but until something ran, the thinking remained private. Code made intention executable. It automated work, connected systems, and gave one person leverage across thousands of users. It also made progress legible. I wrote code, therefore I was an engineer. Better code meant I was becoming a better engineer. When I stayed with a problem longer, I often learned more. When I made another pass, I sometimes caught the defect. When I understood a system that had confused me the week before, I had evidence that effort was changing who I could become. Technical mastery created mobility, confidence, and a place in the profession. Hard work changed my life. Complexity often marked the edge of what I had finally learned to understand. The lesson seemed obvious: more technical ability, more effort, and more complete models produced better work. For a while, they did. Then I watched excellent code solve the wrong problem. I watched a technically inferior system succeed because the team understood the user, the constraint, and the moment better. I saw weeks of engineering work disappear after one honest conversation revealed that two groups had been using the same word for different needs. I also saw the cost begin to appear inside the work itself. Another pass could make an implementation cleaner while delaying the feedback that would have corrected its direction. Continued effort could make a decision feel more valuable because I had invested in it. Complexity could create status for the people who understood it and dependence for everyone else. The old diagram captured that period perfectly. Its completeness looked like rigor because I had learned how much rigor technical work required. What I had not yet learned was that a complete-looking model can also make incomplete knowledge less visible.
Conceptual illustration of an elaborate brass mechanism and a spare mechanism operating identical balanced lifts in a bright workshop.
I still love code. I still believe difficult work sometimes deserves unusual intensity. I still respect systems capable of representing difficult conditions. The correction is not that people matter and code does not, or that every complicated system is a failure of taste. The correction is where value begins. Code is one of the ways a group of people makes its understanding executable. Its value depends on the quality of that understanding, the honesty of the constraints, and the relationships that allow the system to change after the original author is gone. Simplicity is not few components at any cost. It is comprehensibility in service of change. A system is simpler when the people responsible for it can form an accurate model, predict the important consequences of a modification, and remove what no longer belongs. Effort has to be judged by the quality of attention it creates. There are periods when sustained intensity is appropriate, but exhaustion is not proof of seriousness. A person who cannot recover eventually makes decisions with a smaller mind. The first belief I had to outgrow was not that technical excellence matters. It was that technical excellence could decide what mattered by itself. Sometimes the highest-value technical contribution is code. Sometimes it is the question that prevents the code from needing to exist. [ Architecture changed when I stopped seeing only software ] ------------------------------------------------------------------ The architecture work I first admired appeared to happen above ordinary conversation. It dealt with scale, boundaries, protocols, consistency, failure modes, and the difficult properties of distributed systems. The architect saw across components and time. If the technical relationships were represented precisely enough, the architecture would become clear. Then I watched architectures encounter organizations. A boundary that looked clean in a diagram placed one team's urgent change behind another team's backlog. A shared service reduced duplicated code and created a negotiation for every release. A flexible abstraction allowed many possible futures and made the current behavior difficult for anyone to explain. Once I stopped looking only at the arrows, the diagram changed. Every box had an owner. Every arrow crossed a relationship. A service boundary was also a promise between groups. An interface said who was allowed to change what without asking. A data model decided whose language became structural. Operational ownership determined whether the component with the most elegant design received attention at two in the morning. Architecture is partly the distribution of future conversations. That realization arrived as my own role was changing. Early in my career, I met senior engineers who appeared to know immediately what the rest of us had not yet understood. Their speed felt like certainty. I wanted to become the person who could enter a room and know. Eventually, people began looking at me that way. Sometimes I did know. Pattern recognition is real, and decades of consequence make some mistakes visible earlier. Experience should save other people from having to rediscover every failure personally. But the more consequential the decision, the less likely the answer belonged to one discipline or one person. Business conditions, human behavior, technical constraints, power, timing, and events that had not agreed to become knowable all entered the model. The confidence expected from the role could prevent useful evidence from reaching it. Some of the most senior-sounding statements I heard were defenses against being seen thinking. Certainty made disagreement expensive because nobody wanted to challenge the person whose title appeared to require complete understanding. The senior people I trust most now identify which unknown changes the decision. They separate a strong opinion from a verified fact. They can say, “This is my current view, and this is what would change it,” without weakening the group's ability to act. Research on intellectual humility gives useful language to that capability. A [four-study paper](https://journals.sagepub.com/doi/10.1177/0146167217697695) described intellectual humility as recognizing that one's beliefs might be wrong and found relationships with curiosity, openness, tolerance of ambiguity, and lower dogmatism. The research does not prove that a humble person will reach the right answer. It supports something more practical: fallibility can be noticed without dissolving conviction. My current belief is that architecture is communication made durable through technical constraints, and seniority is responsibility for the quality of the questions and the calibration of the decision. The diagram still matters. So do the people who must use it to disagree. [ Indispensability can become a system defect ] ------------------------------------------------------------ Responsibility has always felt moral to me. If I could prevent avoidable pain, catch a risk, or absorb uncertainty so another person could remain focused, I believed I should. In leadership, this often looked useful because teams genuinely need protection from chaotic priorities, irrelevant conflict, and organizational noise. The belief expanded quietly. Protection became anticipating every failure. Support became solving before someone had to struggle. Leadership became accepting responsibility faster than other people could develop it. I was strongest when the system needed strength, and then surprised when the system kept needing mine. Success reinforced the arrangement. The person who can be trusted with a difficult problem receives more difficult problems. The leader who remains calm during uncertainty becomes the place uncertainty is sent. Being needed provides identity, access, and daily evidence of value. It also makes the cost easy to misread. Indispensability can feel responsible even when it is preventing the surrounding system from becoming strong. This is one of the beliefs I have been revising most recently. I explored its internal side in [I Mistook Anxiety for Personality](/blog/i-mistook-anxiety-for-personality) and its social side in [The Loneliness of Responsibility](/blog/the-loneliness-of-responsibility). The common thread is that carrying more can look like care while reducing choice for everyone involved. Other people cannot develop judgment around consequences they are never allowed to carry. A team protected from every difficult conversation does not become safer. A person whose mistakes are quietly corrected may look successful while receiving none of the information required for growth. A leader who accepts every escalation teaches the organization where ownership truly lives. For years, I thought respect required projecting confidence. People should not have to absorb a leader's unresolved thinking. That principle still contains truth, especially where power is unequal. But confidence without visible uncertainty can make other people distrust their own accurate questions. My current belief is that protection means building strength around the burden. That includes context, authority, honest boundaries, and support after a decision. It includes saying what remains uncertain without asking someone else to make the uncertainty emotionally comfortable. It includes allowing another person's approach to be different and still sound. The responsible leader is not the person who carries everything. It is the person who makes responsibility possible for more people. This correction changed how I understand mentorship too. The durable result is not another person who can reproduce my answer. It is someone who can exercise judgment without needing my permission, then help another person do the same. That is the argument behind [Why I Mentor](/blog/why-i-mentor). The career markers around this progression were real. Titles described growing responsibility. Loyalty allowed me to see decisions mature over years rather than quarters. Achievement created satisfaction, security, access, and moments of genuine joy. What they could not do was answer a private question. They could tell me what responsibility I held. They could not tell me whether the problem was still meaningful, whether the relationship between effort and life remained acceptable, or whether staying had become a substitute for deciding. I had expected professional success to create a stable form of happiness. It could create options. It could not decide whether I was allowed to be content. The higher the title, the more the role tried to tell me what should matter. I now care less about whether a problem is prestigious and more about whether it is real, whether I can contribute, and whether the people around it can work with honesty. A career is part of a life, not the instrument that proves the life has value. That belief sounds obvious when written plainly. It was not obvious while the earlier model was still producing success. [ Success can preserve an obsolete model ] ------------------------------------------------------------ The diagram bothered me because it showed how a strength becomes a constraint without announcing the transition. Code had proved value. Architecture had proved foresight. Effort had proved commitment. Calm had proved leadership. Titles had proved progress. Together, they formed a story in which confidence came from assembling enough evidence that doubt no longer deserved a voice. Certainty felt stable. It also made correction expensive because a challenged conclusion could feel like a challenged identity. This is how expertise can become a trap. A person accumulates real knowledge and receives authority because of it. People expect a position. The position becomes associated with competence. New evidence arrives, but revision now threatens not only the answer. It threatens the story explaining why the person should be trusted. The dangerous response is to defend the story. I have done versions of that. I have continued thinking because stopping felt careless. I have remained committed because prior effort made reconsideration feel like waste. I have treated visible struggle as evidence that resilience had failed, then kept the struggle private so the role could remain intact. Those choices are connected. Perfection, certainty, and invisible endurance all promise that enough control can protect identity from an unfinished reality. My life did not cooperate with that model. There have been periods when continuing required help, rest, repair, or a changed plan. There have been moments when strength meant admitting that the existing method of continuation was causing additional damage. Resilience was not the absence of struggle. It was the decision to remain in a meaningful relationship with the future, even when that required becoming different from the person who made the original plan. My current belief is that confidence is comfort with accountable revision. It is the ability to say what I believe, act in proportion to the evidence, and make the assumptions visible enough that another person can challenge them. It is also the ability to remain responsible for an earlier decision after changing the belief that produced it. The past does not disappear because the model improves. People may have paid for the old belief. Systems may still contain it. Trust may require repair. “I have changed my mind” is the beginning of accountability, not its conclusion.
Conceptual illustration of hands replacing one misaligned wooden joint in a long working bridge while older repaired joints remain visible.
[ Changing your mind is not automatically growth ] ------------------------------------------------------------ There is a flattering version of intellectual humility in which every revision becomes evidence of sophistication. I do not trust it. People change positions for fashion, belonging, fear, convenience, and access. A new belief can be less accurate than the old one. Indecision can borrow the language of nuance. Avoiding commitment can look thoughtful when the real motive is avoiding consequence. Some convictions should be difficult to move. Integrity, human dignity, and the obligation to use power responsibly should not fluctuate with the incentives of a room. Even technical beliefs sometimes deserve defense when the new proposal is merely novel, politically useful, or easier to sell rather than better supported. Updating needs a standard. For me, the strongest signals are new evidence, repeated consequence the old model cannot explain, or a better model that predicts and organizes reality with fewer distortions. Social disagreement may prompt examination, but disagreement alone does not decide the result. A [two-study paper on intellectual humility and false beliefs](https://pubmed.ncbi.nlm.nih.gov/38421055/) found that participants with higher intellectual humility explored more opposing information, while the findings for actual belief revision were encouraging but mixed. I appreciate that result because it resists a tidy moral. Recognizing fallibility can improve the search without guaranteeing the correction. The standard also includes consequence. If a belief made a decision possible, and that decision affected people, revising the belief does not cancel the responsibility. Growth without repair can become a way of centering the leader's development over everyone who lived with the earlier mistake. This is why I prefer the language of maintenance. A working model requires inspection. Assumptions need to remain visible. Failures need to be traced. Components that no longer fit must be replaced without pretending the previous system never existed. The old architecture diagram is still valuable to me. It records a way I once understood complexity. It shows what I had learned and what I had not yet learned. I do not need to destroy it to prove I have changed. I need to understand which assumptions I would refuse today and remain curious about which assumptions I still cannot see. [ I hope I am wrong again ] ------------------------------------------------------------ Nearly thirty years in technology have not made me skeptical of everything. They have made me more selective about certainty. I still hold strong views. I believe technical excellence matters. I believe clear ownership matters. I believe people deserve honest feedback, systems should be understandable, and leaders are responsible for the environments their decisions create. These beliefs guide action now. I hope they are expressed with enough clarity that future evidence can find them. Ten years from now, I want to write the next version of this essay. I want to name something I currently believe, explain how it helped me, identify the moment it stopped explaining enough, and show where the correction changed more than my vocabulary. The goal is not to be right forever. It is to remain in a relationship with evidence, consequence, and other people that makes being less wrong possible. The old diagram tried to contain the system. Experience has taught me to value a different kind of architecture: one with visible assumptions, reversible decisions, room for disagreement, and enough humility to change when the world refuses to match the boxes.