Every organization has them—those strange, singular challenges that emerge once and never repeat. A merger with a company in a completely different industry. A once-in-a-decade regulatory shift. A crisis born from a unique confluence of factors that won't align again.

The instinct, especially for systematic thinkers, is to build infrastructure around every problem. Create a process. Document everything. Build for reuse. But this instinct can become a trap. Not every problem deserves a system. Some problems deserve only enough structure to solve them well, and nothing more.

The art lies in recognizing which problems are truly one-time events, building just enough scaffolding to address them effectively, and extracting whatever transferable wisdom exists before moving on. This is a different discipline than systematic problem-solving—it's the discipline of appropriate response.

The first question isn't 'How do I solve this?' but 'Will I ever face this again?' This distinction sounds obvious, but it's remarkably easy to get wrong in both directions. We build elaborate systems for problems that never recur, and we improvise our way through challenges that are actually part of a hidden pattern.

Start by examining the problem's structural components. A product recall might feel unique, but recalls themselves follow patterns. The specific defect may never recur, but the general shape of the challenge—rapid response, stakeholder communication, logistics coordination—likely will. Conversely, integrating two companies after a merger truly is singular. Even if you acquire again, the specific cultural dynamics, technical systems, and human factors will be entirely different.

Ask three diagnostic questions: What percentage of this problem is situational versus structural? If most complexity comes from specific circumstances that won't repeat, it's genuinely one-time. How often does my organization face problems in this general category? If the answer is 'rarely' or 'never before,' don't build infrastructure. What would I actually reuse? Be honest. A detailed playbook for this exact situation helps no one if the situation won't recur.

The goal isn't to eliminate all process-building—it's to match investment to expected return. Building a crisis communication framework makes sense because crises recur. Building a detailed playbook for 'What to do when our CEO and CFO both resign on the same day during a product launch' probably doesn't.

Takeaway

Before investing in systematic solutions, determine whether you're facing an instance of a pattern or a genuine anomaly. The structural features of a problem—not its surface appearance—reveal whether infrastructure investment will pay off.

Once you've identified a truly one-time problem, resist the temptation to over-engineer your response. The goal is minimum viable process—just enough structure to solve the problem well, without building scaffolding you'll never use again.

Think of it as the difference between building a house and setting up a campsite. For permanent habitation, you want solid foundations, proper plumbing, long-term durability. For a single night in the wilderness, you want shelter that works, protection from the elements, and the ability to pack up and leave. Both approaches involve planning. But the planning serves different purposes.

For one-time problems, focus on three elements. First, clear success criteria. Define what 'solved' looks like before you start. Without this, you'll keep refining indefinitely. Second, decision rights. Who can make which calls without escalation? One-time problems often require speed, and unclear authority creates friction. Third, resource boundaries. How much time, money, and attention is this problem worth? Set limits upfront.

What you explicitly don't need: comprehensive documentation for future users, scalable processes that can handle variations, training materials, review cycles designed for iteration. These are valuable for recurring challenges. For one-time problems, they're overhead that slows you down without adding value. Solve it, learn from it, move on.

Takeaway

Match your process investment to the problem's recurrence probability. One-time problems need clear success criteria, decision rights, and resource boundaries—not infrastructure designed for reuse.

Here's the paradox of one-time problems: while the specific situation won't recur, it often contains transferable insights that apply broadly. The art is extracting these without over-investing in documentation that serves no purpose.

Think about what actually transfers. It's rarely the specific solution—that's tailored to circumstances that won't repeat. What transfers is usually at a higher level of abstraction: heuristics about when certain approaches work, warning signs that a situation is about to become complicated, relationship insights about how stakeholders behave under pressure.

After solving a one-time problem, spend thirty minutes—not three hours—answering these questions: What surprised me about how this unfolded? What would I do differently with perfect hindsight? What did I learn about the people or systems involved that I didn't know before? What general principle might this suggest?

Capture these insights in a form you'll actually review. For most people, this isn't a detailed report filed in a document management system. It might be three bullet points in a personal note, a brief conversation with a colleague, or simply reflection during your commute. The format matters less than the practice. One-time problems are expensive teachers. Extract what lessons you can, even if you'll never face the same exam again.

Takeaway

One-time problems teach transferable lessons at a higher level of abstraction than their specific solutions. The insights worth capturing are heuristics, warning signs, and principles—not procedures.

The discipline of one-time problem-solving is fundamentally about proportionality. It asks you to resist the engineer's instinct to systematize everything and the consultant's instinct to document everything. Some problems are meant to be solved and released.

This doesn't mean approaching unique challenges carelessly. It means bringing appropriate intensity—enough structure to succeed, enough reflection to learn, and the wisdom to know when you're done.

The next time you face a strange, singular challenge, pause before building infrastructure. Ask whether you're looking at a pattern or an anomaly. Build just enough process to solve it well. Extract the lessons that transfer. Then move on to problems that deserve more of your attention.