Obvious in Hindsight

Ownership once became the most debated topic in a program around data reconciliation. We had taken ownership of solving the problem. Another team was unhappy with that decision. What followed was a quarter-long debate across teams, leaders, and forums. Eventually, a VP made the call. Everyone aligned, agreed, and we moved on. We spent the next quarter focused on solving the reconciliation problem, assuming the hardest part was behind us. Then came the quarterly review cycle. Out of nowhere, the other team presented three roadmap items. Two were difficult and therefore dropped. The third was conveniently the same data reconciliation problem. In that moment, the principle of working backward from the customer problem disappeared. What had been settled through debate returned through planning. Ownership mattered more than outcome. The visible task mattered more than the actual need. The lesson was simple. Alignment in meetings is not the same as alignment in incentives. If people believ...

An idle mind rarely stays idle. In organizations, empty capacity often gets filled by work that is neither important nor urgent, but is made to feel like both. A shiny abstraction layer, a fashionable initiative, a new framework, a clever platform idea. Once momentum builds, the simple question gets lost: why should we do this now? The answer is often incomplete, vague, or borrowed from trend rather than need. I have seen this in engineering bets around GenAI experiences. Teams rush to build a thin AI abstraction layer for developer productivity while the fundamentals are still unstable—IDE integration is immature, knowledge bases are fragmented, CI/CD is noisy, infrastructure is unreliable. It is like trying to build the transformer before enough Lego blocks exist. Even worse, we may discover later that the real need was not a transformer at all. If the underlying pieces evolve quickly or become trivial, the early abstraction becomes rework. Tenet #3 — Ask: Why Are We Doing This No...

When given a problem, many of us instinctively rush to optimize the solution. We try to think two steps ahead, hoping to set direction early, avoid rework, and create clarity before the facts arrive. It feels intelligent and proactive. But often it is just premature certainty. We mistake movement for progress and guesses for insight. I have seen this in design systems and engineering decisions. If all you can do is lazy-load everything or lazy-load nothing, choose nothing. Not forever—only until the system has enough knowledge to do better. The same applies to testing. If the only option is to run every possible test for every change, it may be better to pause and improve signal quality before brute-forcing scale. Broad actions based on weak signals usually create hidden costs, wasted cycles, and noise that later has to be undone. Tenet #7 — Ambiguous in Foresight, Obvious in Hindsight. In uncertain moments, speculation can look like strategy. Later, it becomes obvious that the smar...

For a long time, I believed wearing emotions up the sleeve was a valid way to work. If something mattered, show passion. If a bad decision was not being reversed fast enough, show frustration. If progress was slow, show urgency. Emotions felt like proof that you cared. I brought that energy into discussions on engineering efficiency, long-term architecture, and pushing back on short-term trade-offs that would hurt the future. Then came the feedback that changed my thinking. It was not that I was wrong on the substance. It was that I had not built enough trust with the new people. My intensity was being felt more than my intent. That was the aha moment. Being emotionally charged may feel authentic, but it often creates friction where alignment is needed. My instinctive reaction after that was to swing to the other extreme—to become cold, detached, and purely transactional. Before I went too far, I realized that would be another mistake. The answer was not emotional volatility, and it wa...

Choosing where to spend your time rarely feels obvious in the moment. I was working across three projects. One was in the center, where I was deeply involved in shaping the solution. The second would need attention in the coming months. The third, on the periphery, was urgent and visible. It had momentum, stakeholders, and pressure. My director suggested I move there. On the surface, it made sense. Urgency usually pulls attention. But the question was not about urgency. It was about what the work actually needed. The peripheral project needed coordination, tracking, and execution discipline. It needed strong program management. It already had capable engineers and managers driving it. My center project was different. It was still ambiguous. It needed technical disambiguation. It needed someone to simplify, make trade-offs, and shape direction. Moving away from it would not reduce risk. It would increase it. That is where the decision became clear, even if it did not feel comfortable....

Most confusing discussions are not about disagreement. They are about mixing levels of abstraction. In the moment, it does not feel that way. It feels like a rich conversation. People are connecting ideas. Strategy, architecture, code, testing, customer impact — all in one flow. Everyone is adding valid points. Yet nothing moves. It is only later that you realize the problem was simple. We were not talking at the same level. I saw this clearly when we were trying to answer a basic question: how do we test an app like Kindle? The discussion quickly spread everywhere. Test infrastructure, CI/CD, build failures, code reviews, regression tests, feature tests, UI tests, non-functional tests, packaging. Each person was right, but from a different layer. AI had made writing code faster, but certification had not caught up. We were not blocked on effort. We were blocked on clarity. The shift was almost embarrassingly simple in hindsight. We grouped everything into clear layers. White-box cer...