In any professional setting, conflicts will inevitably arise, and once in a while, you’re going to find yourself having to tell someone they’re wrong. There are a number of ways to correct someone: You might be able to prove it out with a visual example. Or you could gather together best practices or a body of evidence showing how others are addressing a problem and the reasons why. Sometimes it helps to escalate the problem and have your boss make a judgement or, if you’re on different teams with the other person, talk to their boss.

Despite these options, the person with whom you’re disagreeing may still not want to listen to you beyond all reason. This can be challenging, because the more someone digs in their heels, the more work it takes to overcome their biases, and the more they feel like an opponent, instead of a co-worker. For small, task-level decisions, these points of contention may not be a deal-breaker. My team has adopted the phrase, “That’s not a hill I’m going to die on,” meaning in this battle, I can lose these small skirmishes here and there but overall, at least we’re still creating a better product in the end.

Once or twice in my career, however, I’ve run into big, project-level problems, where the lead has chosen a strategy that’s doomed from the beginning (or perhaps has failed to choose a strategy at all). In these cases, it feels less like a series of disagreements and more like a mountain climb: you’re either going to get to the top or you won’t. And even if you do, you’ve spent too much time proving your expertise, had too many arguments, and you’ve just generally put so much energy into the problem, you don’t feel good about it once you get there.

If you’re doing work for hire, you’ve probably crossed the line where you should fire your client. If they’re hiring you for your expertise, but they’re not listening to it, then there’s no point in continuing to clock the hours. If you’re working in-house, however, you don’t necessarily have the luxury of saying goodbye forever to your clients. Like it or not, they’re part of your team. But there is one more piece of advice I can offer up.

Let it fail

It’s hard to admit, and it took me a long time to learn it in the first place. Nobody wants the project they’re working on to fail, especially when you know in your heart of hearts that you can fix it if only you’d be given the chance. But if your environment is in your favor—your boss supports you, and you have a proven track record of making a good faith effort, and you have some flexibility—sometimes you have to let the project go, let nature run its course, and wait for them to come back to you. Let me illustrate what I’m talking about.

I worked on a long-term project that was succeeding in spite of the project owner’s constant meddling only because of a herculean effort from me and my team constantly preventing it from going off the rails. I’ll call it Project A. I spent a tremendous amount of energy designing the experience and helping to write the content for Project A, and most of the time, I felt like I was swimming upstream. Early on, we had the client determine their audience and goals, a process that gets stakeholders on the same page and informs the design and content. Even with this tool, we had to constantly remind the client of their own stated objectives. Every step of the way felt like a battle as we tried push a cohesive strategy through. But at least it was a war my team felt like we were winning.

By the time the project was finished, I felt like it was in a good place. Not perfect, but a clear improvement, and a good jumping off point for future iterations. But just three months later, much of that work had been undone. The tone of voice had been re-written to please the client instead of their audience, and even then it was inconsistent. Wandering content was added to address edge cases so that they could avoid a handful of support phone calls per year. UI components were being abused for purposes beyond what was intended. In short, the project was once again no longer serving the needs of its audience, nor the even the goals of the client.

We ran usability studies that proved that out. So, the project was re-opened and it was once more into the breach. The trouble is, the client didn’t learn their lesson, and we found ourselves fighting familiar battles. But at least after another gruelling set of work-sessions we had restored the pages to their former glory. Heck, we had even learned a few things along the way, so it was maybe even better than before. We patted ourselves on the back, and handed it back off to the client, and called it a job well done.

I’m sure you can guess where this is going. The saying goes, “Fool me once, shame on you; fool me twice, shame on me.” For me, it was “Fool me a third time, I give up.” I really wanted Project A to succeed. It would have been good for my client, for sure, and personally, I could see how my contributions would improve the experience for the user—everybody would win. But as long as the project was under the control of that lead, I couldn’t see a way forward. If all the work I was doing was going to be undone, what was the point of doing it in the first place? It came as a difficult decision, but I decided to bow out of the project altogether.

I talked about it with my manager (who, to be clear, was not the project manager), and they understood. Even so, I had to remain steadfast through every new usability study, because there were clearly changes that needed to be made. Easy changes. If I just have five minutes… The reality was, however, that we no longer had the power to make those changes, and truly, we never did.

I did get requests to update the UI for new seasons, and I dutifully made the necessary changes, though it pained me to do so. Much as I wanted to slip in an improvement here and there, I restrained myself. I didn’t even make an effort to patch the mess that had become of my clever UI. I just silently made the update, then closed the code editor. It was frustrating, because it seemed like nobody (but my team) cared that it was terrible work—for years!

At long last, someone did care. Problems with the project finally became clear to senior staff, and when my team was approached to fix it, we suddenly found ourselves in a position to negotiate better terms for our involvement. We had more than two years to build a case for a real strategy, not to mention using that time to pursue more successful projects, which reinforced our expertise all the more.

I’ve had to give up on hopeless projects a couple of times now, and while it always feels like losing at first, letting a project fail doesn’t necessarily mean that I am a failure as a designer, as a worker, or as a person. It’s actually freeing to be able to let go of these time and energy vampires. I can then spend those reserves working on more successful and rewarding projects instead.

You still have to do your work!

There are some caveats that I should mention, just to cover my own ass, lest I lead you to do something rash.

Assuming all else is equal and you’re not asked to do anything unethical, do not take your ball and go home just because you don’t like a project or a request. When work needed to be done on Project A, I still did what was asked of me. I just didn’t give any further input on additional improvements while I was in there. If you want to be successful, you have to meet your boss’s expectations. If they expect you to put in time on a project, you better get the work done—even if you feel like Sisyphus. Don’t do something that will jeopardize your job on principle alone.

If, on a given project, you are the manager or if the proverbial buck otherwise stops with you, letting your project fail is not an option. Your job is, in fact, to make the product succeed. On the other hand, if you find your staffers or contractors giving up on your project, you might want to evaluate why that is.