Skip to main content

Training!

As a SE, I see successful roll outs and adoptions as well as botched ones.  When I go through post-roll out analysis and lessons-learned efforts, most of the time, I see the culprit right away.  Lack of knowledge and going through the project/roll out blind, usually sinks the ship.

There are many reasons some customers skip training.  The first reason always points to budget.  I hear "We don't have budget for training" or "our engineers will figure it out" or the best one yet, "we don't see any benefit in wasting our engineers' time with training".

The second reason is "ego".  I know we are all engineers and have been around security or networking products for a long time.  But implementing a new security platform in an enterprise will take some time to correctly configure, optimize and utilize.   a new centralized management system which requires some scripting knowledge alone  is an formidable undertaking. By blindly going through a project like this, not only you jeopardize the bottom line, you also delay the ROI.

When I go through a demonstration and then a PoC, I usually provide a basic/advance (2-3 day training depending on the product or features) to my customers at no charge.  This helps me to build a better relationship with my customer by ensuring a more successful adaptation and roll out of the technology.  It also helps the customer get enough knowledge to architect and plan their roll out and figure out where they might need more structured training.


Ask your SE about training options!

Comments

Popular posts from this blog

MPLS vs VPN (Internet Connection) and power

This topic has been covered extensively by experts. What has not been covered in my opinion, is the underlying and fundamental change of transport infrastructure and specially power. The traditional WAN transport mechanisms are solid in terms of power normalization all through the last mile.  With the new (or not so new) shift towards commercially available Internet connections (namely DSL and Cable), customers need to watch out for excessive power coming through those lines and the respective modems and into their edge devices. There are surge protectors out there with "ethernet in/out" ports which could be used to mitigate this problem. Happy conversation out there...

“If you want to make beautiful music, you must play the black and the white notes together.” ― Richard M. Nixon

Does your product integrate with other security products? At this point, you should hate product silos (point products) as much as I do.   I understand and respect “divide and conquer” or “best of breed” strategies. I also understand having different security vendors at different layers of the network could possibly prevent an incident better (one vendor might not see/catch a vulnerability but another might have a signature or way of catching it). But isn’t it time to ask your vendors how and if they can work with each other? So what we (vendors) are competitors?   If by integrating with each other, we are able to increase the return on investment (ROI) for the customer, then why not (I know it might sound naive and unaware, but could you just imagine ). Vendors have application programming interfaces (APIs) for interaction with other platforms.   However, customers have to have application development resources to write code for these APIs, and that's not answer to a tr

"If I have seen a little further it is by standing on the shoulders of Giants." -Isaac Newton

Your vendors’ systems or sales engineers are a wealth of knowledge.  I don’t say that because I am one, I say that because we have been around various IT departments as employees or sales engineers.  We have seen different ways of achieving the same goals and can save you headaches or hidden roadblocks. It is mostly a myth that we only know the technology we are representing or selling.   First of all, we have to know our competitors’ technologies well enough to be able to differentiate ours. Second of all, we have to know enterprise IT applications well enough to make sure our products actually work in tandem. SEs also talk amongst themselves.   I might not know the project you are working on, but I am sure one of my colleagues do.   I work with a great group of engineers from different backgrounds.   They are sharp and always willing to help. I’ve worked in energy (both upstream and downstream) industry, healthcare (distribution and provider) as well as manufacturing (