How Developers Can Communicate Better With Customer-Facing Teams
The explosion of the SaaS sector and rise of DevOps showed the tech industry what’s possible when developers and salespeople fluently speak the same language. So why are so many engineers and account executives still exchanging caveman grunts in a joyless Slack channel?
It’s probably because many companies haven’t defined what that “same language” looks like. In most sectors, engineering and sales are still separate organizations with distinct skill sets. And when it comes to dismantling old siloes, telling engineers to work on their so-called soft skills or encouraging salespeople to boost their technical know-how isn’t enough.
The keenest companies, by contrast, are creating new communication models and rethinking team structures to make sure salespeople have the knowledge they need to excel.
At contract management software company Icertis, a designated pre-sales engineering team helps transfer knowledge between the product team and sales organization, while a product marketing team helps translate features into compelling language for salespeople, senior director of sales enablement JP Mantey told Built In.
“If you’re a sales director and you want to know something about the product, you could go and speak directly to engineering,” he said. “But what’s going to be more effective is for you to go to product marketing or pre-sales and say, ‘Hey, what are we trying to accomplish?’”
Meanwhile, at Balena, a platform for managing fleets of connected devices, a commitment to treat all employees like engineers helps break down barriers between teams, director of product experience Shaun Mulligan said.
“Good or bad, we want to treat everyone in the company like an engineer in that they have the power to solve problems as they present,” he said. “So there’s less of a perception like, ‘Oh, I’m on a super badass backend engineering team.’ Everyone is comfortable enough to talk in both directions.”
Mantey and Mulligan shared their tips for how to facilitate better communication with your customer-facing organizations:
Here’s what your sales and customer success teams need from you:
- An explanation of why a release matters. You have more to offer than a technical explanation. Help them articulate the release’s value to customers.
- Visibility into development timelines. Often, developers don’t know when deliverables will be finished. But making estimations is a skill you can practice.
- A thoughtful team structure. Could an intermediary team make communication easier for everyone?
- Fewer middlemen. Sometimes, the most helpful information comes from the people in the weeds.
- Some research into their roles. Do you really understand what their jobs require?
- A willingness to learn. By seeking out customer stories now, you make their lives easier later.
Developers should play a role in articulating value for customers
Much of the talk around communication between engineering and sales centers on the challenges of unpacking technical concepts for a non-technical audience.
Don’t be mistaken: This is an important professional development area for engineers. But even a developer that can give a perfect, detailed-but-not-overly detailed explanation of a release’s technical components has only provided her customer-facing counterparts with half the equation.
“The salespeople need to understand the actual value of that feature. I think often that’s where problems arise,” Mulligan said.
Labeling developers as the builders and salespeople as the storytellers ignores an important give and take. During the development process, engineers draw on customer stories to drill down and define a new feature’s purpose and value. While those customer stories likely came from the sales organization, Mantey said, salespeople still need to be looped in on the final value proposition.
As the release is deployed, he noted, salespeople will further refine that value proposition in light of customer feedback. But until that feedback starts coming in, developers can help give salespeople a strong starting point by making it clear how the feature ties back to the customer needs that inspired it.
Improving visibility is an ongoing effort
One of the most frequent pain points between sales and engineering is confusion around product timelines.
“Sometimes we get sucked into the expectation that just because we’re currently building something, we’ll get done very soon,” Mulligan said. “But just inherent in the way making software works, sometimes it takes way longer than we expected. In those cases, we probably shared a little too much information up front.”
So, if sharing information can set the wrong expectations, and not sharing leaves customer-facing roles in the dark, what’s an engineering team to do?
Balena is in the process of building an internal tool that will let people on any team query the status of projects. The platform will also host customer data, so Balena can give engineers access without paying for all of them to use Salesforce. It’s a work in progress, Mulligan said, but eventually he hopes it will improve visibility for both customer success and engineering.
That’s not to say the new tool will fix how difficult it is for developers to estimate delivery times on new features. Like any skill, Mulligan said, engineers get better at it by practicing over time. But it helps to make expectation-setting part of professional development for engineering teams, so they have the chance to explore what works and what doesn’t.
Hybrid teams can improve communication
If information doesn’t flow smoothly between your engineering and sales teams, an intermediary team may help.
In addition to product and sales teams, Icertis has pre-sales, product marketing and sales enablement teams supporting cross-functional communication. Pre-sales, for instance, works with prospective customers to understand their existing systems and processes. Then, they configure and demonstrate new technology based on the prospect’s needs. This provides salespeople with valuable insight into prospects’ technical needs, while feeding information on potential pain points back to the product team.
At the same time, Icertis’ sales enablement team holds weekly jam sessions with salespeople to review new releases and share customer stories that may lead to new talking points. Many of these sessions are stored in a central repository so the product team can access the customer stories as well.
Mantey described Icertis’ product, sales enablement, pre-sales and product marketing teams as four sides of a diamond that stretches and shifts to prioritize what’s most helpful at a given moment: “That diamond is constantly flexing to give the organization what it needs, whether it’s more technical depth, or ability to demonstrate what Icertis can do, or the ability to articulate what a certain functionality means to the market, or the ability to storytell,” he said.
Let hands-on developers present to sales
Other times, adding middlemen between engineering and sales creates more problems than it solves.
For example, just because there’s an audience at a presentation of a new release doesn’t mean a product manager needs to be at the helm. Sometimes, the developers who spent the most time in the weeds are the best equipped to explain, Mulligan said. That also provides an opportunity for customer-facing people to build relationships with the developers most familiar with the product they’re selling.
Along those lines, Balena’s internal query tool will group developers by project history and expertise, so customer-facing employees can quickly see who is most knowledgeable about particular functions and use cases.
“For smaller, quick stuff, we don’t have those siloed teams, so [customer-facing employees] can go directly to engineers with questions,” Mulligan said.
Switch up responsibilities for a flatter company structure
A real understanding of what a salesperson’s job requires organically improves communication.
At Balena, engineers cycle through customer support assignments to get a better idea of what problems customers encounter and what challenges the customer success team faces. By building a stronger connection with users, they learn to speak the language of their customer-facing counterparts.
“It forces them out of their comfort zones and encourages a lot of user empathy,” Mulligan said. And since user empathy is the name of the game for customer success professionals, it also helps engineers relate to them better.
The inverse of this is true as well. At many tech companies, customer success and salespeople can code. Giving them the chance to do so helps them stay up to speed on product innovations — and also reduces the “backend badassery” Mulligan mentioned.
Balena holds “hack Fridays” where customer-facing employees take the day to build features using the platform. So, the next time a customer has a question or technical issue, they’re better prepared to respond to it themselves.
Remember that sales has a lot to teach
There’s a lot of information engineering needs to relay to sales, but don’t let that distract from the many ways developers can learn from salespeople.
Balena’s customer success team often works hand in hand with engineering to fix major problems, like when a large number of connected devices go offline at once, Mulligan said. While engineers have the technical savvy to find what went wrong, the client-facing team’s knowledge pushes the group toward a solution that’s affordable and palatable for the customer.
“The customer success people also go explain to customers at a technical level why the failures happened and what we were doing to fix it,” he added.
At Icertis, the pre-sales team gets out ahead of new releases, running beta programs with clients and feeding the results to the product team. The head of pre-sales is a “heavy influencer” on the product team, Mantey said, with a foot in both worlds.
“That ties into how our product evolves. It’s a continuous loop of feedback from customers coming from the pre-sales team, like what they’re seeing on the front lines that people need, or special industry-related things they’re asking for and how our product might flex to accommodate that.”