What does a Forward Deployed Engineer do?

If you work in tech, you know the struggle of trying to explain your job title to people outside the industry. It turns out that even comedians are starting to notice.

Quite recently, I saw a video from Austin Nasso titled “Engineer does not have a real job”. Austin is a Microsoft software engineer turned standup comedian. In the clip, he’s doing crowd work and asks a member of the audience “What do you work with?” to which the poor targeted fellow in the audience replies “Forward Deployed Engineer”. “What is that?” Austin replies, and this person then becomes the punch bag the next few minutes.

That video resonated with me, since not only do I work as a Forward Deployed Engineer, or FDE as we say in the biz, but I also have similar struggles explaining to people what I actually do. To most people, like my neighbors, I just say “computer”. To my friends and family, I usually just say that I’m a software engineer who also talks to customers.  But to you, who’s (hopefully) reading this blog post, I will explain what I actually do. 

Bottom line. 100% truth. No fluff.

A day in the life of the FDE

The first thing I do when waking up in the morning is check the progress of my 100 subagents that have been burning away all night… no, not really. But in my defense, I do check the logs for 100 other things that are far less glamorous, so let's stick with the agent story for the blog.

My background is within cybersecurity and computer science, specifically within product and application security. Prior to that, I did a stint within sales and finance. So being an FDE suits me well.

My work is split between product engineering, software development and last but not least field work. 

Product engineering usually involves roadmap related items, making sure that these are aligned with our customers' wants and needs.

That way I serve as a “voice of the customer” to our engineering team or, as they call me, “the bearer of bad news”.  I believe this is valuable in a startup environment where things move fast and where it’s difficult to know what to prioritize and when.

Software development is quite self explanatory. Together with the rest of the engineering team, I work on the issues I previously created. In my case, I especially focus on UX, since I experience what the customer experiences almost every day. Moving fast and working with different verticals of the product often creates a rift between them, thus focusing on tying them together to make sure that the UX makes sense is important.

Field work however, may need a bit of explaining. This involves working directly with potential and existing customers, showcasing our product, helping them get onboarded or getting customers unstuck when such needs arise. 

Instead of having to go through traditional channels where an account manager would have to talk to a product manager, and a product manager have to talk to an engineering team, we close that loop early. That way, we do not have to play telephone and risk that information gets lost along the way.

The three perks of FDEs

This changes the development process a lot and drastically improves three crucial parts where traditional methods may fail. 

• Firstly, we may implement and ship fixes or features the same day, before we even leave the call or the customers office. 

• Secondly, we avoid promising too much too soon. Thanks to having one foot in software development, I’m deeply familiar with the true horror of technical debt, which means my time estimations are usually closer to 'realistic' than 'wildly optimistic.'

• Thirdly, being able to translate the customers needs directly into code, prevents scope creep and more often leads to higher customer satisfaction. Again, less information gets lost along the way, and actually having hands-on technical knowledge allows me or my colleagues to pinpoint the problem quicker.

So, all in all, having FDEs certainly brings value to both customers and companies. When we sell our product, Hedgehog, to customers we always include dedicated FDE time in those deals.

From experience, this has helped tailor the onboarding experience, bridge any gaps between expectation and reality, and overall increase the value for money for customers. 

I know, from experience, just how tedious and frustrating it can be to get started on a new platform or toolset. As a user, I may like it overall, but some of the finishing touches are missing. It lacks support for our ticketing system, or misses a specific SIEM parser. “I’ll talk to the engineering team and get back to you” is the reply you generally get, and your ticket then gets lost in the ether together with heaps of other stuff. 

Not to toot my own horn, but having a dedicated FDE in your case, (okay, I’m tooting my horn) would not only get these last important pieces of the puzzle with the skill set I described above, but also be able to demonstrate them to make sure they live up to expectations.

At NRDSNIPE, we don’t do “all bark, no bite”. We encourage customers to try first, and decide then. We love good competition. In our customer pilots, where we typically do scoped two week engagements, we always include dedicated FDE time. So if you’re interested in leveling up your security work with Hedgehog, don’t hesitate to give us a call.