Lesson 1.2: FDE, solutions engineer, consultant and software engineer

Four jobs sit close together and share job titles. Learn four questions that sort any role, and how a forward deployed engineer differs from the rest.

By the end of this lesson you will be able to tell four neighbouring jobs apart: the software engineer, the solutions engineer, the consultant and the forward deployed engineer. You will learn four questions that sort almost any job description into the right group, even when the title is misleading, and you will use a simulator to score a real posting. You will also walk through a project in which all four roles work on the same customer, so you can see who does what and where the handoffs happen. You should have read Lesson 1.1, which describes the forward deployed engineer's five-step loop, but no coding experience is needed to follow this one.

Why spend a whole lesson on definitions? Because this is the first practical problem anyone faces when they become interested in the role. Job boards mix titles. A "solutions engineer" posting may describe three days a week of writing production code inside a customer's cloud account. A "forward deployed engineer" posting may describe a pre-sales demo job with a new name. If you cannot read past the title, you may apply for the wrong job, accept the wrong job, or, if you are hiring, write a description that attracts the wrong people. The goal here is a reliable way of reading what a job actually is.

Why the borders are blurry

Companies invent titles for reasons that have little to do with precision. A title can signal seniority, attract applicants, match a competitor's wording or reflect the history of one team. The same work may be called an implementation engineer, a customer engineer, an applied engineer, a deployment strategist or a solutions architect in different places. The reverse also happens: two jobs with an identical title may have almost nothing in common.

So we will not memorise titles. Instead we will look at four things that stay stable when the name changes: who the work is for, where the work runs, when the work ends and how success is measured. Each of the four jobs gives a different answer to each question, and the pattern of answers is what makes a job what it is.

Four questions that sort any role

Take any job description, or any person you work with, and ask these four questions.

1. Who is the customer of the work? Is it every user of the product, one prospective buyer, one client who has hired the person for advice, or one customer who already uses the product and depends on it? 2. Where does the work run? In the company's own product and servers, in a demo environment, in a document, or inside the customer's own systems and data? 3. When does the work end? When the code is merged, when the deal is signed, when the report is delivered, or when the customer is getting value from something running in production? 4. How is success measured? By the quality and reliability of the product, by deals won, by the client's satisfaction with the advice, or by the change in the customer's own results?

Here is how the four jobs answer. The descriptions are the typical case. Real jobs blend, which is the point of the simulator later in the lesson. Question · Software engineer · Solutions engineer · Consultant · Forward deployed engineerWho is the work for? · All users of the product · One prospective or new customer · One client · One existing customer Where does it run? · The company's product and servers · Demo or trial environments · Documents, models and plans · The customer's own systems and data When does it end? · When the change ships and works · When the customer decides to buy or goes live · When the recommendation is accepted · When the customer is getting value in production How is success measured? · Product quality, reliability, adoption · Deals won, successful trials · Client satisfaction, quality of advice · Change in the customer's own results Main product of the work · Features and services · Demos, proofs of concept, answers · Analysis and recommendations · Working software in production Read the table by columns first. The software engineer's work is for everyone, so it has to be general. The forward deployed engineer's work is for one customer, so it can be specific, and a lot of it is. Now read it by rows. The row that separates the forward deployed engineer from the others most clearly is "when does it end?" The solutions engineer is usually finished when the customer says yes. The consultant is finished when the advice has been delivered. The software engineer is finished when the change is released. The forward deployed engineer is finished when the customer's results change, and that is a much later and harder finish line.

Predict first: a company has sold a large pilot to a customer. The pilot works in a demo, but the customer's data is in three old systems and nobody there knows how to connect them. Which of the four jobs would you send to the customer to make it work, and which one would you not send? Decide before you read on.

The best answer is the forward deployed engineer, because the missing piece is neither a general feature (software engineer), nor persuasion (solutions engineer), nor advice (consultant). It is working software inside the customer's real systems. The job you would least want to send is the consultant, because a report on how to connect the systems does not connect them. The software engineer is a useful second choice if the connection turns out to need a new product feature, which is why the forward deployed engineer and the software engineers talk to each other often.

The software engineer: one capability, many customers

A software engineer builds and maintains the product. Their work is judged across all customers at once, so they think in terms of general solutions: a feature that serves a thousand customers is better than a feature that serves one, even if the one customer is large.

The company that popularised the forward deployed model, Palantir, described this split clearly in a 2019 post on its engineering blog. It calls its software engineers "Devs" and its forward deployed engineers "Deltas", and sums up the difference as a Dev's focus being "one capability, many customers" and a Delta's being "one customer, many capabilities". A Dev owns a part of the platform from start to finish and writes code that will run for many customers. A Delta works as part of a team that supports one customer, and measures success by the customer's goal. The post also says "Delta" is a leftover from the company's early days, when each team in its business development division was named after a letter of the NATO alphabet. The name carries no deeper meaning.

A few habits mark a software engineer's work. They design for reuse, write tests, think about performance and maintenance five years out, and say no to requests that would complicate the product for everyone. They rarely meet the customer. When they do, it is usually through a product manager or a support team.

That distance is a strength and a limit. The strength is depth: a software engineer can spend months on one hard part of the system. The limit is that the customer's real environment may stay unfamiliar. A software engineer who has never seen how a customer's data really looks may build a feature that fails on contact with real records. This is one reason companies add forward deployed engineers: they bring the reality of the customer's environment back to the people who build the product.

The solutions engineer: showing that it can work

A solutions engineer, sometimes called a sales engineer, sits next to the sales team. Their job is to answer the technical questions a buyer has and to show that the product can solve the buyer's problem. They give demos, run trials called proofs of concept, fill in security questionnaires, explain how the product connects to the buyer's systems and answer the sceptical engineer in the room.

The defining feature is timing and incentive. A solutions engineer works mostly before and around the sale, often on several prospects at once, and their results are usually tied to deals won. That is not a criticism. It is a real skill: they must understand the product deeply, translate it for different audiences, and spot quickly whether a prospect's problem is a good fit or a bad one. A good solutions engineer saves everyone's time by saying, early, "this product will not solve that."

Two things separate the job from the forward deployed engineer.

The environment. Proofs of concept usually run in a demo or trial setup, with clean sample data and no real security reviews. The forward deployed engineer works with the customer's real data, real approvals and real users. The finish line. A successful proof of concept ends in a signature. A successful forward deployed project ends in a result that the customer can measure. The first can happen without the second.

The gap between the two is where many projects fail. A demo looks wonderful, the contract is signed and then the customer discovers that making the demo work on their real data takes four months. Companies that notice this pattern create forward deployed roles to own that stretch. When the same person owns the demo and the deployment, there is also a pleasant side effect: they are less tempted to promise things the product cannot do.

The consultant: deciding what to do

A consultant is paid for judgement. A client has a business question, such as whether to enter a new market, how to reduce costs or how to organise a team, and the consultant analyses the situation and recommends what to do. Their main product is analysis: interviews, models, benchmarks, reports and plans. Some consultants also help carry out the plan, and technology consultants may build systems, so the border is not sharp.

The Palantir post addresses this comparison directly. Deltas it quotes say that consultants generally produce a one-time analysis, recommendation or solution, while a forward deployed engineer works with the customer to build a long-term solution that keeps improving, and that the critical difference is that a Delta deploys existing software products to reach the customer's outcome and does significantly more engineering than a consultant. Those are the views of people who hold the job, so treat them as a description of how the role sees itself, not a neutral verdict. The practical point is still useful. When the work is mostly about deciding, you are closer to consulting. When it is mostly about making something run, you are closer to forward deployed engineering.

Consultants bring skills that forward deployed engineers should borrow: structured problem-solving, interviewing stakeholders, building a case with numbers and presenting a clear recommendation. A forward deployed engineer who can also frame a problem like a consultant is more valuable, because they avoid building the wrong thing quickly.

The forward deployed engineer: making it work there

Lesson 1.1 described the forward deployed engineer's loop of understand, build, deploy, communicate and feed back. Seen against the other three, three features stand out.

Ownership of the outcome. The job is not finished when the code is written or the demo succeeds. It is finished when the customer's people are using it and their numbers move. This ownership is what makes the work stressful and what makes it rewarding. Real code in real environments. Unlike the consultant, the forward deployed engineer builds the thing. Unlike the solutions engineer, it runs on the customer's real data and under the customer's real rules. A two-way bridge. The forward deployed engineer carries the customer's needs back to the product team and carries product changes forward to the customer. Some of the code they write may flow back into the core product, with the product team's review, because a missing feature is sometimes what stands between a project and its result.

It is also the job with the least tidy boundary. A forward deployed engineer borrows from all three neighbours: they write code like a software engineer, they demonstrate and explain like a solutions engineer, and they diagnose a business problem like a consultant. That breadth is the reason the role is hard to hire for and hard to describe, and it explains why the titles are confusing.

Here is one rough picture of how the four jobs might spend their time on writing production code. The figures are illustrative, chosen to show the shape. Real jobs vary widely.

Notice that the forward deployed engineer sits between the software engineer and the solutions engineer. They write a lot of code, but a large share of the week goes to understanding the customer, deploying and communicating, which is also why they do not write as much code as a core software engineer.

Worked example 1: one project, four roles

The best way to see the differences is to watch the four roles on one project. This is an illustrative story, not an account of a real company. A mid-sized lender, which we will call Vikas Finance, wants an AI assistant that helps its collections team decide which borrowers to contact and what to say. It is evaluating a product from a software company.

Weeks 1 to 3: the sale. A solutions engineer meets the lender's head of collections and the head of technology. They run a demo with sample data, answer a security questionnaire and agree on a two-week trial on a small slice of real records. They are good at this: the lender sees what the product could do and signs a pilot contract. The solutions engineer's work is mostly done.

Week 3: the advice. The lender, unsure how to measure success, has hired a consultant to define the target. The consultant interviews the collections team, studies the lender's recovery numbers and recommends a goal: raise the share of overdue accounts that pay within thirty days, starting with the smallest overdue band. This is a useful document. It is also a document. Nothing runs yet.

Weeks 4 to 12: the deployment. The forward deployed engineer joins. They spend the first week in the collections room, watching callers, reading the data and finding that due dates sit in two formats and a third of the records lack a language preference. They build a rough pipeline in the first two weeks, show it to the team, and rework the account groups after the head of collections reacts. They set it up inside the lender's own cloud account because the security team requires it. They train the callers, write the runbook and report weekly progress against the consultant's target.

Weeks 8 to 12: the product change. In week eight the forward deployed engineer finds that the product cannot send reminders in the lender's regional language. They write a small version of the feature, send it to the software engineers who own the messaging component, and discuss how it should work for everyone. The software engineers redesign it, add tests and release it a month later as a standard feature. The forward deployed engineer then drops the custom version.

Across twelve weeks, every role did something the others could not do well, and every handoff was a place where information could be lost: the solutions engineer's promises to the forward deployed engineer, the consultant's target to the data, and the field's lessons to the product. Much of the discipline of the role is about these handoffs.

The chart below shows how long each role was involved in the twelve weeks of the Vikas Finance story. The forward deployed engineer is present for most of the project, and the others for the stretch where their kind of work is needed.

Worked example 2: reading three job postings

Now apply the four questions to something you can do today. Here are three short, invented postings. Read each and decide which job it describes before reading the answer.

Posting A. "Customer Engineer. Join our pre-sales team. Run demos for prospective customers, build proofs of concept in a sandbox environment, respond to technical questions in sales calls, support requests for proposals. Quota-carrying role with bonus tied to closed deals."

The work is for prospects, runs in sandboxes, ends at the sale and is measured in deals. That is a solutions engineer in everything but name.

Posting B. "Solutions Engineer. Work with our largest customers for three to six months after they sign. Write Python and SQL that connects our product to their data warehouses and internal systems, ship it into their cloud account, own the pilot's success metric and present results weekly to their executives. Contribute fixes back to the product team."

The work is for one existing customer, runs in the customer's systems, ends when results appear and is measured by the customer's metric. Despite the title, this is a forward deployed engineer.

Posting C. "Technology Consultant. Assess our clients' data strategies, interview business leaders, build a roadmap for their analytics investments and present recommendations to the board. Some prototype development in a sandbox."

The work is for a client, lives mostly in documents and ends at the recommendation. It is a consultant, with a small coding component.

In two of the three postings the title points the wrong way, or at least the way that a quick reader would not expect. That is common enough that checking the four questions should be a habit before you apply for, accept or write any role.

Score a posting yourself

The simulator below turns the same idea into numbers. Describe a posting by moving five sliders: how much of the job is writing production code, how much happens inside the customer's own systems, how much of it happens after go-live, how much of it is tied to winning deals, and how much is analysis and advice. The tool compares your description with an illustrative profile of each of the four roles and shows how close the match is. A higher score means a closer match.

The profiles are simplified teaching aids, written for this lesson. They are not measured from real data, and your own judgement about a specific job will be better than any score. Use the tool to see which dimension separates the roles. A good experiment is to start from the forward deployed engineer defaults, then slide the deal-related share up and watch the match move toward the solutions engineer. Then slide the advice share up and the code share down, and watch the consultant take over.

Worked example 3: which one should a small company hire first?

Now suppose you run a young company with a promising product and the first three large customers just signed. You have budget for one new person. Should it be a software engineer, a solutions engineer, a consultant or a forward deployed engineer? This is an illustrative decision, with invented figures to show the reasoning.

Say each customer is worth ₹60 lakh a year, so the three together are ₹1.8 crore a year in revenue. Your problem is that all three are stuck in deployment: each customer's data is messy and none of them has used the product in production yet. Suppose a customer that is not live after six months has a one in three chance of leaving at renewal, and a live one has a one in ten chance. With three customers at ₹60 lakh, the expected loss from deployments that stay stuck is about 3 × ₹60 lakh × 1/3 = ₹60 lakh a year, against about 3 × ₹60 lakh × 1/10 = ₹18 lakh if they go live. Getting them live is worth roughly ₹42 lakh a year in kept revenue, before counting the growth that satisfied customers bring.

Now compare the candidates against that specific problem.

A software engineer improves the product for everyone, but each customer's problem is specific. They may be the right hire in six months. They are not the fastest route to unsticking three deployments. A solutions engineer helps sell more customers, which is valuable. But your bottleneck is not selling. It is making what you sold work, and adding more customers to a stuck pipeline makes the problem larger. A consultant can tell you what to do about the deployments. You probably already suspect what is wrong. What you lack is someone to do it. A forward deployed engineer goes directly at the bottleneck, and the work they do generates the information the product team needs.

For this company, at this time, the forward deployed engineer is the best first hire. That does not mean it is always the best role. If the problem were "nobody is buying", the solutions engineer would come first. If it were "the product has a design flaw affecting everyone", the software engineer would. The skill is in naming the bottleneck before choosing the role, which is another way of saying that you start with the problem, not the title.

You can test the reasoning with your own numbers. Change the number of customers, what each is worth and the chance of losing one that is stuck or live, and see what getting deployments live is worth.

At the defaults, stuck deployments put about ₹60 lakh a year at risk against about ₹18 lakh once live, a difference of about ₹42 lakh. That gap, and not the job title, is what the forward deployed engineer is hired to close.

How the four work together

A mature company often has all four roles, and the relationships between them matter more than any one of them.

The solutions engineer hands the forward deployed engineer the promises made in the sale: what the customer was shown, what they were told and what they expect. A forward deployed engineer who finds out about those promises by surprise is already behind. The forward deployed engineer hands the software engineers the patterns they have seen. If three customers need the same workaround, a good forward deployed engineer writes a short, clear description of the need with evidence, not only a list of complaints. The software engineers hand back product features that make the custom work unnecessary, and a stable platform that makes the forward deployed engineer faster. The consultant, where there is one, supplies a view of the business problem that the engineers may not have, and benefits from the engineers' view of what is technically possible.

When these handoffs work, each role gets more done than it would alone. When they fail, the usual symptoms are a customer who feels sold to by one team and abandoned by another, a product team that hears about a problem only when a customer threatens to leave, and a forward deployed engineer who is the only person who understands a customer's setup. The last one is a risk, and later lessons in this track show how to reduce it with documentation and clean handovers.

What this means for your own path

If you are thinking about which of these jobs to aim for, the four questions give you a way to test yourself.

If you most enjoy depth in one technology and building something many people will use, the software engineer path is a natural fit. If you enjoy explaining, demonstrating and being a trusted technical voice in front of customers, and you like variety and fast cycles, look at solutions engineering. If you enjoy structuring ambiguous business problems and communicating recommendations, but not building the system, look at consulting. If you like all of the above in moderate doses and especially like the satisfaction of making something work in a messy real environment, and you can live with the pressure of owning the result, look at forward deployed engineering.

You can also move between them. Software engineers who spend time with customers often become forward deployed engineers. Solutions engineers who start building real deployments move the same way. Forward deployed engineers who want deeper technical focus return to the product team, or move toward product management or start companies. No one of these choices closes the others, which is useful to remember when a title on a posting does not quite match what you want.

Common mistakes

These mistakes come up most often when people compare the roles.

Trusting the title. A title is a label, not a description. Check where the work runs, who it is for, when it ends and how it is measured. Treating the solutions engineer as a lesser forward deployed engineer. The jobs have different goals and skills. A strong solutions engineer is not a forward deployed engineer who has not been promoted. Assuming a forward deployed engineer is a consultant who codes. The consultant is judged on advice. The forward deployed engineer is judged on a running system and the customer's results. Over-promising in the sale. When the same company has both pre-sales and deployment roles, a promise made in a demo becomes a task in the field. Share what was promised, early and in writing. Hiding behind the product team. Saying "that is a product limitation" ends the conversation. A good forward deployed engineer says what the limitation is, what they will do about it for this customer now and what the product team should consider. Applying for a role without asking the four questions. Before an interview, ask where the work runs, who owns the result and how success is measured. The answers show you the real job.

Key takeaways

Job titles in this area are used loosely, so judge a role by four questions: who the work is for, where it runs, when it ends and how success is measured. A software engineer builds for all customers. A solutions engineer shows the product can work, usually around the sale. A consultant advises. A forward deployed engineer makes it work inside one customer's real systems. The finish line is the clearest difference: the forward deployed engineer is finished when the customer's own results change. The roles depend on one another through handoffs: promises from sales, patterns to product and features back to the field. The right first hire depends on the bottleneck. Name the problem before choosing the role. A posting that describes working in the customer's systems, owning a result after launch and writing production code is a forward deployed role, whatever its title says.

Check yourself

1. What are the four questions that help sort a job description into the right role? Who the work is for, where it runs, when it ends and how success is measured. 2. A posting titled "Solutions Engineer" describes writing code that connects the product to a customer's data warehouse, running for three to six months after signing, and owning the pilot's success metric. Which role is it? A forward deployed engineer: the work is for one existing customer, runs in their systems, ends with results and is measured by them. 3. What does the phrase "one capability, many customers" describe, and what is its opposite? It describes a software engineer's focus on building general capabilities for many customers. Its opposite is "one customer, many capabilities", the forward deployed engineer's focus. 4. In the Vikas Finance story, why did the forward deployed engineer send the regional-language feature to the product team instead of keeping the custom version? Because a general feature built and tested by the product team serves every customer and costs less to maintain than a one-off. The custom version was dropped once the standard one shipped. 5. A company's customers are signing but not going live. Which role should it hire first, and why? A forward deployed engineer, because the bottleneck is making what was sold work in the customers' real environments, not selling more or building general features.

Try this

This exercise takes about forty minutes and teaches you to read roles instead of titles.

1. Open a job board and find five postings with any of these titles: forward deployed engineer, solutions engineer, customer engineer, implementation engineer and technology consultant. Choose companies you can read about. 2. For each posting, answer the four questions in one line each: who is the work for, where does it run, when does it end and how is success measured. Quote the words in the posting that tell you. 3. Use the simulator above to score each posting. Estimate the five sliders from the text, and write down which role the tool picks. 4. Compare the tool's answer with the title. Mark each posting as "title matches the work" or "title does not match". 5. Choose the posting you would most like and write three questions you would ask in an interview to check that the real job matches the description, for example "who owns the result after launch?" and "how much of the week is spent inside the customer's systems?" 6. Write two sentences on what you learned about how the titles are used.

A good result is a short table of five postings with four-question answers, a score for each, and a list of three interview questions. If at least one title surprised you, you have seen the problem this lesson describes.

Sources

[Dev versus Delta: Demystifying engineering roles at Palantir](https://blog.palantir.com/dev-versus-delta-demystifying-engineering-roles-at-palantir-ad44c2a6e87), Palantir engineering blog, 8 April 2019. Used for the "Dev" and "Delta" descriptions, the NATO-alphabet origin of "Delta", the "one capability, many customers" framing and the Delta-versus-consultant comparison. These are the company's own staff describing their own roles. The worked examples, postings, profiles and all figures are the author's illustrations for teaching, not data from real companies or surveys.

Tags: Forward Deployed Engineer Solutions engineer Careers Software engineering Beginner