We don’t sell, we close

What’s your relationship with the salespeople in your organization? Do you even talk to them? Is there a culture of us and them in your company? Do you feel like they see your department as unwashed geeks and you see theirs as a herd of Patrick Batemans wearing Submariners? I hope not!

Regardless of your own relationship with the salespeople in the organization, you have to have utmost respect for them: they close the deals that bring in the money that keep us all employed. Kudos to them.

Although we as engineers may have a stereotype of salespeople as the hustlers of big deals, commission cheques and the wearers of flashy Swiss watches, the art of selling big enterprise deals requires real talent, artistry and chutzpah. These people are at the periphery of the business, often away from home at the other end of the world on puddle-jumper flights, fighting the good fight to sell the stuff you’re building.

What do salespeople do all day?

As a manager in engineering, it’s extremely useful to include some salespeople in your network inside the business. Before we look at some ways that you can work more closely with salespeople, and most importantly, make their lives much easier, let’s have a look at what they typically concern themselves with.

Now there are many different types of sales roles in the world of SaaS. Those roles can range from those who contact leads who have requested demos or who have been identified as prospects at events to qualify them as worth pursuing further, through to senior salespeople who spend multiple quarters crafting multi-million dollar deals. In the same way that your most senior engineers can have a dramatic effect on the future health of the company, the same is true with the most senior salespeople. A landmark deal can secure years of runway and growth.

So what do they concern themselves with?

• Building relationships. Software companies with sales organizations of a decent size will typically work on deals that are worth quite a lot of money. This means that they aren’t the kind of deals that close very quickly. The length of time it takes from a lead being qualified to the paper being signed is called the sales cycle and for the biggest deals the sales cycle can potentially be years. This means that your salespeople will be continually working on building the relationship with their prospect throughout the cycle, ensuring that what they are selling is what ultimately gets chosen.
• Solving problems with the technology that you are building. Every client has different problems that your software can solve. Your salesperson will think creatively about how your software can fit into their daily lives so that they can do their job better, faster and more efficiently. This can be as simple as demonstrating the power of the software through to building a compelling story of how their whole organization could change around it.
• Working on revenue targets and growth. Always be closing: this is slightly tongue-in-cheek with a reference to the quite epic monologue in Glengarry Glen Ross (warning: very strong language) but it rings very true: sales is about closing deals. It’s not about turning up and giving a pitch in the hope that someone will bite, it’s about being creative, hustling, getting on that plane or train, learning about prospects, getting their interest and then getting them to sign on the dotted line. Sales organizations hold themselves to typically quarterly targets and they have to hit them (and you thought that your deadlines were bad). They’re the frontline indicator of the health of the business. If they’re closing lots of deals, it’s probably a function of their confidence in the product and the great work you’re doing. If they’re having a bad quarter, it could quite possibly be an indicator of something else that’s wrong in the organization, but they get the flak. Remember this.
• Understanding what the market wants to buy. They are uniquely placed to see what kinds of problems clients are trying to solve and what kinds of existing tools they are using to do it (if any!). They can also use the relationships they build to see that there are entirely new, untapped areas of the market to sell to. Also, they can alert you to when there are cheap ambitious startups that are trying to undercut you. Is the market becoming more specialist and is after point solutions rather than software suites? Is the market becoming more price sensitive and as a result you need to adjust yours?

So now we’ve taken a look at what salespeople concern themselves with, how can you help them do their job even better? Let’s be honest – it’s a world away from you working on the code with your team. Or is it?

How can you help salespeople succeed?

There are a number of ways that you can help your sales staff do their job really well. Let’s take a look at some of them.

• Get to know them. You’ll have more in common with them than you think: you’re making the stuff that they sell! Introduce yourself, spend some time talking to them about their job and what their current challenges are. Buy them a coffee and have a chat. As mentioned at the beginning of the article, some organizations have an us and them culture between engineering and commercial. You can bridge this gap.
• Prioritize uptime, speed and stability. You might have the best features in the world, but if they’re slow, buggy and ragged around the edges then that won’t matter one bit in a demo. Keep experimental or slow features behind feature flags. Ensure you’re fixing stability issues as a priority. Remember that demos may be occurring on different continents to the one that you’re on, and consider your SLAs carefully. A simple, fast tool can make a feature rich slow tool look awful when they are pitched side-to-side.
• Deliver on time. Since the sales cycle can be a long one, especially when your software is going through lengthy procurement procedures, remember that your roadmap is a key persuader to the potential buyer. If you’ve promised to drop a feature this quarter and you don’t, then your salespeople will look like they’re overpromising or that there isn’t company-wide alignment on the story and the discipline of delivery.
• Work on cadence. In addition to delivering on time, you’ll want to work on your cadence of delivery with your team. Software that has regular updates looks cared for, alive and driven by creative people. Sequence your projects so that you can keep releasing new things regularly. If you have large pieces of architecture work that will take months to complete, try to combine them with lots of small enhancements so that your salespeople can show that you’re always shipping.
• Promise at the right granularity. This point is aimed more at product, but you can help lobby the cause as an engineering leader. Roadmaps that go into to much granularity before the unknowns have been worked out will fail to deliver. Prime your salespeople with roadmaps that provide high granularity for features very close to release, but talk in general terms about what you’re doing six months from now. Describing that the latter half of the year will concern itself with “solving our most common data export problems” is better than saying you’ll be “allowing data export from all 25 components” because it gives you more flexibility in the scope of the project. It’s hard to fail at the first promise.
• Use their expertise as stakeholders in new projects. If not already, as per your product marketers, invite key salespeople to join your team’s demo meetings and kick-offs for new projects and solicit their feedback regularly. They’re working on the periphery of the business and have some of the most up to date information from the field: key missing features, what competitors are selling, and how you stack up against them.

In summary

The sales staff in your organization have more in common with you than you might think. They’re fantastic people to have closer to your team to get a temperature check on what you’re building, and they have the most up to date information on how you’re stacking up against your competitors. Go and talk to them.

Thank you to Joakim Nilsson for the comments and feedback on my draft of this post.