Selling sophisticated data analytics technology to a large bank is a bit different than selling beverages at a lemonade stand to kids playing soccer in your neighbourhood. Sure, the result of the sale may be similar; kids quenching thirst on one hand and network engineers quenching thirst for knowledge on the other. In the end you solve a problem. However, the process of the sale is dimensionally different.
Such a sale for us generally depends on where the request comes from and the driving force behind it. If the business has been affected by a major outage that resonated throughout the firm, it is clear the need is given and the request comes from high above. These reactive kind of deals usually bear fruit much quicker because the issue has been identified and it needs to be solved quickly.
More often than that, we get invited to either solve a niche problem or provide a tool that is somewhat necessary but viewed as “nice to have”. These requirements typically come from lower ranks and call for much more effort to prove our value and to convince the business that they really need us.
It took me a while as a starting solution engineer many years ago to learn how a deal is struck in a corporate environment. Understanding who pulls which strings and where those strings lead is an admirable asset. It requires a thorough knowledge of the organisation, its culture and usually a lot of experience.
And in it I see a problem in the form of a disconnect between the teams on the ground and the business which calls the shots. Far too often a network engineer approaches me after our pre-sales meeting and tells me that if it was up to him he would buy our product right then and there. He is one of the few who truly understands how their network runs, what its shortcomings are, and where it is vulnerable. He is the one who truly understands how extremely helpful such a tool can be. And yet, he typically has very little say in the final decision, which tends to be done by folks far too removed from the reality of daily network problems.
In this case, my network engineer needs to show that such product not only makes his job easier, but more importantly how exactly this product will prevent any possible future failures. In other words, he needs to show how the company, in the long run, saves money or makes more money with this product.
Well, as it turns out, that is not an easy task, especially if you’re putting your reputation (and perhaps your job) on the line. And the same applies to the guy with the fat wallet. However, because he may not be as aware of the lurking issues as the guys on the ground, he may be even more hesitant to approve and dish out the cash. So my network engineer, once presented with the rejection, will grind his teeth, say a couple of curse words and go back to the way things always were.
Now imagine how much more difficult this process becomes when the potential disconnect between these two guys grows exponentially over the bureaucratic spiderweb of various corporate teams.
I’ve seen the same disconnect at small firms where individual teams respond directly to the board as well as large institution banks where you have to climb a very tall ladder to get your final yes.
My point is simple and applies to all. Protect your network at all cost! Trust me, you don’t want to become one of the guys who realise way too late that the “nice to have” could have saved them millions of dollars if they only treated it with highest urgency.