Just say "No" to sending out an RFP

In my many years working as a Pre-sales engineer for a variety of enterprise software companies the single biggest waste of my time and effort was answering a request-for-proposal (Yes, the dreaded RFP). I am so jaded from my past experiences with RFPs that I strongly encourage my portfolio companies to refrain from the practice of issuing them entirely.  “Why?” you ask.  Because your garden variety RFP is an unnecessary step comprised of useless information.  

On the one side of things you have an enormous list of unprioritized questions put forth by the buyer. It represents a complete superset of every possible feature and function by every single solitary employee of the company from the CEO on down to the second shift janitor. Everyone wants to have their say in the process, but in most cases their feedback is a waste of time.  You end up asking a bunch of questions that having no actual bearing on your business.  For example:  

“Does your software run on Windows 95, Windows XP, Windows 7, Windows 8, Mac OS X, Red Hat Linux, Debian Linux, Solaris, IBM eSeries?”  

Really?  Do you really need to run the software on all of those platforms?  I SERIOUSLY doubt it. A subset of skilled professionals can whittle down a set of products to very short list of best-fit solutions with nothing more than a very concise list of requirements put down in order of priority.  If you must ask, do it that way. Period.   

On the other side of the equation you have the vendor.  As a former representative for a number of vendors I am uniquely qualified to let you in on a little secret.  And here it is.   As a pre-sales engineer for EVERY vendor that I ever worked for, my job was to figure out a way to answer "YES" to every single question on an RFP — regardless of how much I had to stretch the truth to do so.  Here's an example:  

“Does your software run on Windows 95, Windows XP, Windows 7, Windows 8, Mac OS X, Red Hat Linux, Debian Linux, Solaris, IBM eSeries?”

“Yes, by running Parallels or VMWare you can run our software on Windows 95, Windows XP, Windows 7, Windows 8, Mac OS X, Red Hat Linux, Debian Linux, Solaris, and IBM eSeries.”  

What this means is that you can install Parallels and a copy of Windows and then run the software under Windows 7.  So the real answer is "No, we do not run on all of these platforms, we only run on Windows 7.” I wasn't lying in my answer, but I was certainly massaging the truth.  Every single RPF is RIDDLED with weasly answers just like this.  

And why is that, you ask?  It's because the RFP itself is riddled with a million questions that may or may not be critical to the success of the product in your environment.   If you are going to ask me a bunch of inane questions that may or may not mean anything then I am going to turn around and give you back a bunch of vaguely worded answers that allow me to answer "YES" to every question.  As a rep, my goal is to get past the RFP stage and into the face-to-face meeting stage where the REAL selling can begin. Government agencies and purchasing agents at large companies are the kings of issuing RFPs.  And this is EXACTLY why I like working with middle-market companies on the buy side of the equation.   

Let's say that you are a company with $55 million in sales and $10 million of EBITDA looking to move off of QuickBooks and onto a bigger and new accounting platform.  Do you really think that you are going to make a better buying decision by putting together a 500-question RFP and sending it out to every accounting software vendor that comes up when you Google "accounting software"?  You won't.   

Get a small team of people led by your CFO in a room and put together a short list of requirements in priority order:   

- What platform do you want to run it on? (SAAS?  On premises?  Windows? Linux?) 
- What Accounting functions do you need to support (G/L, A/R, A/P, Purchasing, Invoicing)? 
- Budget — how much do you have to spend on licenses and implementation? 
- Lists of any unique functions/features.  

For example, maybe you need to support both English and simplified Chinese for data entry.  You can get the whole thing down to a few simple sheets of paper.  With some simple Googling and conversation amongst your team you'll come up with a list of 3-4 likely candidates in no time.  Call up the vendors, get a demo, and ask to SEE them demonstrate the few unique requirements that are specific to your situation. Get multiple quotes and talk to some references.  Pick one and negotiate a deal.  I guarantee you that these steps will work better and faster than any RFP-based process — and you will save yourself a TON of time.

The "Out-Of-Box Experience" and the Mobile Market

In the old days, companies used to ship you their software in a big square box.  Actually, when I started, the software delivery guys from Digital Equipment would hand-carry the magnetic tapes to you. By the time we reached the PC/Server era, your software would arrive in a massive mailer.  Inside that Costco-sized box was a manual and a compact disk (…okay, okay, it was mostly floppy disks). It wasn't always easy to get a trial version of software because the company actually incurred some real costs in packing and shipping the materials to you. As a consumer, you had to put in work too. You had to march through a phalanx of sales reps and sales engineers in order to get your trial copy.  It was a far cry from today's world, in which you just download the ZIP/EXE/DMG/TAR file from the web site and away you go.    

Once your trial arrived, you'd open the box, install the software and fire it up. We called the period from the opening of the box through the installation, all the way to the first hour (or so) of using the software, by the phrase the "out-of-box experience".  Yes, I know it SOUNDS like some hippy-trippy saying about you becoming one with the cosmos—or an overused company retreat exercise—but that's not what it meant.  When you mentioned the "OBE" you were talking about your initial impressions of the product and the likelihood that you would purchase it.  

If the product put a smile on your face during the installation and first-use, it had a "positive" OBE. Products that were difficult to install, were difficult to use at first, or were just plain ugly to look at (bad colors, bad fonts, busy screens) were said to have a "negative" OBE.  After all the work that went into just getting the trial software into a customer’s hands, a bad OBE could be a real killer.

Having a bad OBE can kill you in today's universe too.  

These days, expectations are higher particularly in the mobile apps sphere. Serving up a lousy web page is a bad idea, but it's not necessarily fatal. It does not cost you much to surf to a lousy web page; you don’t actually have to download or install anything. Will you go back to a bad web site? Maybe. 

Mobile apps are a different beast altogether. I tend to get mightily perturbed when I go to the trouble of downloading and installing a mobile app and it's terrible. I get particularly angry if I also have to create some sort of web account to go along with it on the back end. A bad OBE means that I might delete the app in question and never try it again. 

So the question becomes, do you risk putting out a mobile product with a clunky OBE in the middle market? Despite my previous remarks, my answer is a guarded YES.  If you are technology company in the middle market with solid customers in a defined niche, it is a bigger risk to get to the market late.  Go early and iterate, rather than wait until your app is “perfect”. Your customers are with you anyway and, while they might not love a clunky OBE, they will live with it. They are likely to be more unsettled by the lack of a product on your part, particularly if your competitors have a mobile product in play.  

However, if your FIRST product is a mobile product then my advice is the opposite.  Your OBE had better be killer or you'll get deleted and never re-added.  

Hire developers that understand mobile (iOS, Android) and your first product will be more likely to have a decent OBE, even if the software lacks a ton of functionality. Shoot for a minimum of features, make it run fast and keep it as error-free as possible. Apps with tons of features tend to have lots more errors that jump out at the user. Since you aren't likely producing a game app, your mobile software will need to connect to your backend systems--upping the potential for errors (limited signal coverage, data synchronization issues, etc). A fairly simple app, with clean graphics, that runs fast and relatively error-free is a good start.

We may be years removed from the literal box, but the OBE is still very relevant. The appearance and ease of use of your mobile product (or website, for that matter) communicates its quality to your customer. You are asking them to expend their time and effort to acquire and install your app--or worse, to discover that it doesn’t exist--so it’s up to you to make that effort worthwhile.

A Helping Heap of Technical Debt

I was talking to a founder about a process for working down their backlog of technical debt when it dawned on me that many business owners might not actually understand the concept at all.

Consider your car.  Most cars require you to get the oil changed every 3000 miles or so.  Once you get past 3000 miles you start running the risk of having problems.  Maybe you won’t see a problem right away, but somewhere down the line you might end up with a mess.  The longer that you wait to change the oil, the greater the risk becomes and the more near-term it gets.  

Technical debt is nothing more than required maintenance of a piece of software, like changing the oil in your car.  The difference is that the technical debt is coming from three directions: 
 
1.    External Influence — Your technology partners and suppliers.  Every time that they make a change to their software, they are adding technical debt to your software.  When Oracle releases version 12 of their database software, you inherit the technical debt of updating your database from version 11.  You don't have to do it right away, but you are going to have to do it sooner or later.  The longer that you wait, the more difficult it will be.  If you wait until Oracle ships version 13, you could end up in big mess.  We'll talk about this kind of technical debt in more detail in a subsequent post.  
2.    "Fashion” — Trends come and go in the technology business.  
For example, at one point technologists had the idea that putting all of your business logic into your database was the smart thing to do.  A few years later, they changed their mind.  As technology trends move out of fashion you, the business, are stuck with the task of removing these older designs out of your code line.  
3.    Internal Influence — Your own development processes and the changing business requirements of your software. 
For the remainder of this post we are going to talk about just this sort of technical debt - let's call this internal technical debt.   

Internal technical debt is a backlog of software maintenance that you have built up all on your own.  Executive management, product management and software engineers all contribute to the problem.  This probably sounds confusing to you. After all, how can you build up your own technical debt?  It's easier than you think.  To show you how, let's use a fictitious, but realistic, example of business logic.   

Let's say that you have a web ecommerce platform with an electronic shopping cart that your customers use to buy your product.  Early versions of this software allowed users to add products to their cart and make purchases by entering a credit card.  Simple.  

At some point, somebody in the company gets the clever idea to add a discount code for the upcoming holiday season to drive a little extra business by encouraging your customers to speed up their purchases.  Sounds like a great idea. At this point your team may not have a fully fleshed out idea of what the "discount code" should do.  However, since you had embraced a "ship and iterate" mentality, you might pull a basic storyboard together and dive in.   

[Now clearly I am being a little tongue in cheek.  It's never this bad, but I am simplifying the process a bit in order to tease out the core of the problem.  So I am asking for a little liberty here.]

Let's say that you call this new feature DiscountCode, and your team agrees on a basic set of features:  
- A discount code field will get added to the checkout screen 
- The discount code itself is a string called "HOLIDAY2014" 
- The server-side code will look for HOLIDAY2014 and subtract 10% from the order  

Engineering starts cranking out the code and the test cases.For the purposes of our little tale, we'll ignore the client-side code and just concentrate on the server code.Engineering adds the following code to the checkout layer: 

/*
** ... Checkout code
*/

IF (@V_DISCOUNTCODE == "HOLIDAY2014")
{
@V_TOTAL_SALE = @V_TOTAL_SALE - (@V_TOTAL_SALE * .10);
}

Simple, really.  If the variable @V_DISCOUNTCODE is "HOLIDAY2014" then we take 10% of the @V_TOTAL_SALE.  [Once again apologies for this psuedo-code. I’m going for simplicity here, not precision.]  

So far, so good.  This is a pretty simple change and, while it’s maybe not that well done, we haven't really disrupted the applecart so far.     

Now let’s say you realize that you shouldn't be enabling the discount code right away — after all, this is supposed to be a holiday promotion.  So you make a simple change:  

/* 
** ... Checkout code 
*/

IF (@V_DISCOUNTCODE == "HOLIDAY2014" and @SYSDATE BETWEEN "2014-11-28"
 AND "2014-12-31") 
{ 
@V_TOTAL_SALE = @V_TOTAL_SALE - (@V_TOTAL_SALE * .10); 
}

Still okay, we dodged a bullet there.  Let's say that our little promotion worked pretty well.  So we decide to add a first-quarter promotion in order to spark up the post-holiday sales. We'll make this one a little more aggressive because the first quarter is usually soft.  

/* 
** ... Checkout code 
*/

IF (@V_DISCOUNTCODE == "HOLIDAY2014" and @SYSDATE BETWEEN "2014-11-28" 
AND "2014-12-31") 
{ 
@V_TOTAL_SALE = @V_TOTAL_SALE - (@V_TOTAL_SALE * .10); 
} ELSEIF
(@V_DISCOUNTCODE == "1STQTR2015" and @SYSDATE BETWEEN "2015-01-01" AND "2015-03-31") 
{ 
@V_TOTAL_SALE = @V_TOTAL_SALE - (@V_TOTAL_SALE * .15); 
} 

We've got to keep the old code in there, even though it's not valid, because we might need to go back in time to understand why holiday sales in 2014 had a discount.  

[Once again, a small aside in the hopes of avoiding a flame-war here.  Yes, most developers wouldn't be this sloppy.  They would log the data. They could update the source and remove the old code, knowing that their version control system would track the changes.]  

By the end of the year we've ended up with several more simplistic promotions as follows: 

/*
** ... Checkout code
*/

IF (@V_DISCOUNTCODE == "HOLIDAY2014" and @SYSDATE BETWEEN "2014-11-28"
AND "2014-12-31")
{
@V_TOTAL_SALE = @V_TOTAL_SALE - (@V_TOTAL_SALE * .10);
} ELSEIF
(@V_DISCOUNTCODE == "1STQTR2015" and @SYSDATE BETWEEN "2015-01-01" AND "2015-03-31")
{
@V_TOTAL_SALE = @V_TOTAL_SALE - (@V_TOTAL_SALE * .15);
} ELSEIF
(@V_DISCOUNTCODE == "2NDQTR2015" and @SYSDATE BETWEEN "2015-04-01" AND "2015-06-30")
{
@V_TOTAL_SALE = @V_TOTAL_SALE - (@V_TOTAL_SALE * .10);
}ELSEIF
(@V_DISCOUNTCODE == "3RDQTR2015" and @SYSDATE BETWEEN "2015-07-01" AND "2015-09-30")
{
@V_TOTAL_SALE = @V_TOTAL_SALE - (@V_TOTAL_SALE * .25);
}

Sales decides to get cute in the fourth quarter and add several different holiday discount codes in order to REALLY spice up sales.  For the day AFTER Thanksgiving they get a 15% discount, on Cyber Monday they get 25% and then after that the discount code drops to 10% until the end of the year.   

/* 
** ... Checkout code 
*/

IF (@V_DISCOUNTCODE == "HOLIDAY2014" and @SYSDATE BETWEEN "2014-11-28"AND "2014-12-31") 
{ 
@V_TOTAL_SALE = @V_TOTAL_SALE - (@V_TOTAL_SALE * .10); 
} ELSEIF
(@V_DISCOUNTCODE == "1STQTR2015" and @SYSDATE BETWEEN "2015-01-01" AND "2015-03-31") 
{ 
@V_TOTAL_SALE = @V_TOTAL_SALE - (@V_TOTAL_SALE * .15); 
} ELSEIF
(@V_DISCOUNTCODE == "2NDQTR2015" and @SYSDATE BETWEEN "2015-04-01" AND "2015-06-30") 
{ 
@V_TOTAL_SALE = @V_TOTAL_SALE - (@V_TOTAL_SALE * .10); 
} ELSEIF
(@V_DISCOUNTCODE == "HOLIDAY2015") 
IF @SYSDATE is "2015-11-27" 
{ 
@V_TOTAL_SALE = @V_TOTAL_SALE - (@V_TOTAL_SALE * .15); 
} 
ELSEIF @SYSDATE is "2015-11-31" 
{ 
@V_TOTAL_SALE = @V_TOTAL_SALE - (@V_TOTAL_SALE * .25); 
} 
ELSE 
{ 
@V_TOTAL_SALE = @V_TOTAL_SALE - (@V_TOTAL_SALE * .10); 
} 
}

By the first quarter, you might decide to add discount codes for certain products, or only for certain classes of customers.  This is when things start to get really hairy:  

/* 
** ... Checkout code 
*/

IF (@V_DISCOUNTCODE == "HOLIDAY2014" and @SYSDATE BETWEEN "2014-11-28" 
AND "2014-12-31") 
{ 
@V_TOTAL_SALE = @V_TOTAL_SALE - (@V_TOTAL_SALE * .10); 
} ELSEIF
(@V_DISCOUNTCODE == "1STQTR2015" and @SYSDATE BETWEEN "2015-01-01" AND "2015-03-31") 
{ 
@V_TOTAL_SALE = @V_TOTAL_SALE - (@V_TOTAL_SALE * .15); 
} ELSEIF
(@V_DISCOUNTCODE == "2NDQTR2015" and @SYSDATE BETWEEN "2015-04-01" AND "2015-06-30") 
{ 
@V_TOTAL_SALE = @V_TOTAL_SALE - (@V_TOTAL_SALE * .10); 
} ELSEIF
(@V_DISCOUNTCODE == "HOLIDAY2015") 
IF @SYSDATE is "2015-11-27" 
{ 
@V_TOTAL_SALE = @V_TOTAL_SALE - (@V_TOTAL_SALE * .15); 
ELSEIF @SYSDATE is "2015-11-31" 
{ 
@V_TOTAL_SALE = @V_TOTAL_SALE - (@V_TOTAL_SALE * .25); 
} 
ELSE 
{ 
@V_TOTAL_SALE = @V_TOTAL_SALE - (@V_TOTAL_SALE * .10); 
} 
} ELSEIF 
(@V_DISCOUNTCODE = "1STQTR2016") AND (@SYSDATE BETWEEN "2015-01-01" AND "2015-03-31") 
IF (@V_CUSTOMERCLASS IN "1,3,12") 
{ 
@V_TOTAL_SALE = @V_TOTAL_SALE - (@V_TOTAL_SALE * .15); 
}
ELSEIF (@V_CUSTOMERCLASS IN "5,6,18") 
{ 
@V_TOTAL_SALE = @V_TOTAL_SALE - (@V_TOTAL_SALE * .17); 
}
}

While I could carry this problem out to its bitter end, let's stop right here. I’m already cross-eyed anyway.

You can see from the preceding example that the code still works, but it is going to get harder and harder to debug and maintain.  Somewhere along the way your development team is going to tell you that they should probably build out some database tables to hold discount codes, effective dates and values — and maybe some subtables for customer class codes and product class codes.  They'll also need some cycles to build out some user-interface panels for sales to use when entering and updating codes.  

The important thing to note here is that a very simple requirement, providing discount codes, has snowballed into a much more complex beast.  And while your real development team isn’t likely to try to implement a discount code in the imbecilic manner that I used here, the reality is probably closer than you think. Especially in the middle market.  Your understaffed development team probably scrambles to implement a lot of "specials" on an ongoing basis.  Over time all of these little hacks and sub-optimized code processes build up on themselves.  Eventually, you are going to need to fix it.  And that, friends, is the nature of technical debt.  

Almost every major component of every system that you write is going to end up generating some self-imposed technical debt.  And at some point you are going to have to pay that piper.  It's easier to do it a little at time, chipping away at the backlog of technical debt with each release cycle.  When you fail to do so you almost always end up in the dreaded "re-write" penalty box. Complete re-writes are generally a mess of galactic proportions and you’ll be MUCH happier if you choose to avoid them altogether.

 

Milbery's "Maslow" hierarchy of application needs

Almost everybody is familiar with Abraham Maslow's famous paper outlining the various levels of human motivations.  Maslow's hierarchy is built as a pyramid, with its foundation based on physical needs: food, water, and oxygen.  The second layer is safety and security.  Next up is love and belonging, followed by esteem, all leading to the top of the hierarchy—self-actualization.  Whether or not you believe Maslow’s sociological framework applies to man, the hierarchy is an interesting model for application software.

I've developed a pyramid-shaped hierarchy of my own to outline my requirements for any application that I use or build.  In a stunning display of originality, I'm calling it Milbery's Hierarchy of Application Development Needs.  I suspect that many of you will agree with the principles of my hierarchy, just as I believe that you will all disagree with their individual placement within the pyramid. 

Let’s say I’m creating an airline app. Ideally, I will not advance to a new level until the preceding one is airtight. This is especially crucial with the pyramid’s base levels.

Level 1: Speed.

The foundation level of my pyramid is speed. FAST trumps everything; it overshadows the good, mitigates the bad, and forgives the ugly.  Elegant design?  Who cares if those elegant screens take FOREVER to load.  Poor error handling?  Users may overlook crashes if they can access basic services—in this case, checking a flight status—really fast.  Speed. Speed. Speed. Users will tolerate applications that are clunky and offer limited functionality as long as they are FAST.  Slow screens are a constant annoyance to users. If it takes two minutes to load up your flight status, what's the point? Nothing else matters when your program/website/mobile-app isn't fast.   

Level 2: Error Handling.

The second level of my pyramid is intelligent error handling and logging.  Users absolutely HATE it when things go wrong.  They especially hate it when something weird happens and they don't know the state of their work. Did I lose the order I was working on?  Did the credit card transaction go through?  Just what happened?  If our friendly airline application consistently crashes while you are checking your flight status, you certainly are not going to want to use it to BOOK flight reservations.  

Level 3: Productivity and Reasonable Defaults.

Once you’ve nailed down the first two levels, your application needs to offer productivity. A fast, error-free piece of software will limit user frustration, but if it doesn't really offer any reasonable functionality, then there is no reason to use it.  If our airline application lets you check flight status but doesn’t allow you to change flights or seats, it’s not very productive. You might not delete it from your phone, but you aren't going to use it very often.  

At this third level, applications are also equipped with reasonable defaults.  The default installation is configured with the standard features and options that would appeal to most of its users.  Our airline mobile application might default to sending me notifications for every flight change, including all delays, cancellations and gate changes.  This would be turned on by default, so that I would not have to go hunting for these settings as soon as I start using the software. It is important to anticipate the functions users will want most, and then spare them the trouble of setting it up themselves.

Level 4: Native.

The next layer of my pyramid is the "native app" or what I call, "runs well on my platform".  Whatever the program/website/mobile-app is supposed to do, it needs to run natively on the user's platform to be worth anything.  Running on a Mac?  It needs to be a native Mac Cocoa-based application. 

•    "Runs on a Mac via Parallels or VMware Fusion"? NOT a native application. 
•    A web application that uses a screen-scraper to front-end an old client/server application? Doesn’t qualify.  
•    An HTML5 application without an Android wrapper application on your Samsung Galaxy?  Nope.  

The lack of a native interface causes the user problems every day.  Even simple things like cut and paste may not work.  Worse, the user often has to add third-party software to make the whole thing function.  Ugly.  I don't want a browser-based airline application on my iPhone.  I want a native iOS application that takes advantage of the native platform features, caches my credentials, integrated with notifications, the whole shebang.  


Level 5: Highly Configurable.

As we reach the top levels of the pyramid, we are reaching for perfection.  At the fifth level I want my software to be configurable.  In the beginning users don't want to have to fiddle with the software to get it working, but by level five they are used to working with it and want to start making configuration changes to adapt it to the way they work. Take our airline application.  Maybe the default behavior is to notify you via messaging about every flight change.  After a bit you might decide that you only want to be notified if your flight is delayed by more than 15 minutes (which should eliminate a TON of messages). My Level 5 app will be able to let you easily make those changes.

Level 5 software is highly configurable, letting me change things in order to match the application to the way in which I work.  Updated versions of the software maintain these customizations without forcing me to re-apply them.

Level 6: Elegant.

The highest level of the pyramid is the most difficult to describe—elegance.  Elegant applications delight you in unexpected ways.  They automatically adapt to the way that you use them without requiring you to manually change settings.  They often provide you with a new, more efficient and appealing way of accomplishing standard tasks.  They bring to mind that age-old saw —"I can't tell you what art is, but I know it when I see it". 

Elegant isn't some defined set of features and functions, it is deeply entwined with the software.  But it can often be explained via certain features that are unique to the task at hand.  If we take our fictitious airline application to Level 6, it would automatically detect when a "better" seat becomes available for me—and I mean a "better" seat according to where it knows I like to sit on planes.  A truly elegant application would make the change and prompt me to approve the choice with little fanfare while giving me all of the information that I need to make a decision either way.   

These are the things to consider for the mid-market company that provides software to their customers, be it web site, or desktop software or a mobile application.  Level three is my absolute minimum for any "production" class software.  Anything beyond level three is a true customer delight.  

This is simply one man's view of the software universe, but I challenge you to offer a better pyramid by commenting here, or hit us up on twitter @PEFunCast

 

 

You only get one chance to make a last impression

Unless you've been on a deserted island without internet access all week you've read about Donald Sterling's galactic audiotape disaster and RadiumOne CEO Gurbaksh Chalal copping to two misdemeanors after being charged with multiple felonies for apparently striking his girlfriend 117 times.

Our US democracy was founded on the principle that you are "innocent until proven guilty", but that privilege does not extend into the board room.  Not in the real world, at least. I may sound harsh, but it's true.  As partners in a private equity firm, we represent more than just ourselves. We represent our investors, the managers, employees and customers of our portfolio of companies.  We won't allow any of these people to be tainted by toxic issues like discrimination, domestic violence or harassment.  Period. 

This kind of exposure hurts you, and its ripple effect can spread quickly. We are not in the position to delicately parse facts. There is little room for nuance in these situations and we have to move faster than the fallout. Guilty or not, the immediate reaction will be to create distance between you and everyone else. Witness the rapid response of all of the Los Angeles Clippers sponsors, including CarMax and Virgin America.  They jumped ship even before the NBA's commissioner ruled on Donald Sterling's alleged comments—in fact, they were gone before it was even proven that it was Sterling’s voice on that TMZ audiotape.  If it turned out that the Sterling tape was a fake, it still wouldn’t matter.

This is not a matter of reasonable doubt, it's a matter of reasonable likelihood. And it's exactly what we would do.  RadiumOne's board decision to axe Chalal was slightly easier, since he had already pleaded guilty to two misdemeanor charges.  While the board took some heat in the trade rags this week for not moving fast enough I'm giving them the benefit of the doubt that they acted as fast as they could given the legal implications of firing a founder who might still actually control the ownership of the company. 

We’ve recently seen this play out in the investment world. Consider the story coming out about tech-startup darling, Github.  One of the co-founders and his spouse were alleged to have harassed an employee, Julie Ann Horvath.  Tech businesses tend to be male dominated environments, therefore, showing any tolerance for gender discrimination is a deathblow.  While co-founder Tom Preston-Werner was cleared of harassment charges after an internal investigation, he resigned anyway.  My guess is that the clever boys at Andreesen Horowitz (a Github investor) might have brought a little pressure to bear here with their $100m investment at stake. 

So, what's the lesson in the mid-market?  You had better get your house in order and make sure it stays in order.  You can't tolerate discrimination, harassment, domestic violence or anything like it in your company.  We won't tolerate bad behavior and our action will be swift.  We won't accommodate brilliant jerks.  And if the CEO won't clean it up, we will.  And if it's the CEO who's the jerk we'll deal with that, too. 

Our reputation depends upon it.

So it’s not personal, it's just how we do business.