How I Think About Problems as Things That Must End
For a long time, I thought fixing a problem meant assigning it to the right person. If something kept breaking, we gave it an owner. If a process failed, we wrapped a role around it. Ownership felt like progress.
It wasn’t.
What actually happened was more subtle. The problem didn’t disappear. It became well-run. It got dashboards, playbooks, and escalation paths. People did a great job managing it. And somehow, that became the goal.
That’s when I started noticing the difference between projects and jobs. Projects are designed to end. They have a goal, a definition of done, and an awkward moment where everyone agrees the work is over. Jobs are designed to persist. Their success is measured by continuity. If everything keeps working, you’re doing great—even if the original problem is still very much alive.
Once a problem becomes a job, the incentives quietly flip. You’re rewarded for keeping it running, not for making it unnecessary. The system doesn’t need bad intentions to preserve problems. It just needs stable roles.
You see this pattern everywhere. Bugs turn into support responsibilities. Tech debt becomes platform ownership. Broken processes mature into permanent programs. Each step sounds reasonable. Each one adds structure. And each one makes the problem harder to kill.
The shift for me came from asking a slightly uncomfortable question in planning meetings: “Who is accountable for making this problem go away?” Not who owns it. Not who maintains it. Who makes it disappear.
That question changes the room. It forces an end state into the conversation. It exposes whether anyone is actually responsible for closure, or whether we’re just appointing caretakers.
After that, I started looking for finish lines. Clear success criteria. Exit conditions. Dates when the work would stop existing. When those were missing, it was usually a sign we weren’t fixing anything—we were just professionalizing the problem.
Organizations are very good at reviewing performance. They’re much worse at reviewing existence. We ask whether something is running well, not whether it should still be running at all. We reward delivery and reliability. We almost never reward deletion.
But deletion is often the real progress.
The most effective owners I’ve seen aren’t the ones who manage problems forever. They’re the ones who end them. Their success makes the role smaller. Sometimes it makes it unnecessary. That’s not a failure of planning—it’s the point.
Now, when I see a problem that won’t die, I don’t ask who should own it. I ask whether we’ve designed for maintenance or for closure. One leads to elegant stagnation. The other lets the organization move on.
Most problems don’t need better caretakers. They need an ending.