Lesson 8.4: Growing from FDE to lead, product or founder
The forward deployed role opens many doors. Learn the main career paths, what changes on each, how to choose and how to plan your next twelve months.
By the end of this lesson you will be able to describe the main directions a forward deployed engineer's career can take, say what changes in the work and the skills on each, judge which suits you using a simple self-assessment and write a twelve-month plan for your own growth. You will see three people at about the same point in their careers choose three different paths, with the reasons and the trade-offs, and use a simulator to compare your own preferences with illustrative profiles of five paths. This is the last lesson of the track. It looks forward from the role you have been learning, and it also closes the track, so the final section looks back at what the eight modules have covered. You do not need to have held the role yet to find it useful: many readers will use it to decide whether to aim for the role at all.
A career is not a ladder with one right rung above you. It is closer to a landscape with several routes, some of which join and some of which diverge, and the best choice depends on what you enjoy, what you are good at and what the world needs at the time. The forward deployed role is a good place to stand in that landscape, because it builds an unusual set of skills and an unusually broad view of how software meets the real world. But standing there does not tell you where to walk next. This lesson is about looking around.
What the role builds
Before choosing a direction, it helps to take stock of what you will carry with you. A few years in the role develop a set of strengths that are valuable almost anywhere.
Customer insight. You have sat with real users in real organisations, seen how work is actually done and learned to find the problem behind the request. Many people who build products have never done this.
Shipping under constraint. You have built and deployed things inside someone else's rules, with imperfect data and tight dates, and made them work. That is a different skill from building in ideal conditions.
Communication across worlds. You can talk to an executive, a nurse, a security officer and an engineer in the same day, and make each understand what matters to them.
Ownership. You are used to being responsible for an outcome, not just a task. Few engineering roles ask this so directly.
Pattern recognition. You have seen the same problem at several customers, and you can tell what is general from what is particular, as Lesson 7.1 described.
Judgement under ambiguity. You have made decisions with incomplete information and lived with the results, which is the core of senior work in almost any field.
These strengths are not tied to one employer or one product. They are what make people with this background sought after for many roles, and it is the reason the role is sometimes described as a good training ground. It is also a reason to take care in the choice, since many paths are open and each uses the strengths differently.
The main paths
The paths below are not an official list, and the borders between them are blurry. Companies name and structure roles differently, as Lesson 1.2 showed for the neighbouring jobs. Each is described by what changes in the work, what you would need to add and what to watch for.
Deeper in the role: senior and staff forward deployed engineer
You stay in the field and grow in scope. You take on the hardest customers, the largest deployments and the least defined problems. You become the person others consult when a project is in trouble. You mentor newer engineers, write the playbooks and shape how the team works, without managing people.
What changes: the problems get larger and vaguer, and your influence comes from judgement and example.
What to add: depth in a domain, such as financial services or health, and in a technical area, such as data platforms or applied machine learning; skill at framing problems for executives.
Watch for: burnout from constant customer pressure, travel and on-call, and the risk of becoming the hero who cannot be replaced, which Lesson 5.4 warned about.
Signs it suits you: you love the customer work and the building, and you do not want to manage people.
Leading others: forward deployed lead or manager
You move from doing the work to enabling a team to do it. You staff projects, coach engineers, set standards, handle escalations and manage the relationship with the largest customers. You spend less time building and more time with people.
What changes: your output becomes the team's output. Your own hours on the keyboard fall, as the chart later in this lesson shows. One engineer at a company that popularised the role, writing about moving from individual contributor to leading teams, describes enjoying the bird's-eye view: seeing many people's work come together into something valuable for a client, and helping to translate business strategy into technical execution.
What to add: coaching and giving feedback, delegating without abandoning, hiring, planning capacity and handling performance and conflict.
Watch for: continuing to do the hands-on work yourself because it is more comfortable, which starves the team of growth and you of time; and losing touch with the field.
Signs it suits you: you get more satisfaction from helping someone else succeed than from solving the problem yourself.
Into product: product manager
You use what you learned in the field to decide what the company builds. You run the roadmap, prioritise requests, work with engineers and designers and talk to many customers. The field brief of Lesson 7.2 is the document you would now be receiving.
What changes: you stop deploying and start deciding. You carry responsibility for the whole product's success, not one customer's.
What to add: prioritisation methods, market and competitor analysis, pricing, metrics and experimentation, and the skill of saying no to many good ideas.
Watch for: missing the satisfaction of building and the closeness of one customer, and the temptation to build for the loudest customer you remember.
Signs it suits you: you find yourself thinking about what the product should be more than about how to make one deployment work.
Into engineering: core product engineer
You return to building the product, with the field experience that most of the team lacks. You know what breaks in the real world, and you design for it. In some companies, as the engineering blog of one firm notes, there is a good deal of movement between the field and the core product roles, because the company values exposure to different problems.
What changes: your customer becomes everyone at once, and you spend months on one part of a system.
What to add: deeper engineering depth in a specialty, design for scale and maintenance, working in a large codebase.
Watch for: missing the variety and the direct feedback.
Signs it suits you: the part of the role you like best is building something well, and you would trade the variety for depth.
Pre-sales and architecture: solutions architect or customer engineering lead
You work with customers before and around the sale, designing how the product fits their environment and helping to win and shape deals. You are closer to the commercial side.
What changes: you work on many opportunities in parallel, and your results are linked to deals. You hand over to deployment teams instead of staying through to production.
What to add: a stronger commercial sense, presenting and negotiating and breadth across many industries.
Watch for: losing the satisfaction of seeing things run in production.
Signs it suits you: you enjoy explaining, designing and persuading more than long deployments.
Starting something: founder
You identify a problem that you have seen repeatedly, and build a company around it. Your pattern log, as in Lesson 7.1, is an unusually good starting point: a list of needs seen at several customers, with their causes and costs. Your relationships with those customers may become your first conversations.
What changes: everything. You are responsible for finding customers, raising money, hiring, building and selling, often at once, and you carry the risk personally.
What to add: selling, fundraising, hiring and managing, finance, and a high tolerance for uncertainty.
Watch for: mistaking a problem you saw at two customers for a market, and the legal and ethical limits on using what you learned: confidential information, the products and data of a former employer and customers' trust. Take advice on these before you act.
Signs it suits you: you cannot stop thinking about a particular problem, you are comfortable with risk and you like building the whole thing, not one part.
Choosing, without pretending to know
Few people choose a path once and for all. Most try something, learn from it and adjust. But a few questions can make the first choice better informed.
What energises you, and what drains you? Pay attention to which weeks in your work you finish with energy and which leave you empty. Those are data.
What do you want more of in a year? Building, customers, strategy, people, risk?
What are you good at that others notice? Strengths that people comment on are often those that make a path viable.
What does the company need, and what does it pay for? A path that the organisation values and rewards is easier than one it merely tolerates.
What is your life asking of you? Travel, hours, location and income matter, and are legitimate considerations at every stage.
What would you try if you were not afraid? Fear is information, but it is not always right.
It is also worth saying that none of the paths is better than the others. A strong senior engineer who stays in the field is as valuable as a manager, and in many organisations is paid comparably. The idea that growth means management is a habit of thought more than a fact.
Predict first: three years into the role, you love the customer work and the building, you dislike the idea of managing people, and you are being encouraged to become a lead because that is the "next step". What would you say, and what options would you raise? Decide before reading on.
The honest answer is that leading is one of several routes, and that you can say no to it without stalling. You can ask whether the company has a senior or staff track for engineers who want to deepen their work and what it requires. You can say you want to grow in scope, such as taking the hardest customers, shaping the playbooks and mentoring, while staying hands-on. You can ask about adjacent routes that use the same strengths without management, such as architecture or product. And you can agree to try a small piece of leadership, such as mentoring one new engineer, to test your reaction, which is more informative than a guess. The aim is to grow in a direction that fits you and is valued, not to follow the first step offered.
Compare yourself with the paths
A self-assessment can make the choice concrete. The simulator below compares five illustrative profiles with your own preferences. Rate how much you want each of five things in your work, from 0 to 100: hands-on building, time with customers, product and strategy thinking, leading people and tolerance for risk and uncertainty. The tool shows how closely your answers match each path.
The profiles are written for this lesson. They are simplified, they differ between companies and they describe the average emphasis, not any individual's job. A close match is a prompt to look more closely at that path, not a verdict. A distant match tells you what you would have to love to enjoy it. Use it to start conversations with people who do these jobs.
Try three experiments. First, keep the defaults and read the five scores. Second, set people leadership to 90 and building to 30 and see how the lead path rises. Third, set risk to 95 and see the founder path overtake the others.
At the defaults, a person who wants building at 60, customers at 70, strategy at 60, leading at 40 and risk at 55 scores about 89 for a senior or staff engineer, 84 for product, 83 for a founder, 81 for a lead and 69 for core engineering. The scores are close together, which is the usual situation. Several paths fit reasonably well, and the question becomes which of them you could learn to love, and which the world around you makes available.
Three people, three paths
Here are three invented people, each about three years into the role, who made different choices. The details are illustrative.
Asha, who chose to lead. After the lender project of Lesson 8.1, Asha was asked to take on two newer engineers. She found that she enjoyed their growth as much as her own projects. Over a year she moved to leading a team of five, handling the largest customers' relationships and the hiring. Her hands-on time fell from half her week to about a fifth, which she found she did not mind, though she kept one small project to stay close to the work. Her difficulty was learning to let her team make decisions she would have made differently. A mentor's advice, "ask what they would do and why before you say what you would do", helped.
Imran, who chose product. After the integration incident of Lesson 8.2, Imran found that the thing he enjoyed most was writing the field brief and seeing the product team act on it. He asked to move into a product role on the data connectors, the part of the product his incident had touched. His first six months were humbling: he had to say no to many requests that he would once have championed, and learn to weigh them against the roadmap. He kept up his customer calls, which gave his decisions an advantage over colleagues who had never been in the field. He missed deploying, and found that building the right thing at scale was a different satisfaction.
Priya, who chose to start something. Priya kept a pattern log from her first year. Over three years it showed one need appearing at seven lenders, a reliable way of checking customer messages against contact-hour rules in several languages. She spoke with four of the lenders about whether they would pay for it as a product, and two said yes. She also took advice from a lawyer about what she could use from her work and what she could not, and left on good terms, with an agreement not to solicit her employer's customers for a period. Her first year as a founder was harder than any deployment: selling, hiring and cash. She said later that the field gave her the problem and the first customers, and that everything else she had to learn.
None of the three is the right answer. Each used what the role gave them, and each paid a price. The point is that they chose deliberately, with information, and not by drift.
The chart earlier showed building time shrinking as responsibility grows. You can see the arithmetic for a lead. Set the size of the team, the coaching time each person needs and the other things a lead's week holds.
At the defaults, a lead of five people with 2.5 hours of coaching each, eight hours of planning, ten on escalations and key customers and six on hiring has about 8.5 hours left for hands-on work, around a fifth of the week, which matches Asha's experience in the example above.
Build a plan for the next twelve months
Whatever direction you choose, growth rarely happens by accident. A simple plan, reviewed regularly, makes it much more likely. It has five parts.
1. Where you want to be in a year, in one sentence. Specific enough to check: "I lead one customer programme end to end, including its handover, and I have mentored one new engineer."
2. Two or three skills to build. Chosen from the map in Lesson 1.4 or from your target path: for example, coaching, pricing or a technical area. Be specific about what a working level looks like.
3. Stretch assignments. Ask for the work that would grow those skills: a harder customer, a first demo to an executive, a field brief for the product team, a mentoring role. People rarely get these without asking.
4. People. One mentor who has done what you want to do, ideally outside your direct line, and one peer with whom you can compare notes. Ask for specific advice, and be ready to act on it.
5. Evidence. A running record of what you did and what it changed: the value reports, the briefs, the handovers, the feedback you received. It is the raw material for promotions, interviews and your own confidence.
Review it every quarter, for half an hour. What did you do? What did you learn? What will you do next? A plan that is revisited is a plan that works, and one that sits in a drawer does not.
Look after yourself
The role can be demanding. It combines customer pressure, irregular hours, travel, the possibility of being called when something breaks and the load of carrying many people's expectations. Many of the practices in this track, such as clear scope, honest updates, a runbook and a proper handover, also protect you. A few more are worth saying plainly.
Set limits and keep them. Agree what is urgent enough to interrupt your evening, and what can wait.
Share the load. A bus factor above one is for your sake as well as the customer's.
Take real breaks. Plan time off, and hand over properly before it.
Say when you are stretched. Telling your manager early is the same behaviour as telling a customer early.
Keep learning for its own sake. Curiosity is what lasts across a long career.
Looking back at the track
You began this track by learning what a forward deployed engineer does and how the role differs from its neighbours. You then followed the loop of the role through its stages. You learned to find the real problem and the real people, to scope a pilot, to audit and reach a customer's data, to build the least that works, to put a language model to work responsibly, to demonstrate honestly, to deploy and operate and to hand over. You learned to communicate, in demos, in bad news, in updates and in training, and to carry what you learned back to the product, prove the value and keep the work inside its boundary. The last module put it together in two cases, an interview and a career.
The thread through all of it is a single idea. The value of this role lies in the gap between a general product and a particular customer, and the work is to close that gap honestly: understanding before building, evidence before claims, early and plain communication, and a handover that leaves the customer stronger. Those habits are useful far beyond the title, which is why they are worth practising even if you never hold it.
Common mistakes
Treating management as the only way up. There are several routes, and a senior individual track is as valuable in many organisations.
Choosing by default. Drifting into the next step offered, without asking whether it suits you.
Choosing by title. Look at what the work is, using the four questions of Lesson 1.2, and not at what it is called.
Staying the hero. Growth needs you to make yourself less necessary to each project.
Ignoring the cost. Every path trades something, such as variety, building, closeness or security. Name the trade.
Starting a company from one data point. A need seen at two customers is not yet a market. Check, cheaply.
Using what you should not. Take advice on confidentiality and your obligations to your employer before you leave to build something.
No plan. Growth rarely happens by accident. Write the twelve-month plan and review it each quarter.
Neglecting yourself. Set limits, share the load and take breaks.
Key takeaways
The role builds strengths that are valuable almost anywhere: customer insight, shipping under constraint, communication across worlds, ownership, pattern recognition and judgement under ambiguity.
The main paths are deeper in the role as a senior or staff engineer, leading others, product management, core engineering, pre-sales and architecture, and founding something. Each changes the work and asks you to add skills.
No path is better than the others. Choose by what energises you, what you want more of, what you are good at and what your life asks of you, and test before you commit.
Leading changes your output into your team's, and your hands-on time falls. Product means deciding what to build, and founding means carrying the whole risk.
Make a twelve-month plan with a one-sentence goal, two or three skills, stretch assignments, a mentor and a peer, and an evidence record, and review it quarterly.
Look after yourself: set limits, share the load, take breaks and say early when you are stretched.
Check yourself
1. Name four strengths the forward deployed role builds.
Any four of: customer insight, shipping under constraint, communication across worlds, ownership, pattern recognition and judgement under ambiguity.
2. What typically happens to hands-on building time as someone moves toward leading a team?
It shrinks, while time leading others and on strategy grows. The shape differs by path.
3. You like the customer work and building but dislike managing. What options exist besides becoming a lead?
A senior or staff track, growing in scope while staying hands-on, adjacent routes such as architecture or product, or trying a small piece of mentoring to test your reaction.
4. A person rates building 90, customers 20, strategy 30, leading 20 and risk 30. Which path from the simulator matches best, and what is the score?
Core product engineer, with a score of 100, since the ratings equal the profile.
5. Name two things to be careful about before leaving to found a company.
Mistaking a need seen at one or two customers for a market, and the limits on using confidential information and customer relationships from your employer. Take advice on both.
Try this
This exercise takes about forty minutes and gives you a twelve-month plan. Use your own situation, whether or not you hold the role yet.
1. List your last three projects or experiences. For each, write what gave you energy and what drained you.
2. Use the simulator to compare your preferences with the five paths. Write the top two, and what you would need to love to enjoy each.
3. Find one person who does each of your top two paths. Write three questions to ask them about a normal week and the hardest part.
4. Write where you want to be in a year, in one sentence you could check.
5. Choose two or three skills to build, and write what a working level looks like for each.
6. Write two stretch assignments you could ask for in the next three months, and who you would ask.
7. Name a mentor you would approach, and write what you would ask of them in the first conversation.
8. Start an evidence file: write down three things you did in the past year and what they changed.
9. Put a thirty-minute review on your calendar every quarter for the next year.
A good result is a plan on one page, with a one-sentence goal, two or three skills, two stretch assignments, a mentor, an evidence file and four review dates. It is the last document of this track, and the first of your next stage.
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 observation, from company staff, that there is a lot of movement between the field and product-development roles because the company values exposure to different problems, and for one engineer's description of enjoying the bird's-eye view after moving from individual contributor to leading teams. These are one company's staff describing their own practice.
The career paths, the profiles in the simulator, the three people, the time-shift chart and the twelve-month plan are the author's illustrations and practical guidance for teaching, not data from surveys or any employer's career framework. Nothing here is career, legal or financial advice. Take advice on confidentiality and employment terms before leaving a job to start a company.
Tags: Forward Deployed Engineer Career growth Leadership Product management Founders