Forward Deployed

Sign in<br>Subscribe

As a forward-deployed engineer (FDE) my job is to manufacture customer-product alignment.<br>As Nina has pointed out, I love documentation, guides, thinking in procedures, and systematizing relationships such that they are maximally useful and well-lubricated. The best calls are no calls, meaning you don't have to waste time talking to me and I have already pre-helped you to answer your questions on your own, while feeling good about it the entire time.<br>In order to turn myself into a product or service or API layer on top of an application which is complicated enough in itself, you have to feel deeply understood by me. This entails both:<br>actually being understood, such that I can employ my understanding effectively, and<br>over-engineering my understanding such that it is not only legible to me or my internal team, but also to you as the customer. It doesn't matter how much I think I understand you, or even how much I actually do understand you, if you do not yet feel understood.<br>The best way to validate the above 2nd step—which is missing from so many customer service calls in our daily lives, sadly—is literally to say so out loud. If you are VERBALLY TELLING yourself, me, your boss, my boss, other colleagues on slack and zoom, the world, etc... then we will all know that 1 + 2 above were ACTUALLY ACHIEVED.<br>This is in part why I enjoy giving my google maps reviews to restaurants who deserve it (good or bad). And it brings us to another aspect of the forward-deployed role: results have to land. Sometimes my foodie lingo is directed at meme-ing, sometimes it's genuinely praising a waitress, sometimes it's for the owner to fix a problem in their kitchen...<br>Determining where results land is a highly contextual judgment call and cannot be automated nor easily passed onto someone else.<br>By "land" I mean things are never only internal to certain humans, customers, sales people, teammates, or in a database somewhere. The work is literally to propagate behavior change via relationships and conversations that catalyze not only your company to do things differently, but my company too, on the other end!<br>Bridging customers and product is nontrivial because enterprise product feedback is never driven home in a silo or a ticket alone. It usually involves:<br>the customer interacting with the product or application / company as a whole system / solution,<br>their boss. never forget the customer is a human with a boss / board / shareholder to please on their side, in addition to their own customers, users, and other targets,<br>the person receiving feedback on our end, whether they are sales or support or success or field eng, or even a recruiter, or something else – e.g. random heckler at an Apple keynote bothering the CEO during her speech,<br>the person who received the feedback turning around and deciding to act on it, which usually happens later in some other moment or context, so it's worth separating this out from that person in "listening mode" above, then<br>the engineer debugging code, or implementing a fix, tightening a screw,<br>the (perhaps other) eng approving the merge, change, fix, supervising the first one, and finally<br>the person carrying this announcement to the rest of the company or back to the customer: "hey last week the eng team fixed X, you should have heard about it by now, it impacts Y. This matters because Z."<br>etc etc etc... ripples continue into the future forever, butterfly effects. The next day, neither company is the same. The product works better, and the customer moves toward their desired result.<br>So, given the above complexity, it's useful on an individual level to really be careful and thoughtful when reducing the distance between my mind and yours. Even if it doesn't appear so, I'm constantly working to minimize friction between you and your goals, from my end, through the above complexity. And myself as a potentially faulty cog in the system too.<br>The above probably includes building leverage in myriad little invisible ways that I can see but you cannot, like when I drafted this blog post at 4am so I fall asleep as i could not stop thinking about these ideas... and also so I could publish then point at it later this week and share clear thoughts with someone else instead of hurriedly chatting and perhaps we miss the important contextual points...<br>This may or may not include long emails, slack messages, time chatting on Zooms or in-person. Often, middle managers will force you to walk through things that make you want to shoot yourself in the forehead. If a login is broken, share your screen and show us all, so we can all sit here and waste time while we learn how to google "i forgot my password".<br>Still, I find it best to force alignment proactively. This includes providing various overdetermined artifacts and links that we can later point to and agree on "this makes a lot of sense" and "oh yeah, we said that here in the doc there, i forgot". We might have to go step by...