Years ago, in a work meeting, I sat through a presentation about how our development process was broken. The message was: “Instead of using Haskell for everything, we’re going to try other languages.” As a Haskeller myself, this resonated with me completely, and I literally jumped out of my seat and to give my support.
It was a good idea. Haskell is not the best language for everything. I knew that from my data science work, where a one-off package written by a professor for a research paper could provide incredible insight quickly. Being language-agnostic is a powerful principle when success is measured in customer impact.
However, the follow-through proved inconsistent. We created the new project in Rails. Everyone learned it. But over time, the core services stayed in Haskell, and the main result was that developers paid the cost of learning a new language without the organization fully changing around the new principle.
Eventually, the C-level exec came up with the next big idea for how we were wrong and how development was broken. This time, it was: “Everyone needs to write one PR per day.” In isolation, this was also not a crazy idea. Small PRs are faster to review and often lower risk to merge than giant PRs. Frequent shipping is usually better than long-lived branches. But given the spotty follow-through on the previous idea, I realized what was happening.
The leader was surfing from one big idea to the next. Each idea felt right in the moment because it diagnosed something real and came with energy and conviction. But the technical and organizational follow-through was left to someone else. After a few cycles of watching big ideas mostly stay big ideas, my motivation to jump out of my seat went away. The ideas were still good, but the excitement dissipated before any durable change produced receipts.
Salience-driven development is what happens when software teams chase the big idea of the moment.
One problem, one approach, or one solution becomes emotionally dominant. It becomes the thing everyone can see and the thing the team has to fix. Then the next big problem comes along, the previous idea is left half-finished, and no one stops to ask what happened to the last transformation.
The worst version of this happens without accountability. There is no moment where the organization says, “The last time we identified a problem like this, we only half-fixed it.” The main feature of salience-driven development is that every moment feels important in isolation. The team is aligned. The diagnosis feels true. Everyone agrees that fixing the problem should be a priority. But when you only chase the next big thing, the team starts to lose its center, and over time, it begins to spin its wheels.
When everything is important, and you chase a sequence of increasingly salient problems, the net effect is that nothing is important. It becomes Groundhog Day for development teams: today’s topic energizes the room, but the charge never carries forward.
I’ve seen this pattern across startups and software companies. It is the CEO who hears one piece of customer feedback and rallies the whole company in response. It is the CTO chasing the emotional hit of “we only hire brilliant people” or “our development process is better than everyone else.” It is the founder who goes deep on one system, then the next, then the next, without launching any of them to find out whether the end user agrees that they matter.
Salience-driven development is not just a leadership failure. It is also the engineer who surrounds themselves with constant chaos. They ride from incident to process improvement to learning doc to architectural debate, each one urgent and justified on its own terms. What is missing is the boring follow-through that provides the most value. It’s the engineer always living inside the most salient thing, but rarely producing legible outcomes the organization can use.
The solution is remarkably boring. Invest in planning cycles, execute the plan, and make yourself accountable for the outcomes. A saying from my college scuba diving course has stayed with me: “Plan the dive, then dive the plan.” Of course, not all plans survive contact with reality, and not all goals are achievable. Sometimes the known unknowns rock you. Sometimes reality changes. But that is exactly why accountability matters. Accountability to the people around you, to your investors, to your executive team, and most importantly, accountability to your customers and to yourself.
The deeper solution is continuity as infrastructure, which will be the topic of the next article.
When you endeavor to do something great, to build a company, to change how people work, or to change the world, you need more than the next emotionally compelling idea. You need a plan that produces receipts. You need a plan where, six months later, someone can ask a simple question: “Did this work?” And get an answer.