I work as an engineer for a Value-Add-Reseller for many different products. In the acronym world that we are so well acquainted with, this is just referred to as a VAR. What does a VAR do? The idea behind a VAR is that we do what product specific vendors cannot. We are able to work across the product specificity of the solutions out there, and combine solutions sets from different vendors that directly speak to customer needs. This means that I may talk on-premises on one day, and cloud on the next. I may speak to VMware, and also Cisco, in the same meeting. The goal at the end of the day is for the customer to be able to access and utilize what they need for their environment. Some people don’t really like VAR’s as they are not as in-depth as product specific vendors, but some really do appreciate the fact that we can combine technologies for a customer to grow their capabilities. Now, with this in mind, the goal of this blog is not about what a VAR is, but instead, what your career/job/position would look like working in a VAR.

For me, one day I am accelerating sales teams, building the next technology elevation, and the next traveling and helping customers figure out problems. When looking at making a move into the VAR, or Vendor space (especially if you are coming from a customer perspective) it can be quite jarring. Lets walk through a couple things that may help soften the landing.

First, if you are an engineer, you no longer matter in the upkeep of the company. You’re now a small part of the overall growth of the company. You may have a number attributed to your area or technology group that you have to meet, so instead of “keeping the lights on” your goal is to “Sell, Sell, Sell.” Now you are no longer single-threaded to maintain, monitor, and scale, but to dynamically change your technology to the needs of the customer and help them realize that solutions for their growth. This can be jarring, because you no longer have management over you telling you what you need to do, or micromanaging you. That being said, you will have mangers telling you to “sell” or to “create” or something along those lines, but they wont have a direct end goal that they point you to. In many cases your managers may lean on you for direction and perspective. I see this more as an operator moving into a “developer” space. You may not write code, or deal with the same frameworks, but you are basically trying to create a practice and a structure that will lead the company to continual growth.

Second, your ability to know the product does not matter as much as your ability to communicate it. This is rough on engineers, because we are so regularly busy trying to show how smart we are. “Hey I did this really cool thing with these three other products!” or “Hey I got the thing tweaked and now the database will run faster!” doesn’t generate any cheers or excitement anymore because no one really cares. Customer want a product, and they want what the product provides. If that is a faster database then they will purchase it off the customers “faster database” criteria. Understanding the criteria of the customer, and the abilities of the product your selling, creates a gap. That gap, is what you need to bridge in your communications. No one cares about the fact that you have 20x certifications, or know how to connect multi-cloud. What they care about is your ability to solve their problems. This is where the ability to communicate is key. I’ll try to dig more into this on a second blog.

Third, understanding execution is critical. Great, you know your product, you know how to communicate it, and the customer buys it… Now what. Its a hilarious statement in sales that “speed kills” but when you get the customer to sign on the line, they need to be on-boarded with the product as fast as the customer will allow. That means your ability to on-board them fast and in a proper manner counts. I’m not saying that you rush things to get a sale and miss the questions you should be asking as your communicating with the customer, I’m saying that if you have done your due diligence then you should know what needs to be done and you should be able to get it done in a timely manner. Its at this point the sales part drops off as they move on to the next customer and the group on the other side of the fence steps in, which is normally Professional Services or Managed Service Provider(MSP).

The idea behind most of these three statements, is understanding your product, communicating appropriately how your product solves problems for your customer, and then solving their problem in a quick and orderly fashion. This leads to the overarching group schema of where you will end up in a VAR or Vendor product company. Sales, Architect, Professional Services(PS), and MSP are places where you may end up, and each group focuses on different aspects from the above mentioned steps. Sales must know how to bring in an architect to scope and scale, and those two must be able to communicate how these will fix problems, and be implemented for PS/MSP. If any part misses the other, then extra calls will be needed and time will be lost.

So, what are these rantings. Well, first, know what you know. Know how to talk about it from a high level down. Second, know how to speak about it. If you have never spoken above your manager level, you may not understand how businesses are ran, and how they only care about making money. I remember showing a technology solution that would change the companies patching process from 3 hours to 1 minute, and the full C-suite didn’t care at all, as it didn’t add money to their bottom line, and 3 hours to patch was status quo and wasn’t a problem to them. Finally, execute. You got every piece in place, now make it happen. This is pretty close to chess. If you have all the piece in place everything just falls into a process until the final end is realized. I’m going to try to build on these in the upcoming weeks. I miss blogging and maybe this is a good topic to cover.