People Only Buy To Get Promoted - The Key To Enterprise Sales

I have been fortunate to have many good sales mentors in my career but the best hands down was Joe Roebuck. Joe headed sales at Sun Microsystems for 17 years and was on my board at Persistence Software for 5 years.

Joe also gave me the most important insight about how to sell enterprise software:

People only buy to get promoted.

The enterprise software version of this pithy statement would be something like: enterprise buyers will only buy your shiny object if they see it leading directly to recognition, acclaim and promotion or at least a raise.

There is a lifetime of sales knowledge encapsulated in that quote. Here is how I interpret it:

• Status quo is easy: enterprise software is a business in which innovative upstarts try to unseat incumbents. The easy purchase decision in enterprise software is always to go with the incumbent. 
• Shiny objects are risky: Enterprise buyers always have a choice between safe status quo vendors and an array of risky but alluring new vendors
• Career advancement is why buyers take risks: if a buyer does not get a personal benefit - attention, a raise, a promotion - the risk quite literally does not outweigh the reward
• Advancing customer careers is how companies win: most sales people think only through the customer signature and maybe the initial implementation. Making a customer successful is a longer-term venture and extends at least to the buyer’s next HR review cycle.

There is no more passionate evangelist than a successful buyer and it only takes a few really happy buyers for the market herd instinct to kick in.  For example, VMworld pulls in 10,000 attendees a year, all of whom believe that VMware products are advancing their career.

Buyers know that product features don't guarantee success. Just because a product is objectively better doesn’t mean it will be successfully implemented, integrated and maintained by the vendor.  A key success in sales it to structure a deal in such a way that the company has incentive to stay focused on the success of the deal over time.

It is interesting that people always say of incumbents like IBM, “nobody gets fired for buying IBM.” The flip side of that is the only reason a buyer would make a riskier choice would be for the opportunity to be promoted, aka the opposite of being fired.

When Will Cloud Come to PaaS?

One of the perennial cloud predictions has been that 200x would be the year of the Platform as a Service (PaaS) cloud. The logic goes that if an automated data center in the sky is good, an automated development platform in the sky must be even better.

“Normal” clouds like Amazon AWS give the developer a virtual computer to load their OS and App onto. PaaS gives the developer a virtual computer with the OS, database and middleware “pre-loaded,” thereby simplifying the deployment.

Yet so far, PaaS adoption has been anemic and Gartner puts PaaS at 1% of the overall cloud market. At the same time, new technologies like Docker and containers have attracted far more attention from the developer community.

PaaS Lacks “Write Once, Run Anywhere” Simplicity

Developers love the simplicity of “write once, run anywhere.” This is what gave Java its initial allure and it is at the core of Docker’s recent ascendance to the top of the shiny tech object heap. PaaS has traditionally been more of a “write differently for each place” kind of solution.  Issues include:

1. PaaS lock-in – there is no example in the industry of PaaS portability – each PaaS has its own unique services and configuration. While IaaS also suffers from similar lock in issues, the effort required to port from one cloud to another is much lower here.  
2. Anemic ecosystem - real applications use many different services, such as database, file storage, security and messaging. In order to deploy an application in a PaaS, the PaaS must support every service that app needs,.
3. Public/private inflexibility – many PaaS offerings are cloud only (Heroku) or on premise (OpenShift). Even for PaaS offerings that can run on or off premise, replicating the exact service ecosystem in each environment is challenging.

PaaS For SaaS Is a Winner

A no-brainer use of PaaS is to extend existing SaaS applications. In this case, the write once run anywhere problem goes away because there is only one place to build and run the application. 

The big winner in PaaS to date has been SalesForce. Their Force.com platform makes it easy for companies to extend their CRM applications or build entirely new applications. With this platform, SalesForce has created huge competitive differentiation in CRM space while also building a PaaS revenue stream approaching $1B a year, dwarfing any other PaaS offering. 

Cloud Native PaaS Could Go Mainstream

Google recently released their cloud native platform, called Kubernetes (which means pilot in Greek). Kubernetes is a cloud operating system for containers that runs anywhere. A number of PaaS vendors are banding together to define the requirements for cloud native computing.

The promise is to simplify still further the process of provisioning services to cloud containers, regardless of where they are running. It will be exciting to see how existing PaaS vendors like CloudFoundry incorporate these new technologies into their offerings.

Enterprises Need A Panic Button for Security Breaches

Most home security systems have a panic button - if you hear something go bump in the night you can push a panic button to starts the sirens wailing, call the cops and hopefully sends the bad guys scurrying. As useful as this is for home owners, enterprises need a security panic button even more.

Security spending is heavily weighted towards keeping bad guys out. Media coverage has demonstrated how often they get in anyway. According to the CyberEdge Group, 71% of large enterprises reported at least 1 successful hacking attack in 2014.

While there is extensive advice around the manual steps to take to respond to a malicious attack, there is little in the way of an automated response to an attack. This is important area to extend enterprise automation.

What might a Panic Button for automated response to security incidents look like? Essentially this would be an automated workflow that would implement a set of tasks to eliminate the current attack, identify existing losses and minimize future damage. An example workflow could include:

1. Identify compromised systems from intrusion detection tools and disconnect compromised systems from network
2. Search for unauthorized processes or applications currently running or set to run on startup and remediate
3. Run file integrity checks and restore files to last known good state
4. Examine authentication system for unauthorized entries/changes and role back suspect changes 
5. Make backup copies of breached systems for forensic analysis
6. Identify information stolen from OS and database logs

By creating automated “Panic Button” workflows that respond to security incidents, enterprises can reduce the damage of an attack. This automated approach can also show customers that an enterprise is taking full precautions to protect their personal information from falling into the wrong hands.