The Two Engines of SaaS: QCRs and DEVs

I remember one day, years ago, when I was a VP at $10M startup and Larry, the head of sales, came in one day handing out t-shirts that said:

“Code, sell, or get out of the way.”

Neither I, nor the rest of marketing team, took this particularly well because the shirt obviously devalued the contributions of F&A, HR, and marketing.  But, ever seeking objectivity, I did concede that the shirt had a certain commonsense appeal.  If you could only hire one person at a startup, it would be someone to write the product.  And if you could only hire one more, it would be someone to sell it.

This became yet another event that reconfirmed my belief in my “marketing exists to make sales easier” mantra.  After all, if you’re not coding or selling, at least you can help someone who is.

Over time, Larry’s t-shirt morphed in my mind into a new mantra:

“A SaaS company is a two-engine plane.  The left engine is DEVs.  The right is QCRs.”

QCR meaning quota-carrying (sales) representative and DEV meaning code-committing developer.  People who sell with truly incremental quota, and people who actually write code and commit it to the code repository.

It’s a much nicer way of saying “code, sell, or get out of the way,” but it’s basically the same idea.  And it’s true.  While Larry was coming from a largely incorrect “protest overhead and process” viewpoint, I’m coming from a different one:  hiring.

The two hardest lines in a company headcount plan to keep at-plan are guess which two?  QCRs and DEVs.  Forget other departments for a minute — I’m saying is the the hardest line for the VP of Engineering to stay fully staffed on is DEVs, and the hardest line for the VP of Sales to stay fully staffed on is QCRs.

Why is this?

• They are two, critical highly in-demand positions, so the market is inherently tight.
• Given their importance, the hiring VPs can be gun-shy about making mistakes and lose candidates due to hesitation or indecision.
• Both come with a short-term tax and mid-term payoff because on-boarding new hires slows down the rest of the team, a possible source of passive resistance.
• Sales managers dislike splitting territories because it makes them unpopular, which could drive more foot-dragging.
• It’s just plain easier to find the associated support functions — (e.g,. program managers, QA engineers, techops, salesops, sales productivity, overlays, CSMs, managers in general) than it is find the QCRs and DEVs.

Let me be clear:  this is not to say that all the supporting functions within sales and engineering do not add value, nor is this to say that supporting corporate functions beyond sales and engineering do not add value — it is to say, however, that far too often companies take their eye off the ball and staff the support functions before, not after, those they are supporting.  That’s a mistake.

What happens if you manage this poorly?  On the sales side, for example, you end up with an organization that has 1 SVP of Sales, 1 VP of sales consulting, 4 sales consultants, 1 director of sales ops, 1 director of sales productivity, 1 manager of sales development reps (SDRs), 4 SDRs, an executive assistant, and 4 quota-carrying salespeople.  So only 22% of the people in your sales organization actually carry a quota.

“Uh, other than QCRs, we’re doing great on sales hiring,”  says the sales VP.  “Other than that, Mrs. Lincoln, how did you find the play?” thinks the board.

Because I’ve seen this happen so often, and because I’ve seen companies accused of it both rightfully and unjustly, I’d decided to create two new metrics:

• QCR density = number of QCRs / total sales headcount
• DEV density = numbers of DEVs / total engineering headcount

The bad news is I don’t have a lot of benchmark data to share here.  In my experience, both numbers want to run in the 40% range.

The good news is that if you run a ratio-driven staffing model (which you should do for both sales and engineering), you should be able to calculate what these densities should be when you are fully staffed.

Let’s conclude with a simple model that does just that on the sales side, producing a result in the 38% to 46% range.

Finally, let me add that having such a model helps you understand whether, for example, your QCR density is low due to slow QCR hiring (and/or bad retention) against a good model, or on-pace hiring against a “fat” model.  The former is an execution problem, the latter is a problem with your model.