Ever been in meetings where sales and engineering just talk past each other? Maybe even point fingers at each other?
Last week, David Glick (CTO, Flexe) and Adrian G. (VP, Business Development for Flexe) spoke with me about how they’ve built empathy and trust between engineering and sales teams as well as with customers.
So what if engineering and sales teams sometimes speak Thai and Greek? Dave and Adrian have created a language of metrics and ownership. With a quarterback-led execution engine that reminds me of Amazon/AWS, Flexe naturally converts learnings in the field into roadmap planning and faster decisions for customers. They’re in this to win!
Thanks Dave and Adrian for the great conversation 🙂
The fastest learning occurs out in the field
Anu: [00:00:00] Dave, what was it like when you first joined Flexe?
Dave: [00:00:03] After spending many years at Amazon, it was like taking a time machine back to 1999
Anu: [00:00:59] And you were joining as the CTO, Dave?
Dave: [00:01:01] We had about 12 engineers
Anu: [00:01:08] Adrian, how do you feel about the organization growing and evolving since Dave joined?
Adrian: [00:01:12] I was employee number 11 here at Flexe. I’m going to take my perspective a little bit further back to well before when Dave joined. When I started, it was me sitting in and a chair next to Karl, the CEO, Francis and Ed the other co-founders right there. The one engineer that we had, it was like sitting on the catty corner to me, the inside sales guy that was working the phones. And like our one or two operations people and an ops manager, like that was the whole business when I started. When I got here our tech only had one unit of measure and that’s a pallet. In the code that was PL for pallet, you could move pallets in and you could move pallets out. I was a part of us bringing in our very first e-commerce customer.
[00:01:46] Now, today, fast forward six years, e-commerce is more than 50% of our business and we’ve come a really, really long way. But I remember when we did our first e-commerce deal and it was a big, bulky ship alone, ship as-it-as customer. I went out, we met with the customer and figured out what a really strong value prop for the customer. That was our first foray into e-commerce and I came back, talked to our engineers and I was like, guys, we can do this. All you gotta do is go into the code and change PL to say EA for each. And your shipping and your shipping eaches, and now we’re doing e-commerce. So that’s kind of what we did to expand our code, to be able to support our first e-commerce customer.
[00:02:18] And we actually pulled that off and it became a really fruitful multi-year long relationship. That’s kind of where we started. Where we are now, we’re worlds and worlds apart, but are we doing a lot more complex things like that and our tech is capable of stuff that many WMS systems are capable of, but the transition has been remarkable. And of course Dave, and all the people and engineers that he brought in has been a huge part of that. I’ve been fortunate to witness a lot of that evolution, which is fun.
Adrian: [00:03:16] I think as we’ve matured a little bit as a business, when we first started this company, we really wanted to be a software company. And I think one of the things that we learned as we got more and more embedded with our customers is that you can’t play in the warehousing and supply chain space without rolling up your sleeves and getting your hands dirty, without becoming an expert at running a warehouse. To run a warehouse, you have to actually get out there and see it and live it. And so I think that’s a lesson that we’ve learned as we’ve matured over time as a company and started to place more value on having everybody out in the field as much as early as we can. And that’s something that I think we had to learn as we transitioned from being just a technology business to a technology business that provides supply chain services.
[00:02:40] I’ve been in sales in this industry for about 15 years. And prior to COVID, it’s a pretty heavy travel job. Before the pandemic hit, we were traveling almost every week and to this day, every time I go out into the field, I have some sort of an epiphany about how insightful it is and how impactful it is to be actually out in the field, out in front of the customer or at the warehouse. You learn something that you just could not possibly have learned over a phone or an email or a Slack message. It just continues to blow my mind every single time I get out in the field, and come back so energized and fired up and like pushing everybody to that you need to get out in the field because that’s where the action is. And that’s where you learn the quickest.
Not meeting our numbers? Must be the salesperson’s fault!
Anu: [00:00:00] It’s sometimes hard to convince engineers about the value of sales and salespeople. Have you found yourself doing that? And if so, how do you convince the engineering team about the value that sales brings?
Dave: [00:00:09] One of the things, when I got here, all the engineers were cribbing and saying, Oh, we’re just chasing revenue. If we don’t get to work on our technical debt, we’re not building a strong infrastructure, are we just chasing revenue. My first response was like, yeah, that’s our job. We’re a startup. Our valuation is determined based on our revenue. I told you, I flew out to this warehouse and the first couple weeks, and as I came back to corporate, we got that customer stabilized, but then we were looking at our next customer or we’re doing a big peak pop-up for, and they had a bunch of requirements. And the theme was like, ‘Oh no, we’re just going to run from this customer to the next customer.’ So I scheduled a meeting with the team and I had the finance guy to come and bring me two slides. One was our valuation without customer A and the other was our evaluation with customer A. And I was like, this is why we are going to drop what we’re doing and work for this customer. And over the years, we’re going to have many customers. Today, we only have one customer that size. The sales guys were out there selling to these folks. And now it’s our turn to deliver. One of the things, if you don’t have good relationships between sales or tech or operations, you lose empathy. And all people see is like, ‘Oh, we’re not meeting our numbers. Well, that must be the sales folks fault.’ Sales guy comes, ‘I need you to do this.’ And the engineers are like, ‘Well, why do I need that? That’s dumb.’ Then the next thing I was like, ‘Okay, take the engineer to the meeting with you next time.’ And you were sitting across from the customer. He said, ‘Okay, well, you know, we can do the deal or we can not do the deal, but if you want us to do the deal, this is what you need to deliver.’ That’s what the sales guys deal with every day.
[00:01:26] We have expression from lean, the lean six Sigma stuff. I’m not super into that, but there’s like a few key vocabulary words. One’s the gemba, which is Japanese for shop floor, where the action happens. We need our engineers to spend time in the gemba and that can be either with the associates on the floor, seeing error messages pop up because our software is not good or equally as important, it can be where the sales team is out in the field working with customers and seeing that interaction. The closer you get the engineer and the customer or the product manager to the customer, it’s much harder to dismiss their needs.
Money and Metrics – The Unifying Language
Anu: [00:00:00] You’re describing almost seems like a mismatch in vocabulary or language between teams.
Dave: [00:00:04] I always joke that there’s not even, like we’re speaking French or Spanish we’re speaking like Thai in Greek, like a whole different character sets. It is important to have a common language and one of the common languages we speak is money. Top line metrics and close rates . In the end, you have an output metric,
[00:00:49] Adrian: [00:00:49] I want to go back to something that you were talking about. We’re a solution that is pretty heavily focused on large enterprise companies, which is to say that we’re in consultative enterprise solution selling. The supply chain industry it’s an industry that is largely built on customized solutions that have been provided by big legacy
[00:02:07] That puts it into context. The thing you said earlier, Dave, where if you don’t get engineers out in front of the customer often, when salespeople bring these opportunities, you say, ‘Oh, this client’s super bought in. It’s this multi-million dollar opportunity, but we just got to build this one little thing,’ and then the engineer says, ‘Well, why do they really need that? Do they really need that? Why can’t you just push back?’
Dave: [00:02:25] Yeah. you heard this maxim that don’t bring the engineer solutions, bring them problems because what happens if a salesperson is hearing the requirements from the customer to the engineer, either stuff is lost in translation, or they may not deeply understand it. What we found often happens is when we put up a product person or an engineer in front of the customer, they can have a conversation about do you really need that? Or what if we did this, and they have the context of what we can build that’s easy and we can build that’s hard. If you’re playing telephone in there, it’s much less effective and we’ve had at least two or three cases where we had a hard requirement to do that. So when we sent our lead product manager out and he’s like, ‘Oh, well, could we do this instead?’ And they’re like, ‘Oh, sure. That would work great.’ Reducing the number of links in the telephone game is super important.
Mechanisms to build Ownership: QBRs, Deal Health Indicators, and more
Anu: [00:00:00] I think what you’re describing is ownership to me, if you’re bought in from the beginning and you understand the core of the issue that you’re trying to solve, if you’re owning the problem, rather than the solution, where there could be multiple ways to solve it. And I was going to ask if there are any structural mechanisms or processes that you employ today in making sure that there is more ownership built into the process from the beginning, rather than reactively entering each situation.
Dave: [00:00:23] I think there’s a couple things that we’ve done and Adrian, you can tell me if you agree with this is one as for our existing customers, we do quarterly business reviews. So I’ve asked that one of my product or tech managers attend each one of those. That’s a good mechanism because it’s very easy to see if they are invited on the calendar or whether they showed up or not. And then when we talked about deal teams, which is something I wouldn’t say is the mechanism yet. We’re learning as we go, but we are assigning a TPM or an engineer to a specific project. Now they have ownership just as you said, they have ownership and delivering that.
Adrian: [00:00:55] Yeah. Those are both good examples. One more I’ll add is a mechanism on the sales side and how we help our salespeople think about the health of their deal. Going back to enterprise sales, these are complex sales. One of the things that we found to be true, and this is a stat that the challenger sale people put out is that, in enterprise sales, on the customer side on average there’s 5.7 stakeholders in every decision that gets made when an enterprise company selects a partner or a vendor. One of those stakeholders, oftentimes more than one of those stakeholders is the technical person on the customer side. When we get into fulfillment deals or distribution deals for our customers and we set up solutions like that, there’s an integration required, which necessitates that the tech people are speaking to the tech people. Our tech people are talking to the customer’s tech people. One of the things that we’ve set up as a mechanism is
Mechanisms until muscle memory
Dave: [00:00:00] I think we set up around the same time was we called the deal review board and
Adrian: [00:00:30] Salespeople, process is not the forte of many salespeople. Salespeople, generally speaking, like to just go sell stock and do things. And
lnew operational rigor that was just happening naturally. These teams that were actually working quite well together on their own and able to autonomously make these decisions on their own without the need for bringing a deal and do a big committee review with all of our executives, we found that our process was actually the supporting or deal flow on its own. So that was a good thing. Another sort of maturity curve for us.
Quarterbacking beats process
Anu: [00:00:00] What I’m hearing is that you would love to have the sales person be the TPM for the customer, but also sort of part of your team.
Dave: [00:00:06] There’s a bunch of things. One is someone has to be a quarterback, but let’s not put the label of TPM. Someone has to be the captain of the project or the quarterback. We’ve tried to figure out where that sales folks maybe doing 10 deals at a time. They’re out in Chicago or Atlanta. We’d love to have them be the quarterback and be running all the plays what we found, they sometimes need some help. We’ve started to hire TPMS. We’ve got product managers, we’ve got technical project managers. And they flow back and forth between those worlds. You want to have as small a core decision-making team as possible, you want to have one quarterback, maybe you have
like a quarterback and running back together and that’s the deal team.
[00:00:40]Then they’re going out and fighting, solving problems on this side and that side. People keep coming up with RACI charts and we need to assign the roles and we need to see how deals flow from one role to another. But if you think about it, it gets super iterative. If you had to have an arrow for every iteration and then you shoot yourself in the head, it’s too complex. What I found has helped a ton is bringing senior level people with high judgment in and put them close to each other metaphorically. Then they can go reach out their tentacles, to the people they interact with. And the answer is it can’t just be one person. Like the sales people can’t touch every part of your organization, especially when we’re doubling every year and they’re in the field. And we were all at corporate, it’s changed a little bit in the zoom world because we’re all in the field now.[00:01:18]
Sales vs. Process
Anu: [00:00:00] Just tying back to the point that you were making earlier, salespeople aren’t tuned to abide by the process, but some of the process comes naturally and gets built in. How did that begin to shape up in a constructive way?
Adrian: [00:00:10] You have to have process because you have to have a scalable way of getting your solutions out the door for your customers. I’d made that comment a little bit tongue in cheek, that salespeople aren’t great at processes.Probably some salespeople that I offend by saying that. When I say that it’s true because salespeople get to live on the outside of an organization. They have to live out there in the wild where the customers are, where there is no process.
Adrian: [00:00:44] A salesperson has to be malleable and creative and inventive with regard to process. And so that’s why salespeople sometimes get a bad rap, but really they’re just trying to present the best view of our business to that customer, which sometimes requires that you have to be a little bit malleable with our approach and our process.
[00:01:01] You have to have internal process, at least as the benchmark, because
Recalibrating GTM: Focus energy on what you can win
Anu: [00:00:00] Just zooming into one of the examples you were mentioning earlier. You get into a meeting where a large deal is on the line. How do you think about that specific requirement that maybe nobody else will have, but this large deal will require?
Dave: [00:00:11] You know, warehousing is warehousing. The vast majority of people. Don’t have specific needs. When I was at Amazon, ‘Dave you’re just from the U.S. You don’t understand Europe, or you don’t understand Germany.’ Like, ‘Okay, well, Germans are different? Do they not like low prices, fast delivery and big selection?’ We got them sorted. And then we went to China, like, ‘Dave, you don’t understand. Chinese are different.’ Like, ‘Well, do they like getting their stuff fast and cheap, and big selection?’ I’m trying to think back to a single time when we’ve had a request from a customer that we shouldn’t build into the platform
Adrian: [00:01:17] Yeah, that was definitely part of our maturity curve, certainly as a salesforce, as we’ve grown up as a company. There was a time when our salespeople were not, way earlier days when, we were not as
[00:01:54] We were just trading one thing that was on the roadmap a little further down for something that was sooner. That was kind of right around the time that you joined Dave, but we were recalibrating our go to markets and be focused on core use cases that are on plan, that are good fits for the fundamentals of our value prop. And retraining the mindset of our salespeople to be focused on looking for customers that had needs that were a good fit for us if it wasn’t something that we currently supported.
Anu: [00:02:16] What did it look like for the salesperson now talking to the customer versus earlier?
Adrian: [00:02:20] Going back several years
Dave: [00:02:55] It was an interesting meeting because we had a team that was working on that strategy behind Flexe and this thing was going on and on. It ended up being super satisfying. We ended up with a great result, but we spent a lot of time thinking about what the strategy is. Finally, Adrian and I walked into the room and said, look, I need you to answer two questions. What do I tell the salespeople to sell today? And what do I tell the engineers to build tomorrow? Answer those questions and we can be done with that and put this to bed. We came up with three or four things and it was heavy, bulky, single item fulfillment, a couple of other things, and we call that low complexity e-commerce. We’re only shipping singles at a time. That was Adrian, go sell low complexity e-commerce. Dave, go build medium complexity e-commerce that included primarily multi-unit shipments. We’re building
Adrian: [00:03:47] It ultimately winds up being a good thing because
Sales Org Design
Anu: [00:00:00] The biggest question that comes up is designing sales organizations. a lot of what I’ve heard right now is cross-functionality. How do you think about designing the sales organization? Of course, part of it includes mechanisms of engagement with engineering team,
Adrian: [00:00:13] It’s a little bit of thinking about this yesterday. This may seem like an obvious point, it really comes down to you just have to have a really good understanding of the personas on the client side of who you’re selling to and where they need you to meet them in that conversation so that you’re most effective.
[00:01:18] For any business, first, you just have to really deeply understand the persona of your client. And then you can figure out what the best sales persona is the works for your business. We had to go through a little bit of trial and error to learn that.
Anu: [00:01:29] And were these multi-faceted teams report directly into you or do they report into success of levels of management? How do you keep in touch with all of the field teams?
Adrian: [00:01:37] All the sales teams do report up to me, but what makes the sale itself complex is you’re going to have different stakeholders from different sides of the business. Multiple technical stakeholders and folks from Dave’s team TPMS or engineers or integrations engineers we’ll have someone in network development, operations, solutions, engineering. Those folks all report to different parts of the org. But one of the things we learned as a business, as a whole, with our go to market, Is that sales can’t win alone. It takes an army to go win a deal. We had to get everybody at the business aligned around the sales roadmap and the sales plan, what our sales targets were, help them understand that we need you to be part of the deal team in order for us to win these customers. And so it’s a team sell and we just needed everybody at the company to understand that.