How to Create Deep Partnerships with Technical Teams

Thanks for coming today. Appreciate it. Um I'm Samantha. I'm here and I'm going to talk to you about how to create deep partnerships with technical teams. Um my sales engineering is a lesson learned. So uh how to partner together to really make partnerships fruitful between your sales teams and technical uh teams. Cool. So like I said, I'm Samantha. I'm uh the founding sales engineer at Escape. Escape is another application security uh vendor. We do dynamic application security testing. So DAST and ASM more for modern applications. Um prior to be working at um Escape, I was a security consultant at Accenture and I was h a leading part of our cyber security innovation hub. Essentially though, what I've been doing for around

the past 10 years has been partnering with security teams uh from startups to Fortune 100 companies, so big to small across different industries um globally to really help them solve their technical challenges um in different ways, right? As much as I can. So, this picture that I have up here um it's a I work with AppSac teams a lot, right? And it's a picture a face I see a lot when I join a Zoom call. Um, and I'm not like I understand where it's coming from, right? I kind of like to call it the vendor sigh, the uh another vendor call, right? There's a lot of vendors out there. Um, there's a lot of tools out

there. There's a lot of challenges that have to be solved. And for security teams, right, the security folks that I'm talking to, um, they are overwhelmed and they have a lot to do and not enough time to solve those problems, right? So, vendors are yet another thing. they've gotten a lot of promises before and they may have um had discomfort with it in the past and it's brought to this kind of view. That all being said, what I like to say is if you are able to make it happen, it becomes pretty magical, right? So, if you can get the partnership to work and the sales teams and the engineers and the vendors that you're working with and the uh security

teams are able to work together, you can actually make magic happen. And instead of it being a detractor and slowing you down and causing issues, it could really be an enabler and push you forward and really enhance your teams, enhance your efficiency overall and help to secure things e faster. So my mission today and what I'm here to talk about is making technical partnerships cool again, as I like to say, or make them not suck. Um, bringing it forward and really making it the best and most beneficial to everyone. So how do I do that? For today, I really just broke it down into five lessons overall. Um, five different lessons learned to cover kind of what

I've learned as a sales engineer being in the field for a while and what I've learned from my experiences. So, the first is technical credibility, radical transparency, shared success metrics, consistent communication, and then those little things, even the small things matter. Going the difference, right? And I'll go through each of these today. Um, and at the end if you have any questions, we'll go through. So, first one, technical credibility. What do I mean by that? Um, I put a picture of a tech wizard up here because when I go into calls nowadays, um, my account executives will bring me in and they'll be like, "Oh, here's our tech wizard." And while I love them saying it, I'm

really not a tech wizard. I have my background in computer science and cyber security, right? But I'm no expert in the technical environment of my customers that I'm in. And what I kind of look at technical credibility as more even than some of the other lessons I put up is it's really two-sided. It takes two ways to get to that technical credibility and understanding. So that communication you have to earn it together and it takes a partnership. So it's on two sides for the vendors um for myself right it's being curious and asking the right questions. So instead of coming into a call, I'm no developer and I don't know your environment as well as you do, right? It's going in and

knowing to ask the question um in the what questions I'd want to ask and being curious, listening, taking that in and thinking it through and going through and taking that to apply it to the knowledge I have because what am I what do I know really well? I know my platform and my tool really well. And on the customer side of things, right? Well, I don't know your environment. They don't know as much about my product. every product even if they the same as other products on the market they all have different different technical uh capabilities different specific requirements things like that which I know the best right so on the customer side what they can do is

provide the uh vendors with a much as much context details and needs as possible to help everyone paint that picture together and work together to collaborate to have the technical understanding on both sides So providing details into your environment, the biggest one I always say is the needs. So what are the needs? What are the challenges that you have? And going through that is very important. The thing I dread the most when I go into calls, I do demos day in and day out. When I go into a demo and the customer on the other line is silent is the thing I fear the most, right? Because what I learn from is the information and

feedback a customer gives to me that helps me better understand their environment and better understand what they need to give them the best technical solution. So um together working together you can get that technical credibility and get to the best technical solution and technical needs a person has but it definitely takes a partnership to work to it. That's lesson one. Um in terms of lesson two, what am I talking about for this one? So lesson two um is our radical transparency. So we got this nice transparent picture in some city that I got from Genai. But what do I mean by radical transparency here? Um it's having the most uh being honest with each other right in talking together. So

when I talk about radical transparency, it's it's a uncomfortable one I'd say to have because innately uh pe anyone, right, wants to make things look good, say the best things, make the other person happy, right? But it's actually very much closely tied to technical credibility in the way that sometimes the technical challenges and the technical limitations are the things you have to be most honest about. Because ultimately in the end, if you're not going to be honest about um the environment that you're talking to and the things that you're going to be working on, it will only come back to bite you in the end, right? Because no one will be happy, right? So the more

honest you are and the sooner you're honest upfront, the uh more value you'll be able to bring and the happier everyone will be in the end and the smoother overall um your partnership and engagement together will go. So how do you really do that? What do I mean by radical transparency? So ultimately like I said honesty is first but it's not just honesty it's giving context and explanation into why you're being honest and what the situation is. So instead of here I gave some examples of the better and then the less the not as great right of what you could say during a call right so instead of saying hey ignoring the bug or working around it or hiding

it from the customer saying oh we found this bug here's what we're doing about it we're going to fix it and we'll get this fixed for you on this date. Giving as much detail timelines and context to what you're talking about really helps to keep make sure everyone's on the same page. Um, if you're talking about road mapaps, right, road mapaps are really important when it comes to technical challenges, when you'll get stuff done, being clear on, hey, instead of just being like, hey, it's on our road map, it's on our road map, but this is what we're doing to achieve it. Let's get your feedback in mind, and we'll have a result for you by this date. Um, all of

that really helps to create a sense of partnership. And what I'd say from my experience working with teams is the more you're able to be honest upfront, uh, the security teams that I work with would prefer me to be honest and tell them, hey, this is a limitation and we can't achieve it than to ignore it entirely and have it become a pain in the end because no one wants to invest their time for something that they're not going to get, right? Um, in terms of experiences and examples on this, it's actually on a current uh, like PC or like proof of concept I'm working on. Um, the customer I'm working with started working with us a long time ago.

I think their first demo with us was six, nine months ago when I first um was working um with this team. And when we first demoed the product, there was the need that they had and we had a feature set that was in our tool, right? That being said, when they came back to start pcing, they came back six months later and we're like, we're ready to test out um escape. We're ready to move forward with it. um the need that they had was no longer supported in the capability and effect that they wanted, right? And I had a understanding of what their needs were because we communicated it earlier and had that understanding, but

what they were looking to achieve was no longer there even though we talked about it before. And it was an interesting situation of what do we do? How do we handle it? and I talked to my account executive and the two of us together decided to have a meeting with the customer before we moved any further into um putting hands on keyboard, setting things up, uh getting into success criteria and things. And we talked about it candidly with them to say, "Hey, we promised you this one thing. It's not going to be here today if we choose to move forward. Um but if you are willing, we could either continue on with the PC if you want or

we could push it off to this date when it will be ready for you." and the customer really appreciated the honesty, decided they did want to move forward. Like I said, we're currently doing the PC. Um but um and we discussed what a design partnership or something could look like for the thing that they wanted. And instead of promising something we didn't have and causing a lot of headache at the moment, we were able to kind of be honest upfront and then solve the solution overall and build a stronger partnership with that honesty. So anyhoo, that's radical transparency. Um, the next one is the shared success metrics. I put this one in the middle because personally I think

it's the most important one. Um, what's my rule when it comes to this? And everyone does success metrics a little differently, but before we touch a product, before we move forward into testing anything out, um, we agree on what success looks like. And it needs to be in the customer's words, not in my words. Um, this is what I use our success metrics as is the ground of truth for our entire partnership. So, success metrics could look like different things to everyone, right? It could be a checklist, it could be a spreadsheet, it could be um a picture for whatever you need, right? But ultimately, what it needs to be is clearly written down or aligned in some

way criteria on what you need to get done to be able to achieve success. So the goal I'm looking for when I draft success metrics with my customers is to say, "Okay, this is the list of things we need to get done, right? And if we accomplish everything on this list, right, and this is how we're going to accomplish it, then you're going to choose to move forward with us, right? Or you'll be very happy and be ready to take the next step. We're considering it a technical win." And um there's a lot of different things that you can have in mind when you're talking about success, right? But the kind of key questions I

always have and these kind of help to drive the success criteria overall is what are the problems you're trying to solve? How will we measure it? Who decides when we're done? What are the key requirements? What is the outcome? Things like that, right? These are the types of questions you want to have to help draft these success criteria. And then the other piece of that, right, is it's drafting it so that we're all aligned on what we're looking to achieve. But then the other piece to that is keeping it as the source of truth throughout the rest of your engagement together. Because once you align on something and you say, "Okay, this is our baseline. This is what we're

going to track to. This is our goal in the end." Then we come back to it regularly to check back in to make sure are we going and are we going are we mapping to the success criteria? Are we continuing to follow that and having those conversations to see where we don't align so that we could come back and realign there? Um, additionally, another thing I always like to say is a few other tips when we talk about success criteria, I would say, is um, making sure that everyone that needs to be involved in drafting these goals is there at the beginning to draft it and that if anyone new comes into the project or comes into the partnership,

right, they get to look at it. So you want any decision maker that's part of the engagement and testing of the product together to be aligned here and then trying as much as possible to not change it once you set it in stone. Right? Once everyone has gotten their eyes on it and everyone's given the approvals, let's keep this as our source of truth so that we can come back to it throughout. So that's kind of the concept of the success criteria and what it looks like. Like I said, there's a lot of different formats. This is kind of the way I do it a lot of times with my customer. Like I said, my backgrounds

before this was in consulting, so I'm very much used to the spreadsheets and the PowerPoints and all the fun stuff, but anyone can do it in any way they want. Sometimes my customers come to me with the requirements list. Um, there's ways people wait it. I've seen all different things. I've seen charts. Um, that all being said, I try to keep it semi-imple. What we have up here um is for our template, right, is kind of breaking down what are all the requirements and I align with my customers on like what those requirements will be, right? Here's some ones that I know as an expert and using my tool that I know people use a lot,

but also I try to customize it and create kind of get it to a customized place specific for the customer that I'm going to be working with based on what I've learned from them in previous settings. Right? So, um, taking in mind kind of the tools that they're using, the types of authentication they might have, the frameworks that they're using, all that might impact the success criteria and the requirements. That being said, you really want these requirements um to be very tangible, very clear, and not vague in any way, right? Um, from there, we then decide how we want to validate it. Are we going to validate it in the P or are we going

to do like hands-on keyboard testing it out or are we going to validate it via docs? Right? The approach that you want to take to achieve that success item. And then the last part that always I feel like is the biggest challenge for people is once you decide how you want to achieve this right and how you're going to meet this criteria item prioritizing it. And that's really important the priorities. And I think sometimes gets forgotten because people say, "I want to achieve everything on this list." Right? But you need to be realistic and you have a set amount of time, a set thing that you could work together on, right? And you want to

really be as strategic with your time. We're all busy, right? Um, and marking down maybe the top highest items, medium and low, right? To really help together everyone understand what is going to be most important to making this partnership successful and what we need to get done. um first versus what if something happens can fall off, right? Um so this is kind of how I like to do it. It guides it. I'd say this is the most critical part of keeping a partnership together on track is using uh having a clear kind of goals list and know where you're tracking towards. Um, okay. Fourth lesson that I've learned, which kind of ties into everything we

talked about before, but I do like to call it out because it is very important, is consistent communication. So, quote that I made up is a quiet PC is the only one that fails is the one that fails silently, right? The quieter a PC is or the quieter an engagement with any kind of technical team is, the more I tend to worry, right? because talking and feedback is what helps drive things forward and helps make sure that we're going in the right direction. So, there's all different ways that you can do communication approaches. Um, the first one I would say is having a clear cadence and timelines. Knowing when your next meeting is is important and keeping

that schedule very clear. Additionally, communication channel. Everyone communicates in different ways, right? Every company's unique. figuring out what's the best way to communicate. What will be the easiest? Is it email? Is it Teams? Is it Slack? I've used Discord. I've used Zoom chats. I've used it all. But knowing what would be the best way for people to communicate to respond effectively is it seems like a small thing but is very important. And then once you have that right, sending updates after milestones and meetings on a regular cadence, not just waiting for it to be perfect, but sending it on continuously so that everyone's aware of what's going on. And the biggest thing out of all of that is always have the

next steps very clear and communicate it at the end of a meeting. um in a I always like to say it at the end of any meeting send it in whatever Slack channel or teams channel we're talking about after having it documented down having it very clear for any technical project you're working on right there's work that needs to get done work on my side as the vendor but also work on the customer side and knowing what work needs to get done at what time to keep us on track is very important and having that kind of open communication uh both during meetings and ad hoc other ways will only make sure that overall everything's successful ful.

Okay, last but not least, um celebrating the small things, right? The small wins. So the little things that you do um can make a very big impact. So in sales, I do work with our sales teams, right, a lot. We always want the big win. We want the deal to close, right? But the little things that helps us get there and we can't forget that, right? um working together on small things to show your commitment to the security teams you're working with. Um how partnership would look like as you go along, right? All of that's very important to make sure um that you have an overall kind of successful uh engagement. So what do I mean by the

little w things? What are those small wins? It could be anything from troubleshooting an issue, retrying a bug for someone, improving documentation, providing information more clearly, or taking the time to jot down the notes from the meeting in very clear lists so that someone knows exactly what needs to be done next. Um, for example, I'd say one thing I get a lot is a customer will ask us questions, right, all the time. and taking those questions and instead of just giving an answer back right to the question they have a lot of times their questions are very valid like things that they it's good for us to be able to explain to them instead of just

taking it and giving them the answer of oh this is how you do it saying oh we really appreciate your feedback we actually added it into our documentation as well and updating the documentation to show that we're looking to partner with them right and looking to make it better and that we're taking their advice in mind um there's never been a time where when you do the little extra thing or show that you're in have the other team's best interest in mind that it hasn't um helped really build credibility, build partnership and build collaboration and trust. So really helps increase everything that I said on the other lessons, right? Um so that is the last one. Um so that's kind of the

overarching lessons for today. I would say kind of in summary as we went through it all. Uh what's the final takeaways? Right, first one, credibility. Um speak their language, right? Do your best to be on understand each other and share um as much technical details as you can to be on the same technical um understanding level. Right? The next one's transparency. Be honest even when it hurts. The more honest you are upfront, the better it will be down the road for everyone and it will only increase um trust overall. shared metrics. Um, my favorite one, define them clearly, define them early, make sure that everyone is in the loop when you do it. Um, and keep it as your guide

throughout. Communication. It's better to be consistent than to be perfect, right? And then the last but not least, those small wins. Um, they ripple. They're the ripple effect for advocacy. Those small things together combined will help to really make a partnership successful overall. So with that um that is my presentation for today on what I've learned and I'm here to answer any questions but yeah my presentation um it's really great to hear from a sales engineer uh because sales engineering is really critical in a product security not so much in services and as a former CEO of site tell you that the sales engineering is really critical. It is the glue between the sales people and and the customer

but also and something you didn't mention is product management. So like what the people who are designing the next iteration of the product one of the major sources of information uh and the feet on the ground the ground is is the sales engineer and it's also a great um job for people who want to be entrepreneurs to you are a successful sales engineer. you have mastered being able to talk to customers, being you know technical, being able to interface with product management and so it really is this great career. >> Yeah. No, it's a it's a it's a good one. Yeah. It's a it's funny. The first time I heard about sales engineering was at

my first internship at Hacker 1 and they had me like talking to all the different teams and I met the sales engineer there and I remember at the time I had no clue what it was. Um and they said, "Oh, this is the sales engineer. this is a really good career, you should look into it. I never thought about it for years and then I came back around. So, but I recommend >> Yeah. >> Um, how do you deal with like a difficult client? So, like communication is kind of like a two-way, you know, both sides communicating. Um, and so let's say like you're doing a perfect job communicating, but there's like a lack of communication. Super

important. >> Yeah. Yeah. Yeah. Yeah. No, it's it's there's always every customer is different. Um and there's always kind of trickier clients in different ways, too. It's not always communication. There's other things. Um I'd say there's a few different ways I guess I handle complicated and trickier customers. Um back when I was in consulting and even now. Uh but ultimately, I'd say it's asking if they're not going to give like on a communication sense if they're not going to give the to me up front. It's then really digging in and asking those questions. So, something I a lot of times do um for some of the projects I work on is I even have a questionnaire

that I fill out that I send over and say, "You need to fill out all of these questions in detail and then ask them follow-up questions on all of it before we'll even move forward because if I'm not getting that response back, I know we won't be successful." I also very much with difficult customers rely a lot on my account executives, right? As a technical person, I try to be like the good guy. Like, we're here to work together and have a good time, right? The account executive is on the sales side more and has to be a little bit more of the heavier hand. And I'll go to them. I'll be like, "This is going to go

poorly if you don't step in." And they'll come in and say, "Hey, like we need this done and if you don't get this done at this date or if you don't communicate or bring someone else to the team, we're not moving forward." Right? Because at the same time, what we like as a I want to sell a product, right? But our time is also very valuable and we won't go move forward if someone's not contributing on the other side. Right? So a few different ways to do it. But yeah, >> I think I'm at time. I'll stay down outside.