Category Archives: Management

The Evolution of Marketing Thanks to SaaS

I was talking with my friend Tracy Eiler, author of Aligned to Achieve, the other day and she showed me a chart that they were using at InsideView to segment customers.  The chart was a quadrant that mapped customers on two dimensions:  renewal rate and retention rate.  The idea was to use the chart to plot customers and then identify patterns (e.g., industries) so marketing could identify the best overall customers in terms of lifetime value as the mechanism for deciding marketing segmentation and targeting.

Here’s what it looked like:

saas-strategic-value

While I think it’s a great chart, what really struck me was the thinking behind it and how that thinking reflects a dramatic evolution in the role of marketing across my career.

  • Back two decades ago when marketing was measured by leads, they focused on how to cost-effectively generate leads, looking at response rates for various campaigns.
  • Back a decade ago when marketing was measured by opportunities (or pipeline), they focused on how to cost-effectively generate opportunities, looking at response and opportunity conversion rates.
  • Today, as more and more marketers are measured by marketing-sourced New ARR, they are focused on cost-effectively generating not just opportunities, but opportunities-that-close, looking all the way through the funnel to close rates.
  • Tomorrow, as more marketers will be measured on the health of the overall ARR pool, they will be focused on cost-effectively generating not just opportunities-that-close but opportunities that turn into the best long-term customers. (This quadrant helps you do just that.)

As a company makes this progression, marketing becomes increasingly strategic, evolving in mentality with each step.

  • Starting with, “what sign will attract the most people?” (Including “Free Beer Here” which has been used at more than one conference.)
  • To “what messages aimed at which targets will attract the kind of people who end up evaluating?”
  • To “who are we really looking to sell to — which people end up buying the most and the most easily – and what messages aimed at which targets will attract them?”
  • To “what are the characteristics of our most successful customers and how can we find more people like them?”

The whole pattern reminds me of the famous Hubspot story where the marketing team was a key part forcing the company to focus on either “Owner Ollie” (the owner of a <10 person business) or “Manager Mary” (a marketer at a 10 to 1000 person business).  For years they had been serving both masters poorly and by focusing on Manager Mary they were able to drive a huge increase in their numbers that enabled cost-effectively scaling the business and propelling them onto a successful IPO.

hubspot

What kind of CMO does any CEO want on their team?  That kind.  The kind worried about the whole business and looking at it holistically and analytically.

In-Memory Analytics: The Other Kind – A Key Success Factor for Your Career

I’m not going to talk about columnar databases, compression, horizontal partitioning, SAP Hana, or real-time vs. pre-aggregated summarization in this post on in-memory analytics.  I’m going to talk about the other kind of in-memory analytics.  The kind that can make or break your career.

What do you mean, the other kind of in-memory analytics?  Quite simply, the kind you keep in your head (i.e., in human memory).  Or, better put, the kind you should be expected to keep in your head and be able to recite on demand in any business meeting.

I remember when I worked at Salesforce, I covered for my boss a few times at the executive staff meeting when he was traveling or such.  He told me:  “Marc expects everyone to know the numbers, so before you go in there, make sure you know them.”  And I did.  On the few times I attended in his place, I made a cheat sheet and studied it for an hour to ensure that I knew every possible number that could reasonably be asked.  I’d sit in the meeting, saying little, and listening to discussion not directly related to our area.  Then, boom, out of left field, Marc asked:  “what is the Service Cloud pipeline coverage ratio for this quarter in Europe?”

“3.4,” I replied succinctly.  If I hadn’t have known the number I’m sure it would been an exercise in plucking the wings off a butterfly.  But I did, so the conversation quickly shifted to another topic, and I lived to fight another day.

Frankly, I was happy to work in an organization where executives were expected to know — in their heads, in an instant — the values of the key metrics that drive their business.  I weak organizations you constantly hear “can I get back to you on that” or “I’m going to need to look that one up.”

If you want to run a business, or a piece of one,  and you want to be a credible leader — especially in a metrics-driven organization — you need to have “in-memory” the key metrics that your higher-ups and peers would expect you to know.

This is as true of CEO pitching a venture capitalist and being asked about CAC ratios and churn rates as it is of a marketing VP being asked about keywords, costs, and conversions in an online advertising program.  Or a sales manager being asked about their forecast.

In fact, as I’ve told my sales directors a time or two:  “I should be able to wake you up at 3:00 AM and ask your forecast, upside, and pipeline and you should be able to answer, right then, instantly.”

That’s an in-memory metric.  No “let me check on that.”  No “I’ll get back to you.”  No “I don’t know, let me ask my ops guy,” which always makes me think: who runs the department, you or the ops guy — and if you need to ask the ops guy all the numbers maybe he/she should be running the department and not you?

I have bolded the word “expect” four times above because this issue is indeed about expectations and expectations are not a precise science.  So, how can you figure out the expectations for which analytics you should hold in-memory?

  • Look at your department’s strategic goals and determine which metrics best measure progress on them.
  • Ask peers inside the company what key metrics they keep in-memory and design your set by analogy.
  • Ask peers who perform the same job at different companies what key metrics they track.
  • When in doubt, ask the boss or the higher-ups what metrics they expect you to know.

Finally, I should note that I’m not a big believer in the whole “cheat sheet” approach I described above.  Because that was a special situation (covering for the boss), I think the cheat sheet was smart, but the real way to burn these metrics into your memory is to track them every week at your staff meeting, watching how they change week by week and constantly comparing them to prior periods and to a plan/model if you have one.

The point here is not “fake it until you make it” by running your business in a non-metrics-focused way and memorizing figures before a big meeting, but instead to burn the metrics review into your own weekly team meeting and then, naturally, over time you will know these metrics so instinctively that someone can wake you up at 3:00 AM and you can recite them.

That’s the other kind of in-memory analytics.  And, much as I love technology, the more important kind for your career.

A Fresh Look at How to Measure SaaS Churn Rates

It’s been nearly three years since my original post on calculating SaaS renewal rates and I’ve learned a lot and seen a lot of new situations since then.  In this post, I’ll provide a from-scratch overhaul on how to calculate churn in an enterprise SaaS company [1].

While we are going to need to “get dirty” in the detail here, I continue to believe that too many people are too macro and too sloppy in calculating these metrics.  The details matter because these rates compound over time, so the difference between a 10% and 20% churn rate turns into a 100% difference in cohort value after 7 years [2].  Don’t be too busy to figure out how to calculate them properly.

The Leaky Bucket Full of ARR

I conceptualize SaaS companies as leaky buckets full of annual recurring revenue (ARR).  Every time period, the sales organization pours more ARR into the bucket and the customer success (CS) organization tries to prevent water from leaking out [3].

This drives the leaky bucket equation, which I believe should always be the first four lines of any SaaS company’s financial statements:

Starting ARR + new ARR – churn ARR = ending ARR

Here’s an example, where I start with those four lines, and added two extra (one to show a year over year growth rate and another to show “net new ARR” which offsets new vs. churn ARR):

leaky

For more on how to present summary SaaS startup financials, go here.

Half-Full or Half-Empty:  Renewals or Churn?

Since the renewal rate is simply one minus the churn rate, the question is which we should calculate?  In the past, I favored splitting the difference [4], whereas I now believe it’s simpler just to talk about churn.  While this may be the half-empty perspective, it’s more consistent with what most people talk about and is more directly applicable, because a common use of a churn rate is as a discount rate in a net present value (NPV) formula.

Thus, I now define the world in terms of churn and churn rates, as opposed to renewals and renewal rates.

Terminology: Shrinkage and Expansion

For simplicity, I define the following two terms:

  • Shrinkage = anything that makes ARR decrease. For example, if the customer dropped seats or was given a discount in return for signing a multi-year renewal [5].
  • Expansion = anything that makes ARR increase, such as price increases, seat additions, upselling from a bronze to a gold edition, or cross-selling new products.

Key Questions to Consider

The good news is that any churn rate calculation is going to be some numerator over some denominator.  We can then start thinking about each in more detail.

Here are the key questions to consider for the numerator:

  • What should we count? Number of accounts, annual recurring revenue (ARR), or something else like renewal bookings?
  • If we’re counting ARR should we think at the product-level or account-level?
  • To what extent should we offset shrinkage with expansion in calculating churn ARR? [6]
  • When should we count what? What about early and late renewals?  What about along-the-way expansion?  What about churn notices or non-payment?

Here are the key questions to consider for the denominator:

  • Should we use the entire ARR pool, that portion of the ARR pool that is available to renew (ATR) in any given time period, or something else?
  • If using the ATR pool, for any given renewing contract, should we use its original value or its current value (e.g., if there has been upsell along the way)?

What Should We Count?  Logos and ARR

I believe the two metrics we should count in churn rates are

  • Logos (i.e., number of customers). This provides a gross indication of customer satisfaction [7] unweighted by ARR, so you can answer the question:  what percent of our customer base is turning over?
  • This provides a very important indication on the value of our SaaS annuity.  What is happening to our ARR pool?

I would stay completely away from any SaaS metrics based on bookings (e.g., a bookings CAC, TCV, or bookings-based renewals rate).  These run counter to the point of SaaS unit economics.

Gross, Net, and Account-Level Churn

Let’s look at a quick example to demonstrate how I now define gross, net, and account-level churn [8].

gross-and-net-churn

Gross churn is the sum of all the shrinkage. In the example, 80 units.

Net churn is the sum of the shrinkage minus the sum of the expansion. In the example, 80-70 = 10 units.

To calculate account-level churn, we proceed, account by account, and look at the change in contract value, separating upsell from the churn.  The idea is that while it’s OK to offset shrinkage with expansion within an account that we should not do so across accounts when working at the account level [9].  This has the effect of splitting expansion into offset (used to offset shrinkage within an account) and upsell (leftover expansion after all account-level shrinkage has been offset).  In the example, account-level churn is 30 units.

Make the important note here that how we calculate you churn – and specifically how we use expansion ARR to offset shrinkage—not only affects our churn rates, but our reported upsell rates as well.  Should we proudly claim 70 units of upsell (and less proudly 80 units of churn), 30 units of churn and 20 of upsell, or simply 10 units of churn?  I vote for the second.

While working at the account-level may seem odd, it is how most SaaS companies work operationally.  First, because they charter customer success managers (CSMs) to think at the account level, working account by account doing everything they can to preserve and/or increase the value of the account.  Second, because most systems work at and finance people think at the account level – e.g., “we had a customer worth 100 units last year, and they are worth 110 units this year so that means upsell of 10 units.  I don’t care how much is price increase vs. swapping some of product A for product B.” [11]

So, when a SaaS company reports “churn ARR,” in its leaky bucket analysis, I believe they should report neither gross churn nor net churn, but account-level churn ARR.

Timing Issues and the Available to Renew (ATR) Concept

Churn calculations bring some interesting challenges such as early/late renewals, churn notices, non-payment, and along-the-way expansion.

A renewals booking should always be taken in the period in which it is received.  If a contract expires on 6/30 and the renewal is received in on 6/15 it should show up in 2Q and if received on 7/15 it should up in 3Q.

For churn rate calculations, however, the customer success team needs to forecast what is going to happen for a late renewal.  For example, if we have a board meeting on 7/12 and a $150K ARR renewal due 6/30 has not yet been happened, we need to proceed based on what the customer has said.  If the customer is actively using the software, the CFO has promised a renewal but is tied up on a European vacation, I would mark the numbers “preliminary” and count the contract as renewed.  If, however, the customer has not used the software in months and will not return our phone calls, I would count the contract as churned.

Suppose we receive a churn notice on 5/1 for a contract that renews on 6/30.  When should we count the churn?  A Bessemer SaaS fanatic would point to their definition of committed monthly recurring revenue (CMRR) [12] and say we should remove the contact from the MRR base on 5/1.  While I agree with Bessemer’s views in general — and specifically on things like on preferring ARR/MRR to ACV and TCV — I get off the bus on the whole notion of “committed” ARR/MRR and the ensuing need to remove the contract on 5/1.  Why?

  • In point of fact the customer has licensed and paid for the service through 6/30.
  • The company will recognize revenue through 6/30 and it’s much easier to do so correctly when the ARR is still in the ARR base.
  • Operationally, it’s defeatist. I don’t want our company to give up and say “it’s over, take them out of the ARR base.” I want our reaction to be, “so they think they don’t want to renew – we’ve got 60 days to change their mind and keep them in.” [13]

We should use the churn notice (and, for that matter, every other communication with the customer) as a way of improving our quarterly churn forecast, but we should not count churn until the contract period has ended, the customer has not renewed, and the customer has maintained their intent not to renew in coming weeks.

Non-payment, while hopefully infrequent, is another tricky issue.  What do we do if a customer gives us a renewal order on 6/30, payable in 30 days, but hasn’t paid after 120?  While the idealist in me wants to match the churn ARR to the period in which the contract was available to renew, I would probably just show it as churn in the period in which we gave up hope on the receivable.

Expansion Along the Way (ATW)

Non-payment starts to introduce the idea of timing mismatches between ARR-changing events and renewals cohorts.  Let’s consider a hopefully more frequent case:  ARR expansion along the way (ATW).  Consider this example.

expansion

To decide how to handle this, let’s think operationally, both about how our finance team works and, more importantly, about how we want our customer success managers (CSMs) to think.  Remember we want CSMs to each own a set of customers, we want them to not only protect the ARR of each customer but to expand it over time.  If we credit along-the-way upsell in our rate calculations at renewal time, we shooting ourselves in the foot.  Look at customer Charlie.  He started out with 100 units and bought 20 more in 4Q15, so as we approach renewal time, Charlie actually has 120 units available to renew (ATR), not 100 [14].  We want our CSMs basing their success on the 120, not the 100.  So the simple rule is to base everything not on the original cohort but on the available to renew (ATR) entering the period.

This begs two questions:

  • When do we count the along-the-way upsell bookings?
  • How can we reflect those 40 units in some sort of rate?

The answer to the first question is, as your finance team will invariably conclude, to count them as they happen (e.g., in 4Q15 in the above example).

The answer to the second question is to use a retention rate, not a churn rate.  Retention rates are cohort-based, so to calculate the net retention rate for the 2Q15 cohort, we divide its present value of 535 by its original value of 500 and get 107%.

Never, ever calculate a retention rate in reverse – i.e., starting a group of current customers and looking backwards at their ARR one year ago.  You will produce a survivor biased answer which, stunningly, I have seen some public companies publish.  Always run cohort analyses forwards to eliminate survivor bias.

Off-Cycle Activity

Finally, we need to consider how to address off-cycle (or extra-cohort) activity in calculating churn and related rates.  Let’s do this by using a big picture example that includes everything we’ve discussed thus far, plus off-cycle activity from two customers who are not in the 2Q16 ATR cohort:  (1) Foxtrot, who purchased in 3Q14, renewed in 3Q15, and who has not paid, and (2) George, who purchased in 3Q15, who is not yet up for renewal, but who purchased 50 units of upsell in 2Q16.

bigpic

Foxtrot should count as churn in 2Q16, the period in which we either lost hope of collection (or our collections policy dictated that collection we needed to de-book the deal). [15]

George should count as expansion in 2Q16, the period in which the expansion booking was taken.

The trick is that neither Foxtrot nor George is on a 2Q renewal cycle, so neither is included in the 2Q16 ATR cohort.  I believe the correct way to handle this is:

  • Both should be factored into gross, net, account-level churn, and upsell.
  • For rates where we include them in the numerator, for consistency’s sake we must also include them in the denominator. That means putting the shrinkage in the numerator and adding the ATR of a shrinking (or lost) account in denominator of a rate calculation.  I’ll call this the “+” concept, and define ATR+ as inclusive of such additional logos or ARR resulting from off-cycle accounts [16].

Rate Calculations

We are now in the position to define and calculate the churn rates that I use and track:

  • Simple churn = net churn / starting period ARR * 4.  Or, in English, the net change in ARR from existing customers divided by starting period ARR (multiplied by 4 to annualize the rate which is measured against the entire ARR base). As the name implies, this is the simplest churn rate to calculate. This rate will be negative whenever expansion is greater than shrinkage. Starting period ARR includes both ATR and non-ATR contracts (including potentially multi-year contracts) so this rate takes into account the positive effects of the non-cancellability of multi-year deals.  Because it takes literally everything into account, I think this is the best rate for valuing the annuity of your ARR base.
  • Logo churn = number of discontinuing logos / number of ATR+ logos. This rate tells us the percent of customers who, given the chance, chose to discontinue doing business with us.  As such, it provides an ARR-unweighted churn rate, providing the best sense of “how happy” our customers are, knowing that there is a somewhat loose correlation between happiness and renewal [16].  Remember that ATR+ means to include any discontinuing off-cycle logos, so the calculation is 1/16 = 6.3% in our example.
  • Retention = current ARR [time cohort] / time-ago ARR [time cohort]. In English, the current ARR from some time-based cohort (e.g., 2Q15) divided by the year-ago ARR from that same cohort.  Typically we do this for the one-year-ago or two-years-ago cohorts, but many companies track each quarter’s new customers as a cohort which they measure over time.  Like simple churn, this is a great macro metric that values the ARR annuity, all in.
  • Net churn = account-level churn / ATR+. This churn rate foots to the reported churn ARR in our leaky bucket analysis (which is account-level churn), which partially offsets shrinkage with expansion at an account-level, and is how most SaaS companies actually calculate churn.  While perhaps counter-intuitive, it reflects a philosophy of examining, at an account basis, what happens to value of our each of our customers when we allow shrinkage to be offset by expansion (which is what we want our CSM reps doing) leaving any excess as upsell.  This should be our primary churn metric.
  • Gross churn = shrinkage / ATR+. This churn rate is important because it reveals the difference between companies that have high shrinkage offset by high expansion and companies which simply have low shrinkage.  While net churn is powerful because it’s “all in,” any metric that enables offset can allow one thing to mask another.  Gross churn is a great metric because it simply shows the glass half-empty view:  at what rate is ARR leaking out of your bucket before offset it with refills in the form of expansion ARR.

# # #

Notes

[1] Replacing these posts in the process.

[2] The 10% churn group decays from 100 units to 53 in value after 7 years, while the 20% group decays to 26.

[3] We’ll sidestep the question of who is responsible for installed-based expansion in this post because companies answer it differently (e.g., sales, customer success, account management) and the good news is we don’t need to know who gets credited for expansion to calculate churn rates.

[4] Discussing churn in dollars and renewals in rates.

[5] For example, if a customer signed a one-year contract for 100 units and then was offered a 5% discount to sign a three-year renewal, you would generate 5 units of ARR churn.

[6] Or, as I said in a prior post, should I net first or sum first?

[7] And yes, sometimes unhappy customers do renew (e.g., if they’ve been too busy to replace you) and happy customers don’t (e.g., if they get a new key executive with different preferences) but counting logos still gives you a nice overall indication.

[8] Note that I have capitulated to the norm of saying “gross” churn means before offset and thus “net” churn means after netting out shrinkage and expansion.  (Beware confusion as this is the opposite of my prior position where I defined “net” to mean “net of expansion,” i.e., what I’d now call “gross.”)

[9] Otherwise, you just end up with a different way of calculating net churn.  The idea of account-level churn is to restrict the ability to offset shrinkage with expansion across accounts, in effect, telling your customer success reps that their job is to, contract by contract, minimize shrinkage and ensure expansion.

[10] “Offset” meaning ARR used to offset shrinkage that ends up neither churn nor upsell.

[11] While this approach works fine for most (inherently single-product) SaaS startups it does not work as well for large multi-product SaaS vendors where the failure of product A might be totally or partially masked by the success of product B.  (In our example, I deliberately had all the shrinkage coming from downsell of product A to make that point.  The product or general manager for product A should own the churn number that product and be trying to find out why it churned 80 units.)

[12] MRR = monthly recurring revenue = 1/12th of ARR.  Because enterprise SaaS companies typically run on an annual business rhythm, I prefer ARR to MRR.

[13] Worse yet, if I churn them out on 5/1 and do succeed in changing their mind, I might need to recognize it as “new ARR” on 6/30, which would also be wrong.

[14] The more popular way of handling this would have been to try and extend the original contract and co-terminate with the upsell in 4Q16, but that doesn’t affect the underlying logic, so let’s just pretend we tried that and it didn’t work for the customer.

[15] Whether you call it a de-booking or bad receivable, Foxtrot was in the ARR base and needs to come out.  Unlike the case where the customer has paid for the period but is not using the software (where we should churn it at the end of the contract), in this case the 3Q15 renewal was effectively invalid and we need to remove Foxtrot from the ARR base at some defined number of days past due (e.g., 90) or when we lose hope of collection (e.g., bankruptcy).

[16] I think the smaller you are the more important this correction is to ensure the quality of your numbers.  As a company gets bigger, I’d just drop the “+” concept whenever it’s only changing things by a rounding error.

[17] Use NPS surveys for another, more precise, way of measuring happiness.  See [7] as well.

The Opportunity Cost of Debating Facts

I read this New York Times editorial this morning, How the Truth Got Hacked, and it reminded me of a situation at work, back when I first joined Host Analytics some four years ago.  This line, in particular, caught my attention:

Imagine the conversation we’d be having if we weren’t debating facts.

Back when I joined Host Analytics, we had an unfortunate but not terribly unusual dysfunction between product management (PM) and Engineering (ENG).  By the time the conflict got to my office, it went something like this:

PM:  “ENG said they’d deliver X, Y, and Z in the next release and now they’re only delivering X and half of Y.  I can’t believe this and what am I going to the customers and analysts who I told that we were delivering …”

ENG:  “PM is always asking us to deliver too much and we never actually committed to deliver all of Y and we certainly didn’t commit to deliver Z.”

(For extra fun, compound this somewhat normal level of dysfunction with American vs. Indian communication style differences –including a quite subtle way of saying “no” – and you’ll see the real picture.)

I quickly found myself in a series of “he said, she said” meetings that were completely unproductive.  “We don’t write down commitments because we’re agile,” was one refrain.  In fact, while I agree that the words “commitment” and “agile” generally don’t belong in the same sentence, we were anything but agile at the time, so I viewed the statement more as a convenient excuse than an expression of true ideological conflict.

But the thing that bugged me the most was that we had endless meetings where we couldn’t even agree on basic facts.  After all, we either had a planning problem, a delivery problem, or both and unless we could establish what we’d actually agreed to deliver, we couldn’t determine where to focus our efforts.  The meetings were a waste of time.  I had no way knowing who said what to whom, we didn’t have great tracking systems, and I had no interest in email forensics to try and figure it out.  Worse yet, it seemed that two people could leave the same meeting not even agreeing on what was decided.

Imagine the conversation we’d be having if we weren’t debating facts.

In the end, it was clear that we needed to overhaul the whole process, but that would take time.  The question was, in the short term, could we do something that would end the unproductive meetings so we take basic facts in evidence and then have a productive debate at the next level?  You know, to try and make some progress on solving our problems?

I created a document called the Release Scorecard and Commitments document that contained two tables, each structured like this.

release-scorecard

At the start of each release, we’d list the major stories that we were trying to include and we’d have Engineering score their confidence in delivering each one of them.  Then, at the end of every release, PM would score how the delivery went, and the team could provide a comment.  Thus, at every post-release roadmap review, we could review how we did on the prior release and agree on priorities for the next one.  Most importantly, when it came to reviewing the prior release, we had a baseline off which we could have productive discussions about what did or did not happen during the cycle.

Suddenly, by taking the basic facts out of question, the meetings changed overnight.  First, they became productive.  Then, after we fully transitioned to agile, they became unnecessary.  In fact, I’ve since repeatedly said that I don’t need the document anymore because it was a band-aid artifact of our pre-agile world.  Nevertheless, the team still likes producing it for the simple clarity it provides in assessing how we do at laying out priorities and then delivering against them.

So, if you find yourself in a series of unproductive, “he said, she said” meetings, learn this lesson:  do something to get basic facts into evidence so you can have a meaningful conversation at the next level.

Because there is a massive opportunity cost when all you do is debate what should be facts.

Win Them Alone, Lose Them Together

It was back in the 1990s, at Versant, when my old (and dearly departed) friend Larry Pulkownik first introduced me to the phrase:

Win Them Alone, Lose Them Together

And its corollary:

Ask for Help at the First Sign of Trouble

Larry told me this rule from the sales perspective:

“Look, if you’re working on a deal and it starts to go south, you need to get everyone involved in working on it.  First, that puts maximum resources on winning the deal and if — despite that effort — you end up losing, you want people saying ‘We lost the Acme deal,’ not ‘You lost the Acme deal.'”

It’s a great rule.  Why?  Because it’s simple, it engages the team on winning, and most of all — it combats what seems to be a natural tendency to hide bad news.  Bad news, like sushi, does not age well.

Twenty years later, and now as CEO, I still love the rule — especially the part about “the first sign of trouble.”  If followed, this eliminates the tendency to go into denial about bad news.

  • Yes, they’re not calling me back when they said they would, but I’m sure it’s no problem.
  • They did say they expected to be in legal now on the original timeline, but I’m sure the process is just delayed.
  • Yes, I know our sponsor seemed to have flipped on us in the last meeting, but I’m sure she was just having a bad day.
  • Well I’m surprised to hear our competitor just met with the CIO because they told us that the CIO wasn’t involved in the decision.
  • While the RFP does appear to have been written by our competitor, that’s probably just coincidence.

These things — all of them — are bad news.  Because many people’s first reaction to bad news is denial, the great thing about the “first sign” rule is that you remove discretion from the equation. We don’t want you to wait until you are sure there is trouble — then it’s probably too late.  We want you to ask for help at the first sign.

The rule doesn’t just apply to sales.  The same principle applies to pretty much everything:

  • Strategic partnerships (e.g., “they’ve gone quiet”)
  • Analyst relations (e.g., “it feels like the agenda is set for enemy A”)
  • Product development (e.g., “I’m worried we’ve badly over-scoped this”)
  • Financing (e.g., “they’re not calling back after the partner meeting”)
  • Recruiting (e.g., “the top candidate seemed to be leaning back”)
  • HR (e.g., “our top salesperson hated the new comp plan”)

I’ll always thank Larry for sharing this nugget of wisdom (and many others) with me, and I’ll always advise every manager I know to follow it.

On Hiring: Promote Stars, Not Strangers

“Well, he’s never been a sales development rep (SDR) manager before, but he has been an SDR for 3 years at another company. The chance to be a manager is why he’d come here.” — Famous Last Words

I can’t tell you the number of times I’ve heard something akin to the above in hiring processes.

Of course he’d come here to get the chance to be a manager.  The question is why his current employer won’t make him one?  They’re the ones who know him.  They’re the ones who’ve worked with him for three years.  What do they know that we don’t?

As a general rule, startups are not the place to learn how to do your job.  At startups, you should hire people who already know how to do the job.  Running the startup, in a high-growth, frenetic environment, is hard enough; you don’t need to be learning how to do your job at the same time.  A key reason startups offer stock options is precisely this:  to incent people who already know how to do the job to do it again by participating in the upside.

This is not to say, reductio ad absurdum, that startups should have no entry-level jobs, never take a bet on inexperienced people, and never promote anyone into management.  That’s a recipe for losing your best people when they decide the company has no interest in their personal development or career path.  The best startup teams are a mix of veterans and up-and-comers, but since — particular for management hires — you need to have a mix, you need to be very careful to whom you give that first-time in-the-job slot.

This is why I made the Star/Stranger Promotion Quadrant.

star promotion

The two axes are simple:  is the person a known star (at this company, i.e., do we all known her and do we all think she’s a star, here) and has the person done the job before (i.e., the actual job, SDR manager in this case, not SDR).

One of the easiest things you can do is to appoint known stars.  This means the person works today at your company in a different role, but wants to do a new job that’s opened up, and has already done that exact job before.  It doesn’t happen that often, but sometimes your director of product management has been director of product marketing before and wants to get back to it.  Awesome.  I call this “appointing” known stars because while the move may involve a titular promotion, in reality it’s more of an appointment than a promotion.  It’s great to let people move around the organization and there should be no shame in ever wanting to move back to something that someone particularly likes doing (or that the company really needs).  I shade this green because it’s low risk.

One of the nicest things you can do is to promote known stars.  For example, take a top-performing SDR who has management potential (an elusive concept, I know, but a whole post unto itself) and give them the chance to run a piece of the SDR team.  I prefer to do this — especially for first-time promotions into management — on a reversible basis.  Since neither side is certain it’s going to work, I believe it’s best to make someone a “team lead” for six months and then assess how it’s going.  If it’s going great, promote them to SDR manager and give them a raise.  If it’s not going well, you haven’t burned the ships on making the person a regular SDR again, working on some skills, and trying again in the future.  I shade this purple because there is some risk involved, but it’s a good risk to take.  People in the organization want see others given the chance to succeed as well as to safely fail in taking on new challenges.

If you lack existing team members with management potential or if your current team has too many first-time (and too few experienced) managers, then your best move is to hire qualified strangers.  While the stranger might want a career step-up, the reality is that most companies hire new people to do jobs they already know how to do.  Cross-company promotions are rare and candidates offered them should be somewhat wary.  Why again are these people willing to make me a CMO for the first time?  Sometimes the reasons are good — e.g., you’ve been a divisional marketing VP at a larger company and move into a startup.  Sometimes the reasons are bad.  Think: why won’t any qualified CMO (who knows this space) take this job?  But, moving back to the employer perspective, I shade this square purple because external hiring is always risky, but you can minimize that risk by hiring people who have done the job before.

This takes us back to the start of this post.  While depending on the kindness of strangers may have worked for Blanche Dubois, as a hiring manager you should not be extending such kindness.  Hiring qualified people is risky enough.  New hires fail all the time — even when they are well qualified for job with lots of relevant prior experience.  Don’t compound the risks of cultural fit, managerial relations, attitude/urgency, and a hundred other soft factors with the risk of not knowing how to do the job in question.  What’s more, do you have time to teach one of your managers to do their job?  Especially when what’s needed is teaching in basic management?  As I often say, VCs are risk isolators more than risk takers, and hiring managers should think the same way.  That’s why you should almost never promote strangers.  (And, as a corollary why strangers should be wary of those willing to promote them.)

That’s why I’ve colored this square red.  Companies should hire outsiders to do jobs that candidates already know how to do.  Promotions are reserved for promising insiders.

Put differently, and from a career planning viewpoint:  “rise up, jump across.”

The Three Golden Rules of Feedback

I was speaking to my executive coach the other day and we had a great discussion of feedback.  I’m going to adapt what she said into some pithy advice for managers on how to give feedback.

Here are the three golden rules of feedback

  • It has to be honest
  • It has to be kind
  • It has to be timely

Honest Feedback

When you give someone feedback it has to be authentic.  It has to be what you really feel.  It can’t be candy coated.  It has to be what you honestly feel about the situation, tempered by the humility that you may not necessary be “right” — or that right and wrong may not even have meaning in a given situation.

Example:  “I felt disrespected when you arrived late at my meeting.”

I provided a concrete situation in which something happened; I am not generalizing or pattern-matching.  I indicated a specific behavior that I observed.  I described the impact on me — how I felt about it (which is fairly incontrovertible) — without trying to speculate why you did it or what you intended.

This form of feedback is called situation-behavior-impact, and it’s a great template for giving honest feedback.

While awesome, it’s quite hard to do and (given how things went when I’ve been trained on it) seems to come naturally to few people.  While I would never claim to be a great SBI feedback-giver, I nevertheless continue to aspire to be one –because it does work.

Always be honest.

Kind Feedback

While not something I’m necessarily known for, I love my coach’s second rule of feedback.  If you’re like me, the honest part of feedback isn’t hard.  Example:

That’s the worst proposal I’ve ever seen.  You never said what you wanted to do, what it would cost, or why we should do it.  Other than omitting the three key elements of a proposal it was great.

(Or, as Larry Ellison was reputed to have often said:  “That’s the stupidest f**king idea I’ve ever heard in my life,” sometimes rather amazingly followed by, “Say it again!”)

While “honest” comes naturally to me, I really like the “kind” principle.  I stand behind the vast majority of feedback I’ve given over the years.  It’s always been honest and usually been accurate.  I’ve been unafraid to put hard issues on the table that other managers were afraid to confront.  I am proud that I have helped people identify and eliminate issues that would have otherwise limited them and/or developed strengths that helped propel them.

But I am equally certain that I could almost always have found a better way of expressing my feedback had I known about and applied the kind principle.

Being kind forces the feedback giver to focus not just on the validity of his/her feedback, but on the appropriate timing and expression of it.  It provides a second, important test — particularly for well-intentioned managers too blunt for their own good.

To be clear, being kind doesn’t mean avoiding hard issues or candy-coating conversations.  It does mean that you should challenge yourself, even during very difficult conversations, to find a way to communicate such that the other person leaves feeling respected and with their dignity intact.

Even the ultimate hard conversation — terminating someone — can be conducted in a way that leaves feeling respected as a person and with their dignity intact.  While many fearful mangers bungle termination into a personal tear-down, it doesn’t have to be that way.

Before a comment-outcry develops, I’m the first to admit that I’m not the King of kind feedback.  I am, however, going to work on it for three reasons:

  • It’s nicer.  I’d like people to want to work for me because of my feedback — not despite it.
  • It’s a challenge — that will make me a better manager.
  • It’s more effective — I can’t tell you how frustrated I get when people spend more time reacting to how I said something than I what I said.

You can generate big distractions and waste hours by giving feedback without adequate consideration for its impact on the recipient.  It’s far more effective to think up front for 30 minutes about both what to say and how to say it than to hastily offer feedback only to spend hours in damage control afterwards, simply working your way back to zero on the relationship — with most of the actual feedback long-forgotten in the process.  It happens.  I’ve been there.

Always be kind.  (Hey, I’m working on it.)

Timely Feedback

The last rule is that feedback needs to be timely.  Feedback, like sushi, does not get better with age.

Timeliness matters for several reasons:

  • Both sides are in a better position to discuss recent events than ancient history.  Memories fade and the best feedback is usually quite specific.
  • Letting feedback get old tends to bottle up anger or dissatisfaction on the part of the giver.  The manager might start treating someone differently — e.g., being curt, assigning core projects to others — without them having any understanding of what’s going on.
  • Delaying feedback often leads to “pattern matching,” where instead of discussing specific situations (e.g., when you were late to my staff meeting on Tuesday) the giver generalizes to patterns (e.g., you are always late to my staff meetings) which wrecks the SBI process and results in factual disputes (e.g., no I’m not) instead of impact discussions (e.g., it made me feel disrespected).

Being timely doesn’t mean delivering a real-time stream of constant criticism.  (I’ve tried that too and it doesn’t work.)  Nor does it mean confronting hot issues immediately when tempers may still be high.  But it does mean giving feedback within a timeframe when memories are still fresh and when the recipient doesn’t feel like “why did you wait so long to tell me this?”

Finally, if you’re going to start giving periodic constructive feedback you better get ready to give a lot more positive feedback if you want to preserve the overall quality of the relationship.  Research shows that the ideal ratio of praise to criticism is 5 to 1.  This applies not only at work, but also at home —lasting marriages have a 5 to 1 ratio of praise to criticism while marriages ending in divorce have a 0.7 to 1 ratio.

I better go buy some flowers on the way home tonight.  I love you guys.

Always be timely.