I recently wrote about why it’s so hard for a client to adopt a new tool, and how to work with that resistance (link below) Today, we’re talking about something else: about when it’s no longer that they’re struggling, it’s that asomeone is working to make it fail.

Direction had purchased the tool with enthusiasm. Finally they were going to have data from a part of the operation that until then lived in the heads of a few people—like how long projects really took to implement, where the work really got stuck, and what quality was being delivered.

Our job was to deploy, but for that, we needed the person who led that operation, we needed the client but that person didn’t want the tool. They never said it, of course, the truth is nobody ever says it and instead of telling us, what they did was something else:

• When we showed them the data, they said it was wrong.
• When we brought a proposal, they threw it out. Any proposal, even those that didn’t affect them.
• A minor error in a report became something unacceptable that stopped the whole meeting.

And there came a point when the sessions end with shouting and with that closed defense of someone who isn’t arguing about a datum, but protecting something. Because that’s what was happening, that tool didn’t give them visibility, it didn’t give them the exposure they wanted, it was going to show, with numbers and in front of their bosses, things about their work that until then only existed in their version and that they never shared.

For weeks we did what you do: insist, reschedule, ask again for the data for configuration and deployment, prepare the next session better, just in case the problem was ours.

It wasn’t our problem. And the mistake wasn’t not noticing, because we noticed quite early; the mistake was what we did after, what we let go and didn’t want to look at either.

---

How you recognize it

The signal isn’t that they question something but the disproportion in those meetings. When the reaction bears no relation in scale to the fact, you’re no longer facing a technical judgment, because a minor error doesn’t paralyze a two-hour meeting, unless it suits someone that the meeting is paralyzed and your product’s credibility is undermined.

Three things I look at today:

• Indiscriminate rejection. It’s not that one proposal is rejected, it’s that all are rejected, even those that don’t concern them. If nothing is ever good, the problem isn’t the proposals.
• Emotional disproportionality. Shouting, personal defense, rising tone. That isn’t produced by a disagreement about a datum. It’s produced by feeling at risk.
• The data is always wrong. Not the process, not the approach. The data. Arguing about the thermometer is the most effective way to never talk about the fever.

And one that almost nobody says out loud: if someone is shouting at your CSM, this has stopped being a project problem. It’s a decision about what you expose your team to. A leader who sees it and responds “keep insisting” is making that decision, even if they don’t call it that.

---

The real problem wasn’t him

When we became aware of the situation, we escalated it and discussed it with his superior. Dealing with it with his superior we found two things that surprised us even more:

1. He didn’t have real leeway to get into analyzing what was happening,
2. He already knew he had a detractor, he knew and preferred not to look at it, because looking at it would force him to act.

And faced with a situation like that we asked ourselves internally, what could we do? What situation were we in regarding their adoption and renewal? That was the moment we saw the real problem: it wasn’t that we had a person sabotaging the project, it was that we didn’t have real sponsorship to unblock it.

With the superior we routinely had meetings, periodic updates that seemed sufficient and we left with a good feeling, with a sense of success, until we faced the reality with a real blockage and we had no one.

And the difference of having a real promoter or not decides everything. A sponsor isn’t there to know how the project is going; for that you have an informed stakeholder. They’re there to decide when someone has to decide, and to say out loud, in front of the team, that this is a priority and that from now on it will be done this way. That sentence sometimes is the only thing that unblocks six weeks of follow-up.

---

Four things I learned by doing them wrong

1. That I was using follow-up for everything. When a project doesn’t move forward, the default response is always the same: insist. And it only works in one case, when the client wants your product. If what’s missing is someone to decide, insisting only delays the problem. Before sending another reminder, the useful question is what’s really missing here: time, will, or someone with authority? Mine was the third disguised as the second, and that’s why none of my weeks of insistence served any purpose.
2. That I was escalating people instead of decisions. There’s a huge difference between saying that So-and-so isn’t collaborating and saying that the integration has been six weeks without an owner and you need to decide who will take it before the 15th to keep the date. In the first, So-and-so is the problem, you sound like a complaint and you force the sponsor to arbitrate who’s exaggerating. In the second there’s a pending decision blocking a project, and the sponsor can do what you need them for: decide. Before escalating, ask yourself what decision isn’t being made.
3. That I hadn’t opened the channel until I had the problem. For weeks you only talk with the operational team, and suddenly you ask for a meeting with leadership. For you that means you need help to unblock, but for the person you’ve been working with for six weeks it can mean something very different: I’m calling your boss because you haven’t done what you were supposed to. If from the start there’s a periodic review of progress, risks, and pending decisions, when the problem arrives you don’t open a new route, you use the one that already existed and it doesn’t hurt as much.
4. That I had nothing agreed in writing. Neither risk criteria nor a rule for notice. And with an active detractor, that’s costly. Giving notice before escalating avoids a lot of conflict and, even if it sounds aggressive, the “I’m going to take this to Thursday’s committee because we’ve been blocked for six weeks, I wanted to tell you first”, and often unblocks things without needing to escalate, because knowing something will be reviewed on Thursday changes the situation. But with someone who sabotages you have to do it in writing and in project terms, because they may get to it before you with their version and you don’t want the decision to depend on two conflicting narratives. You can use a traffic-light system with the client but define what red and yellow mean to avoid “interpretation.”

These four things have something in common: none can be put together once there’s already conflict and I know it from experience, and although when we tested the proposal with subsequent clients it sounded a bit “exaggerated,” this shielded us because we already knew our product could hurt.

And from now on we sought to secure a real sponsor, with a channel open from day one, transparently and a prior-notice rule that I advise you to carry into your next kick-off: if a key person doesn’t collaborate or this gets blocked, who decides? If the answer has a name, you have a sponsor. If it’s “well, we’d see that later,” you have a postponed problem that will cost you dearly.

How to probe your product before real problems arise? Bring your problem to your sponsor and watch how they react the first time you bring them something uncomfortable, when it’s still small. There you have your answer.

---

How it ended, and what it costs

I’ll tell you how the story ended, because if today I bring you an anecdote it’s to take it to the end. We ended up escalating to the superior of the superior.

It worked. The project was unblocked.

And it was a very complicated situation, one you’d do well not to repeat, because jumping two levels isn’t free.

Client: You burn the person who blocks, obviously, but you also burn their superior, who’s exposed as someone who didn’t manage their area.

You: you come off as the vendor who went over two people and you pay for that in the coming months as they scrutinize you and your product’s credibility is felt.

If you lead a team, the advice I’d give is don’t expose the CSM to such cases without tools, without sending emails with no responses and saying to keep insisting one more time, because a moment will come that will complicate your relationship a lot—yes, yours—because the CSM will have to escalate it. To avoid that, create an escalation system with early alerts as you can see in the article.

---

Next action: Now open a blocked account

Think of one that hasn’t progressed in weeks. Don’t start by writing who’s failing, instead write these three things:

• What decision is pending.
• Who really has the authority to make it.
• What will happen if it’s not resolved before a specific date.

And then a fourth: is there an agreed mechanism to make that blockage visible?

What pending decision are you trying to resolve right now with another follow-up email?