The dangers of saying ‘no’ in martech

I’ve heard many a story about people who have decided to spend a day saying “yes” to everything and anything.

There are very real dangers in saying “no” in the marketing technology and operations space. However, let me clearly state that there are certainly times and good reasons for saying “no.”

Nevertheless, there are real consequences of earning a reputation as a dream killer or wall of no. Maintaining positive relationships matters. 

Where there’s a will, there’s a way

During my career, I have seen scenarios where a stakeholder needed, for example, a project management solution. But instead of coming to the marketing technology and operations folks, they went with a tool with a free tier like Asana or Trello. 

Sometimes they used their work email address. Other times, they used a personal email address. In some cases, they used the personal email address inadvertently, as that’s the Google account they were logged into at the time. 

There are so many other types of systems where I’ve seen something like this occur — like Google Analytics, for example. The user then inevitably invites team members and other colleagues to join them in using the unvetted system. 

It is important to point out that in the vast majority of cases, such instigators aren’t trying to foil the best intentions of the martech and MOps teams. Nor are they trying to violate the company’s IT security policies or increase the risk of a data breach. 

They simply have a need and have found a free and easy solution for that need. In many cases, they can justifiably argue that the information involved isn’t that sensitive.

They may or may not have deliberately avoided oversight. Sometimes they act out of ignorance, while other times, it is indeed done to avoid bureaucracy.

While I’m sure that not all such instances are brought to light, I’ve seen many draw attention. When they are brought to light, the marketing technology and operations folks are understandably frustrated. 

The legal and IT security teams are alarmed and typically take measures like blocking company email addresses from being used with the service or blocking the service from the company’s network. Needless to say, drama ensues. Fun.

And let’s not forget all those times when a stakeholder finds a great solution and gets a senior executive to approve it before the ops folks even learn about it.

They either have a need and found a solution or feel that bringing the need to the tech and ops folks will slow them down from helping the overall organization. It is important to harness the Most Respectful Interpretation principle at such times.

Such messes could have started for a number of reasons, but one of them likely is that the instigator was either told “no” or expected to be told “no.” Besides, sometimes repenting after the fact is easier than asking for permission first. Further, as a disclosure, I don’t like it when people tell me “no” as well. 

Dig deeper: The secret to building a useful martech stack

Preventing messes when ‘yes’ isn’t on the cards

There are certainly times and reasons when “yes” isn’t a viable answer. That makes it really tough to avoid situations like I’ve explained above. However, some tactics can help.

An important objective is to persuade stakeholders that as marketing technology and operations professionals, we aim to help others succeed — and to do so often and spectacularly. 

We don’t slow things down to make careful and thorough deliberations as a power trip, sabotage, or just for fun. 

We are bringing a bigger-picture perspective and understanding of tactical and in-the-weeds details involved in pursuing any system or initiative.

We can convey this by following some tenets of the agile philosophy. 

A crucial tenet is transparency. If we can provide backlogs and Kanban boards, stakeholders can understand all that’s on our plates. 

If, instead of saying “no,” we sit down with the stakeholder to gather requirements and use cases, we can walk through some of the challenges or issues that will arise. 

For instance, if a new system needs to integrate well with the CRM, we can work with the stakeholder to see if their desired solution does that well. If it doesn’t, then the stakeholder should have a better understanding of why the answer may end up a “no.”

Another concept that the agile philosophy allows for is iteration. Perhaps a stakeholder has a big ask that others may not have bought into yet. 

However, through iteration, a minimal viable product (MVP) or setup could reveal if the bigger ask is worth pursuing. This is when a proof of concept can come into play. 

Further, in regard to UX matters, a multivariate testing tool can also provide an easy way to try something out without much effort or commitment.

If an MVP, proof of concept or A/B test yields poor or questionable results, then hopefully, the stakeholder will better understand why their request isn’t fulfilled. 

Sometimes “let’s test that” is an even better answer than “yes,” all while avoiding the dangers of saying “no.”

Dig deeper: 3 pointers to navigate the confusing martech marketplace

More people could say ‘no’

It is crucial for martech and MOps professionals to understand how to handle such requests, as more people can kill an idea. 

As I mentioned, legal and IT security are two prominent players in martech plans. Other actors can include finance, clients, vendors, boards of directors, regulators, partners, device manufacturers — and even customers. That is why fostering positive relationships is so important.

When we engage stakeholders by gathering requirements and accounting for numerous issues upfront, we can prepare the idea for the inevitable scrutiny from stakeholders outside of marketing. 

This can help build confidence in the stakeholder that their tech and operations colleagues are indeed looking out for them.

Avoid the pitfalls of ‘no’

We’ve all been there when either a colleague started using an unvetted system or got blindsided by a stakeholder gaining senior management approval for a solution that we learned about after it was approved and procured. 

While stakeholders’ understandable fear of us saying “no” isn’t the only cause of such incidents, it can certainly play a role. 

We don’t have to say “yes” to everything to avoid the dangers of “no.” However, by using “let’s test that” or “maybe” and including stakeholders in the deliberation that arrives at “no,” we can hopefully enable them to understand the bigger picture and why their desire isn’t viable at the moment. 

Perhaps deliberations may reveal an even better solution requiring less effort. That way, they can view us as allies committed to helping them succeed.