▲ Community Session: What is a Forward Deployed Engineer?

Hello, welcome to this week's Versaille community session. Today we're talking about what is a forward deployed engineer. Before we get started, I just want to say uh remember to follow our community code of conduct. Just generally be nice to each other in the chat so we can keep doing these. Um, and if you have any questions, feel free to ask those along the way. We're not doing any demos today. This is all questions. So, feel free to ask them and I'll ask uh out loud as they come up. And with that out of the way, I would like to welcome our guest here. We have Chris. Bring him on stage. Hello everyone. I'm so happy to have you here. Um, we're talking about forward deployed engineering and I know this role is uh not well known, kind of misunderstood. So I want to clear some of that up. Um, I know the title kind of almost sounds like it's a military role or something. So at a high level, what actually is a forward deployed engineer and how is it different from a solutions engineer or customer support or product engineer? Happy to Amy. Uh, and first by way of general introduction everyone, Chris Williams, better known on the internet as Voodoo Tiki God. Uh, things that I've done that you might know of, Node Serial Port, uh, the yellow JavaScript logo, JS Comp way back in the day. Um, so been around the JavaScript community and, uh, throughout all of its iterations and done great things and, um, it's a great question. A lot of people ask me specifically as the head of the team, the head of the forward deployed engineering team, what that means. And your your comments about it sounding very military actually if you uh want to trace the the ontology back the where the words came from it actually does have its roots in sort of military elements with uh Palunteer I believe being the first one to coin the term. Um there are many different implementations of it uh for a variety of different reasons. Some will take uh some organizations will take their uh consultancies and just rebrand them as now we're forward deployed engineers, same person, same badge, but hey, looks different. Uh at Verscell, we adopt a different approach that isn't exactly like the Palunteer model is a little bit morphed into a newer way that we believe uh is more effective for our customers and for um improving our products including Nex.js JS and the versel platform and all the work we do with the AI SDK and uh the various different frameworks that we're building out. What we view it as is the lynch pin uh or immediate feedback cycle between customers and the way that they are using our actual products. And what I'll say is the theoretical thoughts of how we thought they were going to use it. And sometimes those are perfectly in alignment and customers are able to immediately use the products immediately take advantage of them and then other times it's a little bit orthogonal and what myself and my team do is we will embed directly in that's the forward deployed side uh go hands on keyboard roll up uh sleeves go shoulder-to-shoulder inside our customer environments and develop with them uh develop new things refactor sort of brownfield or existing code bases into a more modern way and in doing so we're teaching them the customers how to operate at the speed of versel how we leverage these new technologies when's the right tool for the various task and when to avoid that other tool because it may send you down the wrong path basically giving our battle scars back into the customer so they can move faster and gain iteration velocity a thing we're sort of fanatical here at Verscell about through experimentation and and rapid development. In exchange, we are gathering feedback of in the trenches how things are actually used. How are cache components in NEX16 actually being used? um where are spaces that uh maybe we have a gap in how um we expected people to use the AIS SDK and we give those real world uh implementations and concepts back to our engineering product and design or EPD teams and team members and we give them real world examples. here is this customer at this scale using and seeing this because we were there shoulder-to-shoulder building it with the customers and we're able to then say see I know we thought we were going this way but we ended up seeing it this way and working with the EPD team to get that alignment more onetoone as best we can in some cases we can't and that's okay uh but more that way so that way other customers we may not be engaged with are I'll say having a better experience as they go through the engagement model. So, a lot of our work is generally diving deep into a customer's code base um challenging their preconceived norms, looking at their observability and instrumentation and making sure they're actually watching what they think they're watching and aligning to the rightmost things and then also feeding that back as the overall cycle. I think there was another part to your question, Amy, but I've forgotten it completely, so throw it at me. Oh, no. I think I think you've covered it. Um success The other thing I want to know because you kind of touched on this a little bit, um, deployed, what does that actually look like in practice? Um, whether it's Epcell or other, um, similar roles at other companies because everyone does things a little differently. Is it a lot of on-site travel? Are you embedded in Slack and Zoom with customers? Um, are you worried about time zones or like what just generally what does an average day or week look like? Uh I wish I wish there was an average day or week but but with respect to your question um when uh the initial implementation and for some places the embedded or deployed means physically on site with the customer to see exactly how they're using it. We at Verscell are very much a remote first and and driving remote implementations for our customers all the time. So for us the deployed or embedded is more as you mentioned in that Slack and uh various ceremonies where we're engaging and working with them through uh asynchronous or synchronous where needed through video conferencing and stuff of that nature models. It does mean and can mean a little bit of travel. uh I'd say in the 25 to 30% demographic where some things are just better to get around a whiteboard and talk through and diagram and let's go through this and the digital whiteboards just they they they lose something they if just the the like residual marker on your fingers when you're trying to write on the whiteboard but there is something worthwhile in doing in person. So we do have a little bit of travel that's involved because of that. We generally try to keep our team members I specifically am like dead set on this keep team members plus or minus one time zone away from the customer base. So that way if you are traveling it isn't a um painful experience. It is something that is you know not you have to go to like uh do some sort of regimen to get back on time zone or anything of that nature. No, we make sure that we are able to get there quickly and return back without any sort of jitter. So there is a little bit um of travel but for the most part we try to prioritize and drive as much as possible through Slack engagements um co-developing through remote and pair programming via a variety of different mechanisms and then also working through uh video conferences where we may need something a little bit more face toface before going into on-site. Yeah. And and being in a similar time zone helps with that as well. Even when you're remote, you you have a lot more overlap in your working hours. It absolutely does. Um and and I mean people want we're all humans still. I think I don't think any of us have crossed the chasm to become agents yet. Uh but soon. Um no, I hope not. I really do. Uh we're all humans. So one of the nice things is is especially with the customers that we have the privilege and benefit of working with they are also all humans and we my my team members end up building great relationships with them. Um largely because we get to come in and sort of like show them the not just art of the possible which everyone loves to talk about or proof of concepts but real like here's how we get this done. Here's how we do this together. And it brings an almost Prometheian fire to the way that they continue to operate there thereafter like um day 2 to day 200. It they have changed and become more like how we operate and that brings them excitement, experimentation, curiosity has rekindled. So we generally end up having great friends who were former FDE deployment targets uh like not targets that's former forward deployments uh in in engagements that we worked with and it is an amazing thing to come back to some of them you know quarters to a year later and find out all the great things they've done without us. I mean, it's kind of sad we weren't there, but uh it's a change and a pivot for them as a business, as a generally happiness model because at least from what I've seen, adding that experimentation in iteration velocity and showing them that things don't have to be so hard and that you could just move quickly ends up making them happier in their day-to-day, in their work, in the output and product that they do, and the experimentation space. So it ends up becoming quite honestly a very virtuous and positive cycle all the way around. Yeah, it is a really good way of working when you move quickly and you can do that experimentation because I've been in roles before where it's everything has to be shipped completely perfect and you've invested all of this time in some big feature and then you launch it and oh no, I mean quite honestly I mean even uh even the start of this and like one of us had a technical problem and couldn't get the audio working. Uh, but that's what makes life fun and exciting. Like th those sorts of like moments or maybe not just audio breaking, but it was a couple minutes right before. But like that is what makes us human is not that it breaks, but how we respond to that breakage, how we respond to that incident. And you know, going through it and persevering it together, which is part of the piece of the FDE side is you're shouldertoshoulder. When things go south, you're going uh south with it and you're helping the team out of that situation. Those are those are galvanizing moments. They they separate like those who are ready to dive in and explore and experiment and figure out better ways and those who you know sort of just fold. And so one of the things as part of being with the team is having a little bit of that empathy to understand that in certain situations you might have to be uh strong in terms of w and opinion, but then there's others where hey look, we're all in this together. um and not necessarily like check the opinion at the door because something happened uh some state change happened in the industry or something and you need to have a little bit of the empathy to and and um what is it uh EQ emotional kosha to be able to assess that situation and find the right move with it and I think on that topic this kind of role it's it's very technical but it also involves a lot of that EQ the understanding people the the soft skills or or whatever uh you might want to call that. So what what's the balance there for people like who excels in this kind of role and um what kind of skills uh would be the best for that you know to fit? That is a great question. I um I have been told that uh I'll give my personal opinion and then I'll say what I've been told. How about that? Um my personal opinion is there are a lot there are fair number of individuals out there who are multidisciplinary or have different parts of their brain that activate uh generalists is the other term that I've heard used for this. So people who have a a breadth and depth uh of broadstretch knowledge not just I am the greatest next.js JS developer in the world but I I I can absolutely write next but I also know how to write AI maybe I know how to write Rust and I also uh maybe tried to run a company once might have failed but that's okay uh we all it's the attempt more than the execution per se the generalist mentality of I'm good at technical I can speak human as well have some of the empathy elements maybe I have some business uh acumen maybe I have a little bit of sales prowess um maybe I have leadership qualities. It what I've found is individuals for the FTE role have pick three or more of those rather than having just one of them. That's not to say that an individual who may join our team and is deep in one, we can't help grow the other, but generally we will start helping to grow that uh those other muscle memory pieces of how to handle uh a stakeholder a seuite stakeholder dinner. um how to navigate a very problematic misaligned expectation and do it with a bit of uh grace and elegance and you know those sorts of things or how to honestly how to how to tell somebody that maybe the project that they're working on isn't a good idea but do it in a way that doesn't seem condescending and negative. Um those are the pieces that we look for in in when we're hiring for the role. So this is very different and I do want to indicate like very different from most other roles and it's actually a thing that historically I've always suffered personally from because I have a very varied background. Um I've run large technical conferences and written code all over the place. Uh only like two of it good two lines of it good. Um and then uh I've run several different businesses. I've been the head of sales at some organizations. So that doesn't make sense. When I go look for job descriptions, it's like you'll do this one thing and you'll do it the best of the ability. I'm like, okay, I could do the one thing, but then I'm bored. Like the rest of me needs activation. I need all all cylinders firing for me to feel happy uh at work. And I found that the team members that I have and the team members that we bring on share that sort of a broadreaching passion or curiosity to dive into different areas and explore it. And you might fail. And that's okay. Um, going back to what I said before, a lot of people will say, "Oh, you have the most experienced team in the company or uh you're bringing in the experienced people." A little little side note here, the word experience just means you've messed up more times than other people have. And you mostly figured out how to do them correctly. And that is when somebody's bringing experience, that's all they're bringing. Wisdom is just you've messed up. You figured out a path through it, and you are gonna avoid messing up because you now know the path. And ideally, you're sharing that, that's the wisdom part, to others so they don't repeat the same mistakes. And um so that said, I guess I'm very I'm very experienced and that I've messed up an awful lot of times and uh have figured out ways to help others not in incur the same mistakes. We have uh someone commented um they said, "This is interesting. I've always assumed you need a lot of depth in one solution to be a forward deployed engineer. So, a little different from what people expected. Uh, so if I could, you should have some depth. It doesn't have to be the best. And a great example, uh, Luis Alvarez is on my team. He is a former core contributor to Nex.js. Um, and I'm trying to get Sam Celikov to come over, but he keeps refusing my invitations. But, uh, but maybe this will turn him. So anyways, Luis has tremendous depth. Uh Gansy Poso, he Poso, he is also uh tremendous depth. Dom in the uh agent commerce space. They all have depth, but they also have that breadth in a variety of other spaces. Um Gansy in the enablement demographic and able to pretty much teach anyone almost anything at this point. I have a firm belief that he could teach anything. Um and it is so it's it isn't to say negating having some level of depth. Uh it is you should have some depth to have like a core area but then also the ability to add in those not near neighbor but other orthogonal pieces that pull together into the FDE. Um and because of that it it kind of balances out. So, the more for lack of a better term, uh, like an infinity gauntlet, like the more gemstones you have, I guess the less depth you have to have, per se, in each one of them, but you should have an overall strength if you're building like a D&D type thing, like your your your character has to have the variety of different levels that balance out to make that robust element. Um, and it could be that you have depth in one and lower depth in the other, but that's still okay. I guess the word is robust. uh robustness in in like how you engage life is the way I'll frame it. Yeah, it sounds to me like uh someone who's willing to try a lot of things, willing to potentially fail at those things, but also as long as they're legal, stay within stay within the legal boundaries. Uh yes, able to learn from it too is I think an important element there, right? and um have the humility to be willing to say, you know, I I suggest you don't go down this path. How do I know? Because I went down that path and you shouldn't. Um and it does it. Look, I I uh have a bit of imposttor syndrome and I've worked many many years to decades on overcoming it and pushing it down and all sorts of stuff. That's okay to be afraid of it. But the key is is by you opening up and sharing the experience the I messed up. I know exactly why this is going to mess up because I did it once. Um being willing to share that most I'll say 99.999% of the time uh more uptime than a cloud service provider. Uh that other person is going to receive that as oh okay thank you for sharing let's not do that or let's do that depending upon which direction you're going and they'll move forward with it. But it does take a lot to be willing to open that up and be a little bit um unguarded uh a little bit uh vulnerable and and that is another piece of of the overall puzzle there. Yeah, I'm willing to try a lot of things. I'm willing to share what you learned from those. Sometimes we learn the better way by trying bad ways first and realizing those were not the best solution. Again, don't don't do drugs. Stay in the legal limits of everything. I got to we got to we got to put that legals on the call. They No, they're not on the call. Um but yes, uh staying trying some things and uh sometimes they work, sometimes they don't. You learn something either way. Absolutely. As far as getting a job as a forward deployed engineer, if someone wanted to do this, what would you suggest that they start learning today? I think that's kind of in line with what we were talking about. Um, but what what like specific things might somebody who, let's say, coming from a strong engineering background might want to work on to to help with all the other skills that would benefit them? This is a very fun question that I Okay, I wish I'd had some prep work on this one. Um so I've done a lot of studying on this because one of my goals has always been since uh well about 2012 just to give a back context of timing um has always been the belief that deeply technical people often fixate or focus on the technical aspects and uh are often pigeonholed or uh square peg round hole type thing forced into only putting blinders up and staying there. And there's a realistically and as we've seen through the variety of different revolutions and evolutions of technology technical people can and should be doing more and more and more different things not necessarily just technical. So, one of the uh right around the 2016 time frame, I 20 2015 2016 time frame, um I came up with a concept that you could through experience-based learning, uh which I'll explain what that is here in a second. you can actually go through and develop the muscle memory that combats whether it's the imposttor syndrome that prevents you from doing things or just gets you comfortable in those uncomfortable situations. Uh and and really what you're doing is you're burning into your psyche and into your your muscle memory that thing we talked about before experience. So, the easiest thing as a piece of this is see a random person and go talk to them. Um, if you're at an airport and there's a person across the way, go talk to them. Uh, simple, hello, what do you do? And it it may sound to somebody who is uh a social butterfly or an extrovert, they're probably like, well, that's easy, but to an introvert, that is very hard. And I the not all engineers are introverts. Uh I myself I phrase myself as an extroverted introvert. I force myself to uh go out. We have some on our team that are introvert introverts, some that are extroverted introvert. We've got one who is an extroverted extrovert and he knows who he is. Um they the team congeals through it and all because of the working model that we operate in we all have to force ourselves to be a little bit more towards the extroverted side than the introverted. So what I would say and suggest if you want to dive into this it honestly at Verscell and we're hiring and would love everyone to to sign up and would love to bring you part of the team but even if you see the forward deployed elsewhere pushing yourself to be able to be comfortable to talk in conversations to meet new people to you know go through things that may initially have like the stomach butterflies um the jittery jittery sense. Um, getting comfortable with that is actually one of the hardest, but also the easiest things to start doing. It's the hardest thing to do, but it's the easiest thing to start doing because you can go out and next time you order fast food somewhere or if you're ordering a full proper meal, hey, uh, how's your day going? And actually genuinely mean it and try to have a conversation. And even if it lasts one sentence like my day is horrible, leave me alone. That's okay. Hey, it's a small step forward able to talk. So I I have found that to be both the the highest hill to get over but also the easiest one to take the first steps in towards. Um beyond that it would be um reading some books about uh how businesses operate truly how they operate not how they say they operate which is very different. Um or experiencing in your own business and and if you're in a company right now questioning what why are we doing this? what this is this is crazy to me. Why are we doing this? And see if you can pick apart why they're doing it. And that gives you some of that business acumen to explore. So said differently, it's going to be going down those orthogonal paths, whether business acumen, sales acumen, uh extrovertedness. Those pieces are the right spaces to extend into. And and it really t it does take time unfortunately, but it's also for the most part something that you can start doing today. And if not, if you don't can't think of ways, happy to help. Uh I, as mentioned, voodoo tiki got everywhere. So, um if you have questions, I I'm just a whatever we call it these days, an ex away. No, that that sounds like I'm at a rave. Anyways, you'll find a way to get in touch with me. You are very easy to find. Like you said, same username everywhere. Um I'm gonna let you go. I appreciate you taking the time, but I know you are very busy and have things to get back to. So, thank you so much for joining us today. Thank you Amy and thank you very much for listening. Uh been a pleasure and looking forward to hopefully uh welcoming you on as part of the team. We are hiring in the uh Americas in AMIA in the UK. Uh I don't know if that's separate or together with anyways uh we're also hiring in Australia and Japan area. So um if you are listening from any of those, please don't hesitate to sign up. Awesome. I just shared the link in the chat for everyone as well. So thank you so much. Thanks Amy. All right, and thank you all for being here. I really appreciate you joining um making some great comments. Uh we do have more online events happening this week and you can find those at community.cell.com/events. And if you registered for ship, we will see you in London, Berlin, and New York next month. If you haven't gotten a ticket yet, but you want to, you can do that at verscell.com/shipip. And I recommend acting quickly because some locations are already sold out and others will be very soon. So, thanks again.