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 where we were first flying out to the warehouse rolling out our warehouse management system. And a specific example was we had signed a big deal. I think at the time it was the biggest deal we’d ever done. And we’d made the choice that we were going to run some pieces of the software on the native WMS, from our operator partners and some of the software in our WMS. And it ended up being not a great user experience for anybody. And we were getting calls from the customer every day saying they were going to fire us. We were getting calls from the warehouse who were upset and we ended up flying out with a bunch of engineers. And we took the red eye out and worked about 16 hours a day and we were rolling out software every two or three hours. After, I guess, 10 days of that, we were able to get to a point of stability and the customer was happy. The operator were able to do their jobs. That felt a lot like my experience in 1999, when we were building our first big automated FCs at Amazon. So that was like, fantastic.
Anu: [00:00:59] And you were joining as the CTO, Dave?
Dave: [00:01:01] We had about 12 engineers which isn’t very many and now we’ve grown it significantly more. And so we get to the point where we’re not just firefighting.
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, which is, are we going to hit our plan, our top line and our net revenue plan. That’s a good one to bring the engineers into it because we don’t, talk about it necessarily at stand ups. Sometimes we do. They don’t come to the monthly business review or the weekly business review that engineers. So they don’t see any of these things. It’s important for us to put things in context for them. If we’re closing less deals, which is leading to lower valuation, which is directly affecting our compensation. That is one way to translate. So I always do a monthly stand up for the team describing what’s going on in the business, where are we at with the revenue plans?
[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 service providers like big 3-PLs, big transportation management companies, et cetera. Customers are used to very customized solutions that are very specialized towards their business. The drawback of the traditional solutions is that it tends to be kind of rigid and there’s a lot of fixed costs and CapEx required to go stand those things up. And we’re the antithesis of that. We’re fast, nimble on demand. When we go out and sell to a customer we sell on the merits of the business model and the unlimited scalability and the flexibility. And when you have the engineer in that conversation, what happens is the engineer gets excited too, because you see the customers starting to buy in, and then you hear the customer talk about this one specific little thing that they need that is a technical requirement that we don’t have. Now we’re having a discussion or the wheels start turning where this is the empathy builder part, where the engineer hears that. And they go and they get excited. Like the salesperson does like, ‘Oh man, Like we’ve got this client, it’s a multi-million dollar opportunity. We just got to close this one little gap from a tech perspective. We’ve got to go build this thing or this feature that this customer needs for them to be able to do business with us.’
[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 this notion of deal health indicators. That would be things like, do we have the decision maker involved? Are we doing decision-maker facing proposals, is the client willing to go out in the field and do site visits? One other is, do we have tech to tech engagement? It’s a forcing function for the sales person to think, ‘Well, how healthy is this deal? Do I have my tech people speaking to the client’s tech people? And if I do have that level of engagement, then that’s a good indicator that the client has leaned in to the partnership. And if I don’t have tech to tech, is that because we’re not doing an integration and the solutions just not that technical or do I not have full engagement from the customer and I haven’t closed that loop yet. It’s a way of programmatically thinking about how we get our tech people involved in the conversation with the client’s tech people and make that an intentional part of our solution cycle.[00:02:22] Dave: [00:02:22] We have a couple of customers who we’ve got good relationships with the VP of tech for supply chain. He or she will be, ‘Hey, we don’t want to be the bottleneck. So we’re going to go ahead and do the integration and let the business guys figure it out later. Those are my favorite because those are super proactive folks, they usually end up coming from Amazon or Walmart and we’re like, we never want to be the bottleneck. And so let’s get this sorted out and then we can hand it over to business.
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 it was interesting. I loved it because I got visibility into what was coming down the pipeline and it allowed me to buy in and to have ownership. I think Adrian felt like we were trying to gate his deals and kill his deals. and I think we ended up doing another rev, another version. We changed the name to high priority deal review or something. So it wasn’t a board or a gate who could stop it. It was just visibility and ownership building for the operations and tech team. I don’t know if that’s the same way you remember Adrian.
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 there’s good reasons for that by the way, which we can get to later if you want. But the deal review board was an interesting thing for us. It was a good thing in many ways, because: One, it was a forcing function for us. We’d bring a deal and evaluate it as a team where all cross-functional stakeholders are looking at the business. And if there were any small gaps or trade off decisions that had to be made, we all made those together collectively as a group, but the cool thing about the deal review board was if we decided we were going to work a deal, then we would go all in. We were playing a win.[00:01:08] In our industry with the solutions that we develop, it really is a cross-functional team effort. It’s a team sell. This is not something that you can be the best salesperson in the world. You cannot win a deal in this space alone. You have to bring a team with you. We’ve pivoted later because we had built in enough 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] But having someone at corporate and someone who’s out with the customer, if you can get those two people there, you’re going to do pretty well. If you have ‘I’m going to hand you this, and then you have me back and then you’d have me this, and I’m going to hand it over here,’ then you’re screwed.
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.
[00:00:31] When we think about our go to market effort, we want to wrap our business and our process around the customer. And in getting enterprise B2B sales deals done, what’s more important is the customer’s process and how they buy is really the more important thing.
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 you can’t just be randomizing everybody on the team all day, every day, that just doesn’t scale. We have an internal process too. But what we’re trying to do is tune the process to be adaptive to the way that our customers buy, which means, to get very specific, there’s multiple aspects of developing a solution for a customer. You have to develop an understanding of the operational scope or the operational profile. So that’s understanding things like inbound and outbound volumes and inventory on hand. Then you’ve got another work stream, which is the technical integration between our tech stack and the customer shopping cart or their ERP. Then you’ve got a legal track which can sometimes be a really long arduous process, especially with big enterprise companies. You’ve got the network development sourcing effort where we source warehouse partners that we bring to the table as part of our solution for that customer.[00:01:47] What we’ve tried to do is set up our process in a way that these different work streams that all have to be completed to get a deal done can happen at different points in time, can run concurrently. We try not to bog one aspect of the process down because we haven’t started or completed a different aspect of the process. It’s a nonlinear motion. We love it when everything just flows in a linear fashion, but the reality is more often than not, the deals are messy and they don’t follow a set deal flow. So we’ve tried to set our process up in a way that is supportive of that and adaptable to the way that our customers and their businesses work and the way that they buy and the circumstances that they’re in.
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 since I’ve joined here. And I can’t think of any. We have requirements from a customer that we don’t support quite yet. And that was something we have to sort through this customer, but lots of people have multi-SKU pallets. So great. Let’s put that in the platform. We want to manage the expiration dates. Oh, we don’t have that, but that customer wants it, but there’s half of all the legit spends in the world’s CPG companies. Every single one that needs expiration dates. What we try to do is say, how do we solve this in the short term for this one? But also let’s try to think globally, act locally. Let’s try and make sure we build something extensible even if it’s a hack in the future. But I don’t know, Adrian, if you know any who are in like a customer specific thing that doesn’t make any sense.
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 well-versed on what was on the roadmap from a tech perspective. We were looking at opportunities that had little feature dev requirements that were not scalable. They were not features that were required by the broad market. And we had to sort of recalibrate the way we thought about our go to market, retrain the mindset of many of our sales team to not prioritize those things. To look elsewhere and be focused on things that were good feature dev requirements. We had to make a trade-off decision for the roadmap that it was a good thing.
[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 and I’m being sort of vague intentionally there, but we were really kind of just trying to sell quote unquote, on-demand warehousing and fulfillment. And so what we actually had to do is get really granular and really defined the core use cases that we supported, what was included within that use case and what was not included within that use case and charged the sales team with just going out and selling within those use cases that we currently supported. It was a short-term strategy that we said while we’re good at these things, we’re only gonna focus on selling these things. But then later as we release new feature functionalities that opens up to him for us, and then we can actually expand our set of use cases, but that’s how we did it.
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 expiration dates support, serial numbers support, and things like that, which allow us to do more SKUs with a greater TAM and so on. But that was a good exercise. although it was frustrating for me. I don’t like it thinking about stuff, I like doing stuff.
Adrian: [00:03:47] It ultimately winds up being a good thing because you free the salespeople up from burning cycles on bad fit deals, and that’s what they really want. Just focus your energy on stuff that you can win.
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. We talked a little bit about, within enterprise sales, there’s 5.7 stakeholders in the decision on the client side. One of the things that we learned early on is that for our salespeople to be effective, they have to be great deal quarterbacks and have experienced managing complex solution cycles. Our sales motion is very much not a transactional vendor type decision. It’s a sort of strategic partnership decision. And then we learned early on that our salespeople have to be supply chain experts so that they can go have an interesting, consultative conversation with the customer, have credibility with the customer and actually be able to give the customer real advice and guidance as to how they think they should set up their supply chain going forward. Once we figured out that that was our winning formula, we had to hire salespeople that could manage a complex enterprise sales cycle, a multifaceted deal team, and could have an intelligent supply chain conversation with the customer. That just made it easier for us to hire and got a lot more specific about our hiring decisions.
[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.