Vendors, Again—8 Things To Do When Delivering a Technical Sales Presentation

In the last two days, I’ve sat through some of the most horrific sales presentations I’ve ever done—this was worse than the time share in Florida. If you happen to be a vendor and reading (especially if you are database vendor—don’t worry it wasn’t you), I hope this helps you craft better sales messages. In one of these presentations, the vendor has a really compelling product that I still have interest in, but was really put off by bad sales form.

I’ll be honest, I’ve never been in sales—I’ve thought about it a couple times, and still would consider it if the right opportunity came along, but I present, a lot. Most of these things apply to technical presentations as well as sales presentations. So here goes.

The top 8 things to do when delivering a sales presentation:

  1. Arrive Early—ask the meeting host to book your room a half hour early and let you in. This way you can get your connectivity going, and everything started before the meeting actually starts, wasting the attendee’s valuable time, and more importantly cutting into your time to deliver your sales message. Also starting on time allows you to respect your attendees’ schedules on the back end of the presentation.
  2. Bring Your Own Connectivity—if you need to connect to the internet (and if you have remote attendees, you do) bring your own connectivity. Mobile hotspots are widely available, and if you are in sales you are out of the office most of the time anyway, consider it a good investment.
  3. Understand Your Presentation Technology—please understand how to start a WebEx and share your presentation. If you have a Mac have any adapters you need to connect to video. If you want to use PowerPoint presentation mode (great feature by the way) make sure the audience doesn’t see the presenter view, and sees your slides. Not being able to do this is completely inexcusable.
  4. Understand Who Your Audience Is—if you are presenting to very Senior Infrastructure architects in a large firm, you probably don’t need to explain why solid state drives are faster than spinning disks. Craft your message to your intended audience, especially if it has the potential to be a big account. Also, if you know you are going to have remote attendees don’t plan on whiteboarding anything unless you have access to some electronic means to do so. You are alienating half of your audience.
  5. Don’t Tell Me Who Your Customers Are—I really don’t care that 10 Wall St banks use your software/hardware/widget. I think vendors all get that same slide from somewhere. Here’s a dirty little secret—large companies have so many divisions/partners/filing cabinets that we probably do own 90% of all available software products. It could be in one branch office that some manager paid for, but yeah technically we own it.
  6. I Don’t Care Who You Worked For—While I know it may have been a big decision to leave MegaCoolTechCorp for SmallCrappyStorageVendor, Inc., I don’t really care that you worked for MegaCoolTechCorp. If you mention it once, I can deal with it, but if you keep dropping the name it starts to get annoying and distracting.
  7. Get on Message Quickly—don’t waste a bunch of time telling me about marketing, especially when you go back to point #4—knowing your audience. If you are presenting to a bunch of engineers, they want to know about the guys of your product, not what your company’s earnings were. Like I mentioned above, one of the vendors I’ve seen recently has a really cool product, which I’m still interested in, but they didn’t start telling me about the product differentiation until 48 minutes into a 60 minute presentation.
  8. Complex Technical Concepts Need Pictures—this is a big thing with me. I do a lot of high availability and disaster recovery presentations—I take real pride in crafting nice PowerPoint graphics that take a complex concept like clustering and simplify it so I can show how it works to anyone. Today’s vendor was explaining their technology, and I was pretty familiar with the technology stack, yet I got really lost because there were no diagrams to follow. Good pictures make complex technical concepts easy to understand.

I hope some vendors read this and learn something. A lot of vendors have pretty compelling products, but fail to deliver the sales message which is costing them money. I don’t mind listening to a sales presentation, even for a vendor I may not buy something from, but I do really hate sitting through a lousy presentation that distracts me from the product.

Vendors and Clients, or How not to sell to me

Vendors, Customers, Community

I love vendors—I’m heavily involved with the SQL Server Community and the support of Microsoft and the many other vendors in our space makes our community possible. I recommend their software to friends; I know most of their evangelists. I’m not always the best customer, I’ll admit. I have done evaluations of vendor software I probably wasn’t planning to buy, just to be able share feedback and try to give a little back. Some vendors love this, others hate it. I’ve been slow in responding to follow up emails, especially after attending events, because I have other priorities than returning sales calls as soon as they come in.

Unfortunately, sometimes you have to deal with vendor sales reps who are focused so much on doing what’s right for them they refuse to hear what’s right for the customer (or prospective customer). They just won’t leave you alone. I understand these folks work off of commission, so they are trying to get a sale, and I (representing a Fortune 100 company) may represent a big target, but there is a right way and a wrong way to sell to me. Pissing me off is generally a bad idea.

Shortly after a SQL Saturday, I started receiving emails (to my personal account, not work) from a vendor I knew, but from a sales representative, whom I had never met. Remember, this is a SQLSaturday, so they would have my full name and company name from the registration. Even if I used a different email address, my name isn’t that common and he could have made a reasonable guess that I was the same person as the other person at the same company with the same name. Or he could have asked me.

The emails looked like the standard from the vendor—I’ve already worked pretty extensively with this vendor on evaluating their product. It will be a good fit for our future environment, but we just aren’t there yet. I mention this, because I’m 95% certain my name is in their sales lead system. If previous sales reps managed to have extended conversations with me about their product and didn’t add this to their sales lead system, then that’s another way that something went wrong. But I highly doubt that. About a week ago, I got this email from the sales rep.

How Not To Send an Email

I saw this email, I thought, “Wow this just comes off as really desperate and annoying. Even worse, I’m thinking this is the last person on Earth I want to work with in bringing in a solution to my company. It’s even more damning because I’ve worked with these folks before. I don’t know if this guy is my new sales rep, another rep trying to steal business from the other, or just naïve at how large enterprises acquire software. As my friend Karen Lopez likes to say “They will never treat you better than they did during the sales process”. I wonder if his boss knows he’s talking to prospective customers in this manner?

I will admit that occasionally things fall through to my spam folder. I sometimes don’t respond to vendor contacts as soon as they want. I probably should have let him know that I was already in their system and ask him to work with the other sales reps about the status of our project evaluations I assumed that he would look at the sales system eventually before making me do that data mining for him. The truth is I’m not going to have the time or resources to work with multiple competing reps at the same vendor. If I need to talk to someone there, I’ll work with one of the reps who I’ve already been working with.

This isn’t so much about the number of emails, but about the tone of the emails. I just don’t understand why a sales rep would ignore the data they already have about me and my company. Maybe this company pays sales people based on each contact? Maybe having lots of duplicate customers in the system benefits somebody?

I know trying to track down leads is a tough job. It requires a lot of follow up getting people to respond to voicemails and emails because so little of their time is allocated for investigating new software. If I responded positively to every request for a call or a demo from every vendor I come in contact with I’d be busy 100 hours a week doing just that.

It gets worse though.

These emails made me feel bad—as in uncomfortable, like I was obligated to reach out to the rep, and it was my problem. I am extremely thankful to all the people and companies who support our community, and would recommend nearly all of their products to serve specific needs to my friends and clients. In fact, I recommended this vendor’s product in a presentation I gave last week. Sales reps—just use your heads—if I’m not returning your email/voice mail/call to my dog’s cell phone/Linked In message, it means as a company we aren’t interested right now. Nothing more.

What PASS Has Meant to Me and My Career

On the eve of leaving for my first PASS Summit, I wanted to talk a little bit about what the SQL Server community has meant to me and my career. In my older roles at Wyeth, I was largely an Oracle DBA, but I had always dabbled in SQL Server since the beginning of my career. The position I was hired into at Synthes would require me to learn a lot more about SQL Server, since their environment was mostly SQL. So, I decided to start going to the Philadelphia SQL Server User Group meeting in the area (if your reading this from Philly–go to the website and sign up for the next meeting), and around the same time, I got involved with twitter, and found Brent Ozar (blog|twitter), which eventually led me into the much broader SQL community.

I submitted my first presentation that fall, to IOUG (Oracle’s version of PASS), and my first major presentation was at their conference in April. In the meantime, I had done a couple of presentations at our SQL group, and more importantly I was learning a ton more about the platform. Various code camps, videos at SSWUG, SQL Saturday’s and a SQL Rally later, I’m fairly confident in my speaking skills, and a few of you actually read my blog. Unfortunately, I’m not presenting at the PASS Summit this year, because around the time for submissions, I didn’t know I was going to be going.

One refrain I see tossed about, is that it really doesn’t matter if a person has 10 years of experience, if that person has the same year of experience 10 times. Getting involved in the community can really help you avoid that rut–you will be exposed to a wide variety of presentations on topics you might not have seen before, and if you make the leap to presenting, you’ll dig far deeper into topics than you might have ordinarily in your job,

So how does this tie back to my career? As the SAP project I was on  really started to suck (and I really figured this out while talking to colleagues at SQL Rally), I started looking for a new role, and I started talking to a couple of companies about DBA roles. It really helps the interview process, when you can respond to a question with, “oh I have an article about that on my blog” or “I did a presentation on that”, really helps.

So a big thank you to those who make up the community, your dedication and hard work has made a much better technologist (not just DBA) than I was three years ago.

Lastly, and the really great thing, is my new role (which is really awesome!) basically happened because of my speaking and blogging work I had done. Get out to a user group meeting, or a SQL Saturday! Stay active in the community, and see you at PASS!

Time for Change

As some of you may have seen on my LinkedIn profile, I recently made a job change. This as always was a hard decision, as I really liked the folks I was working with at my old company and getting to work in Europe (Switzerland) was a great career experience.  Here’s a little bit of background.

Last December, my company was in the midst of a big hiring spree for our global SAP implementation–it was a big project, and it was obviously where most of our IT resources were going to be going for the next several years. It also meant leaving my comfort zone–databases, to be the Infrastructure lead for the project. I decided to do it–the ERP experience would be great, and my backup plan was that I would continue presenting on SQL, I could always go back to being a DBA.

The project kicked off in February, and one of key early decisions was to outsource the hosting of the Infrastructure–this would, in theory make my job easier, as it would limit me to connectivity, and relationship management activities. However, things didn’t work out well with the hosting (the vendor was awful, and we weren’t much better), so in April, when we were coming up against some project deadlines, I jetted off to Switzerland to build the development and sandbox environments with my consultant. The Swiss had some excess hardware, and the plan was for this to be a temporary environment until we got the hosting worked out–it wasn’t, and the VMs we built then, laid the groundwork for development.

From my perspective, this was good and bad at the same time. It tested every part of my technical skills, I did SQL, Oracle, Windows, Linux, VMWare and a bit of SAN. I even was fairly involved in the network and remote access pieces of the project. The bad side of this, was my team hadn’t expanded–it was two of us, and we were beginning to get overwhelmed with requests, both from the development team and the project management stuff I was having to do. (A common week was 6 hours of meetings a day, all while trying to work). After Switzerland (pt 1), I took a few days to go speak at SQL Rally, and relax a bit.

One interesting tidbit I didn’t mention, was that during my trip to Switzerland, it was announced that my company was being acquired by a much larger health care firm. I think I would be safe, but that’s always a big place for concern.

I was talking with some really smart folks John Sterrett (blog|twitter), Kevin Kline (blog|twitter), and Jen McCown (blog|twitter) at Rally, and they suggested I start looking for another role. I only applied to two jobs, and I heard back from both of them–one of them was at a very prominent company in the Philadelphia area, where a couple of my Microsoft friends had worked. I interviewed there in late May–everything went great, the process took forever, but their HR recruiting did an excellent job of staying touch with me, and letting me know that they were still interested.

The project progressed, things only got crazier. SAP has a crazy number of modules, each which have their own inter and cross dependencies, additionally there are a decent number of ancillary systems that also require support. I’m looking at you Business Objects Data Services.  So needless to say free time was at a premium. May-July consisted of a lot of 60 hour weeks–we finally decided to dump the hosting guys, and do it ourselves, so the end of July had another trip to Switzerland (this  would be our vacation for the year, it was fun), this time to build the QA environment.

The day before I left for Switzerland (and SQL Saturday Wheeling), I got a call from the big company I had interviewed with, with a great offer, pending a drug test (I passed, woo hoo!) . While, I was in Switzerland, I began hearing rumors that the SAP project may be cancelled, as the company is trying to save cash in advance of the merger. This along with a couple of other things that happened in the US during that trip, lead me to accept the offer. I do have to thank Erin Stellato (blog|twitter) and Karen Lopez (blog|twitter) for helping me with advice during that trip. Thanks ladies!!!

So, the epilogue of this story is that two days after I started my new role, the project was cancelled, and everyone was reassigned into either their old roles or something else. I felt pretty awful for my colleagues, but like I said on twitter, I felt like I hit the lottery.

Now, that I’m in a different role, you should see some more blogs here. Later this week, I’ll talk about how the community can help your career!

The Top 5 Things I learned during my MBA program.

This post originated one night when John Sterrett (blog|twitter) was asking for a good place to find salary information. I was able to quickly refer him to O*Net, a government database of job descriptions, and extensive salary info based on IRS return data. I mentioned that it was one of the top five things I learned about during my MBA program.

I’d like to just add while I don’t know if it’s totally a worthwhile endeavor, I really enjoyed going to business school. My company at the time paid for most of it, so I took advantage of that benefit. It was a great opportunity to network with a bunch of really smart people, and change the way I looked at a lot of things in business and IT.

John mentioned that he hoped to learn about the rest of my top 5–I had to step back and think about what those were. So here goes my attempt at classifying them.

1) O*Net — As I mentioned before this is a Federal website, that shows both salary information and detailed job descriptions for all professions. Need a job description for a DBA? It’s here. I’ve used this before when our HR org didn’t put together a job description of my liking.

2) HR–I learned how HR works, how to work with them to hire good people. I learned the legal process behind the review process, and the performance review process in general. I also began to understand that in really successful companies, HR is used as strategic asset, and not just a gatekeeper and processor of information. There are other better writings on this, but it’s a good topic to study further on. I also learned that the best way to get hired, is to avoid going to HR, and network your way to the hiring manager.

3) Managing Your Career–Tom LaRock (blog|twitter) wrote a book on this, but one of the key bits of wisdom I picked up in my second take at college was that you and only you are responsible for your career. Your manager probably doesn’t care, as he/she is focused on their own job.

4) Statistics–Or the class where I really learned how to use Excel. I had some vague knowledge of statistics, but a management statistics class gave me knowledge of confidence intervals, how statistics get used in business situations. And despite what some say, marketing is more than liquor and guessing, you can use statistics to model and focus in on a target audience.

5) Don’t murder anyone. As much as I wish it did, this has nothing to do with a product liability class. Unfortunately, one of my classmates, who I witnessed having a liaison with another student on a class trip to France, is on trial was convicted for the murder of his wife. Last month I got to have thewonderful experience of testifying in the case. That sucked, what really puts in perspective is he was a fairly normal guy, with some priorities a little out of whack. I don’t intend this to be one of those “it can happen to anyone things”, but it does really make you think.

So I’ve covered salary, HR, career, stats, and felonies. There were many other interesting things I learned about including a great class on Organization Culture and a series of very interesting Supply Chain classes, but overall these were my top 5 takeaways.

Well, that and I hope I never have to testify in a criminal matter ever again.

A Recruiter Story, Part I

This conversation came up on Twitter a few weeks ago between Brent Ozar (blog | twitter), Tom LaRock (blog| twitter) and Adam Machanic (blog|twitter). Brent has posted before about how to work with recruiters, here and here.

There is a perception in the IT community that recruiters are nothing better than bottom feeding, used car salesman. As a point of reference, I’m trying to hire a DBA right now, and I’ve posted to Linked In and Twitter about it, and have had to be hassled by several sleaze bags types. A really good, professional recruiter is hard to find, and if you find one keep their name in your Rolodex forever.

I’ll echo what Brent says in one of his posts—recruiters don’t work for you, and they aren’t the employees of the company you’re trying to work for, they are contracted middle men, who only get paid if you get the job, and typically work there for six months. So remember—you don’t have the same best interests as a recruiter. Also, please note, most of these blogs are written with the perspective that your are currently employed, and looking for a more interesting role, if you’re currently unemployed, all bets are off, you need to try to talk with everyone you can (just don’t work with anyone who asks you for money!!! Major no, no)

The names in this post have been omitted to protect the innocent and the guilty.  This was a story told to me by a fellow DBA who worked with me in past job.

I get a call from a recruiter about a Senior DBA position with a healthcare software company in the area, and the salary range is X-X+25. I told the recruiter that I would really need to be at the very top of the range for this to work. Of course, the recruiter says no problem. This position was interesting to me, because I would be involved a lot more in development, and I could continue to carry my healthcare experience along.

I send my resume along to the recruiter, and their HR likes it and schedules quick phone screen (with HR).  When HR calls me the first question, after pleasantries were exchanged, was “What is your salary range?”, no questions about my experience or details about the role. Of course, I try to back away from the question; by saying., you know I need to hear more about the responsibilities of the position, etc. The HR rep won’t back down, so I say I need to at least be at X+25, she responds with “Oh, we were only looking to pay X, and no more” . So that call ended quickly—I called the recruiter back and told him the story, and he didn’t quite know what to say.

The next day the recruiter calls back, and says the hiring manager would like to talk to you, and that they would be willing to pay X+25 for an extremely qualified candidate such as yourself…

Come back next week for the conclusion to this exciting story!

How to Transfer an IT Project Effectively

A couple of weeks ago I got some really good news—I was transferring into a new role at my current company. Since this is an internal transfer, the standard two-week notice stretched to four and I had time to properly transfer my existing projects.

It is important to be as effective as possible in doing this, so you aren’t dealing with your existing projects in your new role.

The first thing I recommend doing is introducing the project contact person (In this case a business user) to the DBA you are handing off to. Ideally, you can do this in person, but since we are at multiple sites, I had to do it over email. Make it clear you will be transitioning all responsibilities over to the other DBA, and are trying to be successful in a new role, so can no longer support this project (be really nice about it—kill ‘em with kindness).

Secondly, if you have an email folder for the project, share it with the rest of your DBA team. If you don’t have one—create one and copy as much mail as you can into it. The search function in Outlook 2010 works really well, and sharing the mail may save you a phone call or two down the road.

Finally, and most importantly, you need to build out a project document. Put as much detail in as possible. I used the below sections for mine:

• Project Contacts—Who you work with, and what is their business function • Vendor Contact Info—Who you work with directly (If a small vendor) or contact/support info for a larger vendor

• Business Purpose—What does this application do, and what does it support? What are the uptime requirements?

• Authentication—How is authentication handled? Are there SQL logins to worry about? • Security Groups—This ties back to authentication, but are there domain groups controlling access to the application? Which groups control which rights?

• SQL Jobs—If the application has agent jobs—what are they? What do they do? How do you handle job failure? Who is the point of contact on the jobs?

• General Narrative—Describe anything else about the application. In our case there are some subprocesses that were failing, so I included that information. I also discussed the application patching process, along with some persistent issues we were trying to resolve with the vendor

. • HA/DR—This was touched on earlier, but how is specifically implemented? Where is the database mirrored/replicated to?

• Architecture—A very detailed Visio showing the whole landscape for the application—client connections, database connections, application servers, any external connections.

This list is in no way complete—feel free to add anything in the comments, I’d love to improve my process.

This is important stuff—in order to be as successful as you can  in a new role, you need to be able to transition projects effectively, but this same process can be used to transfer support of an application to an operations team, or outsourcing overnight support.

%d bloggers like this: