Lesson 1.4: The skills map and how to build each one
Eight skills cover most of what a forward deployed engineer needs. Learn what each is, how to build it from scratch, and how to find and close your gaps.
By the end of this lesson you will be able to name the eight skills that cover most of a forward deployed engineer's work, say what a working level of each looks like, and build a realistic plan for the ones you lack. You will see three people with different backgrounds plan their way into the role, and you will use a simulator to turn a self-rating into a number of weeks. The lesson closes Module 1, so it also looks back at the role described in Lessons 1.1 to 1.3 and asks what it takes to do it. You do not need any particular background. The skills here can be learned from the beginning, and the plan at the end is designed for someone who has a job and limited spare hours.
A common worry among people who are curious about this role is that it asks for everything: coding, data, cloud systems, security, communication, business sense and now language models too. The worry has some truth, since the role is broad. But broad does not mean deep in everything. Most people in the role are strong in one or two areas and competent in the rest, and they learn the remainder as each project requires. A skills map helps by showing what the pieces are, how deep you need to go in each one and in what order to build them.
Why a map helps
Without a map, learning is random. You follow whatever tutorial appears next, you spend two months on a topic that turns out to be marginal and you never practise the dull skill that would have helped most. With a map, you can see the whole territory, rate yourself honestly, choose the biggest gaps and spend your limited hours there.
The map in this lesson is a teaching tool, not an official standard. No exam certifies a forward deployed engineer, and employers describe the role differently. In a 2019 post on Palantir's engineering blog, one engineer who holds the role even calls the group "a bit of an artists' colony", saying that each person has a skill set that makes them valuable, so that it is hard to pin down exactly what is required. The same engineer lists traits such as strong empathy for users, a desire to understand business strategy, creativity in solving problems and independence. Another lists technical decomposition, which means breaking a high-level problem down to the code needed to solve it, along with autonomy, strong technical intuition and thoughtfulness about what is best. Read these as examples of how practitioners describe themselves. The eight skills below are a practical grouping of the same ground, written for learning.
The shape: broad, with one deep spike
The most useful picture of the target is the letter T. The horizontal bar is a working level across all eight skills: enough to take part in any conversation, to do simple tasks yourself and to know when to ask for help. The vertical bar is one or two skills in which you are genuinely strong. The strong one differs between people. Some come from software and are deep in code. Some come from data and are deep in analysis. Some come from operations or consulting and are deep in understanding a business.
Two ideas follow. First, you do not need to be top-class at everything, so you can stop worrying about the longest list. Second, your spike gives you a place to start. Hire managers look for someone who can do something real from day one. Then the breadth is what allows you to survive the variety of projects.
The eight skills
Each skill below is described in the same way: what it is, why the role needs it, what a working level looks like and one way to build it. "Working level" means you can do the basic tasks alone and explain your choices, not that you are an expert.
1. Programming in one language
What it is. Writing code that works and that others can read. Python is a common choice for this role because it is used for data, scripts, integrations and many language-model tools, but any mainstream language teaches the same habits.
Why the role needs it. Almost every deliverable involves code: a script that loads a customer's file, a service that calls an interface, a test that checks a result.
A working level. You can break a small problem into functions, handle errors, read other people's code, use a package, write a simple test and use version control. You can build a small program of a few hundred lines.
How to build it. Work through a beginner course, then immediately build something small that you actually want, such as a script that cleans a messy spreadsheet. Read other people's code in small open projects. The quickest improvement comes from writing, running and fixing, not from watching.
2. Data and SQL
What it is. Reading, cleaning and questioning data, especially in tables. SQL is the common language for asking questions of a database.
Why the role needs it. The customer's data is where most surprises live. Dates in two formats, missing values, duplicate customers and fields that changed meaning last year are ordinary. An engineer who can inspect data quickly finds problems before they reach production.
A working level. You can write queries that filter, group, join and count. You can spot obvious data problems, such as nulls, duplicates and impossible values. You can explain what one row of a table stands for.
How to build it. Take a public dataset and ask ten questions of it using SQL. Then deliberately break it, for example by inserting duplicates, and write queries that find the damage. Learning to doubt a dataset is as important as learning to query it.
3. Interfaces and integration
What it is. Connecting one system to another through interfaces (often called APIs), which are agreed ways for programs to talk. It includes authentication, which proves who is asking, and webhooks, which let one system notify another when something happens.
Why the role needs it. Customers do not run your product in isolation. It must receive their data and send results back to the systems they already use. A large share of deployment work is integration.
A working level. You can read an interface's documentation, make a request, handle errors and rate limits, store credentials safely and write a small program that moves data between two services.
How to build it. Pick two public services with free interfaces and write a program that takes data from one and posts it to the other. Make it retry when the second service is slow. Then change one field name in the first and see what breaks.
4. Cloud and deployment
What it is. Running software somewhere other than your own laptop: on a cloud provider, in a customer's private cloud or on their own servers. It includes packaging code so it runs the same way everywhere, releasing new versions and rolling back a bad one.
Why the role needs it. The deliverable is software running in production, in the customer's environment, under their rules. Many customers will not let data leave their own cloud account, so you have to deploy there.
A working level. You can package a small service in a container, run it on a cloud virtual machine or a managed service, read its logs, set it to restart on failure and update it without losing data.
How to build it. Take the integration program you wrote for skill 3 and deploy it somewhere free or cheap. Make it run on a schedule. Then break it on purpose and practise reading the logs and restoring it.
5. Security and access basics
What it is. Handling secrets, permissions and sensitive data responsibly: who can see what, where passwords live, what must be logged, and what a customer's security team will ask.
Why the role needs it. You are working inside someone else's systems with their real data, and the cost of a mistake is high. Customers in banking, healthcare and government will review every access you ask for.
A working level. You can explain the principle of giving only the access that is needed, keep secrets out of code, describe how data is encrypted in storage and in transit, and answer a basic security questionnaire honestly.
How to build it. Read the security page of a cloud provider you use and a short public checklist on handling secrets. Then audit your own practice project: where does it keep its keys, who could read its data, what would a log reveal? Fix three things you find.
6. Working with language models
What it is. Building features on top of language models: writing prompts, giving the model your own documents, checking its answers and controlling cost. A full track on AI Engineering covers this in depth, and you should read it alongside this one.
Why the role needs it. Many new forward deployed roles are at companies whose products are built on language models, and customers want assistants, summaries and automation. The engineer's job is to make these reliable in a real business setting, which is much harder than making a demo.
A working level. You can call a model through its interface, write a prompt that returns structured output, supply documents through retrieval, and build a small set of test cases that shows whether a change made the answers better or worse.
How to build it. Build a small assistant that answers questions about a set of documents you care about. Write twenty test questions with known answers before you change anything, and rerun them after each change.
7. Discovery and listening
What it is. Finding out what a customer really needs. It means asking good questions, watching how work is done, mapping who decides and noticing the difference between what people ask for and what would help them.
Why the role needs it. The first description of a problem is often wrong, as Lessons 1.1 and 1.2 showed. Building quickly on a wrong description wastes the speed advantage.
A working level. You can run a thirty-minute interview with a non-technical person and come away with their process written down in steps, the places where they wait or fix mistakes, and one question you did not know to ask when you started.
How to build it. Interview someone about a task they do every week, and ask them to show you instead of telling you. Practise the follow-up "and then what happens?" and the follow-up "why?" until they feel natural. Write one page on what the person asked for and what they seem to need.
8. Writing and presenting
What it is. Explaining technical ideas to people who are not technical, in short written updates and in conversation. It covers demos, status notes, plans, and the delicate task of giving bad news.
Why the role needs it. The customer's executives decide whether your work continues. They read your notes, not your code. A solution that nobody understands will not be adopted.
A working level. You can write a one-page update in which the first sentence tells the reader the situation, the second the next step and the third what you need from them. You can explain a technical choice to a manager without jargon.
How to build it. Write a weekly one-page update on any project of yours, even a hobby, for a month. Ask one reader what was unclear. Practise a five-minute demo aloud and time it.
How deep is deep enough?
A natural question is how much of each skill you need. The honest answer is that it depends on the company and the project, but a rough guide helps. The chart below shows illustrative numbers for how many hours it might take a motivated beginner to reach a working level in each skill. They are teaching estimates, not measurements, and they vary a great deal with background. Someone who already codes will reach a working level in cloud basics far faster than someone starting from nothing.
Two points stand out. Programming is the largest single investment, but it is not most of the total. Adding the figures gives 385 hours, and programming is about a third of it. And the human skills, discovery and writing, together take about as long as learning to deploy software. They are not afterthoughts. They are the skills that most people skip, because they feel less like study.
Predict first: of the eight skills, which one would you guess beginners most often skip when they prepare for a role like this, and why? Decide before reading on.
The usual answer is discovery and listening, followed closely by writing. Both are invisible in a course catalogue, no tutorial site sells them and the results are slow to show. But in the field they decide whether your technical work is pointed at the right problem. Many strong engineers have learned this the hard way. One useful side effect is that people who practise these two early stand out in interviews, because few others have anything to say about them.
Worked example 1: a data analyst moves toward the role
Meera is a data analyst at a retailer. She writes SQL every day, builds dashboards, explains results to managers and has written some Python for analysis. Her spike is data. She rates herself on a scale of 0 to 10, where 6 means a working level:
Programming 5, data and SQL 8, interfaces 2, cloud and deployment 1, security basics 2, language models 3, discovery 7, writing 7.
With a target of 6 in each skill, her gaps are one level in programming (6 − 5), four in interfaces, five in cloud, four in security basics and three in language models. Data and the two human skills are above target. The total gap is 17 levels. If a level takes about fifteen hours, that is 255 hours, and at eight hours a week it is about 32 weeks. That sounds long, but she does not have to learn it all in order and she can overlap them.
Her plan: first, build and deploy one small integration project that covers three gaps at once: it calls an interface (skill 3), runs on a cloud service (skill 4) and handles keys properly (skill 5). Then she builds a small document-based assistant (skill 6) on the same cloud setup. Her data spike and her understanding of business users will make her stronger than the average beginner in those projects. Notice that she did not start from the largest gap. She started with a project that exercises several gaps at once, because projects teach several skills at the same time and make a better story in an interview.
Her gaps against the target of 6 sit mostly in the technical areas she has not worked in. The chart shows them skill by skill.
Worked example 2: a backend developer moves toward the role
Arjun is a backend developer at a software company. He writes services in Python or Java, deploys to cloud systems and works with interfaces every day. His spike is engineering. He rates himself: programming 8, data 5, interfaces 8, cloud 7, security 5, language models 3, discovery 2, writing 4.
His gaps against a target of 6 are one in data, one in security, three in language models, four in discovery and two in writing. The total is 11 levels. At fifteen hours a level, that is 165 hours. Notice that most of the remaining work is not technical. For Arjun the missing skills are people skills.
His plan is different from Meera's. He starts with the human skills because they are the largest gap and the one he can practise at work. He volunteers to sit in on two customer calls, writes up what he learns and asks a support colleague to read his notes. For the next ten weeks, he writes a one-page weekly update on his own project. The technical gaps are smaller and he fills them with a weekend project: a small assistant over a customer-like dataset.
The pattern is one to remember. Engineers tend to underrate the people skills because they are harder to measure, and the result is a profile that is strong where it was already strong. An honest rating usually finds the gap in the soft skills first.
Worked example 3: a consultant moves toward the role
Neha is a business consultant. She is strong at problem structuring, stakeholder interviews and presentations. She has done a little SQL but has never deployed software. Her ratings: programming 2, data 4, interfaces 1, cloud 0, security 3, language models 2, discovery 9, writing 8.
Against a target of 6, her gaps are four in programming, two in data, five in interfaces, six in cloud, three in security and four in language models. The total is 24 levels. At fifteen hours a level, that is 360 hours, and at nine hours a week it is 40 weeks. This is the longest of the three plans, and it is honest to say so: moving from advice to building takes real time.
Her plan is built around her spike. She is already stronger than most beginners at discovery, so she chooses a path where that skill is visible: she builds small, working tools for real colleagues, with each project starting from a proper interview. She does not wait to become a good programmer before she starts. She builds, with help, and tracks her own progress. A year of this produces a portfolio of three working tools with written case notes, which is attractive to employers who want someone who can both listen and build.
The three plans share a structure: find the spike, find the gaps, start with projects that use several skills at once, and let the strongest skill carry the story. They differ in total effort and in which skills lead.
Put the three plans next to each other and the difference in effort is plain. The consultant has the most to learn, because her strengths lie in the human skills, and the backend developer the least, because his are technical and the technical gap is small.
Find your own gaps
The simulator below turns the self-rating into a plan. Rate yourself from 0 to 10 on each of the eight skills, using 6 as a working level, and set your target. The tool adds up the gaps, converts them to hours and weeks, and shows which skills are furthest below the target.
The defaults describe a mixed profile like those above. The hours per level are an illustrative assumption: change it if you learn faster or slower. A good experiment is to enter your own ratings honestly, then lower the hours a week you can really give and see the number of weeks rise. Then raise the target to 7 and notice how much longer the total grows. A higher target costs far more than it seems.
At the defaults the gaps add up to 18 levels: none in programming, two in data, three in interfaces, four each in cloud and security, three in language models, one each in discovery and writing. At fifteen hours a level that is 270 hours, and at eight hours a week about 34 weeks. Notice how much of the total sits in the cloud and security gaps. These are the two skills most people skip because the work feels dry, and they are the two that customers' security teams will test you on first.
Building skills by doing
The fastest way to build these skills together is to treat practice like small customer projects. A good practice project has four features: it solves a real problem for a real person, it touches several skills, it runs somewhere other than your laptop and it comes with a short written account. Here are three examples that cover the whole map.
The nightly file project. Take a messy file that a friend or an employer sends you every day, clean it, load it into a database, and send a short summary of problems each morning. It covers programming, data, deployment and writing, and it leads you through the first problem every customer has: data that does not look the way you were told.
The two-systems project. Connect two services you already use, for example a form tool and a spreadsheet, so that new entries flow in automatically. It covers interfaces, authentication, error handling, security of keys and deployment.
The assistant project. Build a small question-answering tool over documents someone really needs, such as a club's rules or a shop's product guide. Interview the person first. Write twenty test questions, check the answers, and show the person. It covers language models, discovery and writing together.
For each project, write a one-page account: what the person needed, what you built, what went wrong and what you would change. These pages are your portfolio. They also train the skill of describing what you did to a non-technical reader, which an interviewer will test.
Pacing yourself
Learning for a role like this takes months, so pacing matters more than intensity. A few ideas help.
Small, regular hours beat rare long ones. Six hours a week for six months produces more than a month of daily twelve-hour days followed by exhaustion.
Alternate technical and human skills. One week on a technical project, one week practising interviews or writing keeps both moving and keeps boredom away.
Revisit your ratings every month. Honest re-rating shows progress, which is motivating, and shows where your plan is drifting.
Ask for feedback early. One kind person reading your one-page update tells you more than a month of private practice.
Use the job as a classroom. If you have a job, look for small ways to use these skills in it: sit in on a customer call, take over an integration task or write the weekly update.
Common mistakes
These mistakes slow people down most often.
Learning in the order of a course catalogue. Courses are organised by topic. Roles are organised by problems. Learn by building projects that cross topics.
Skipping the human skills. Listening and writing look easy, and are the ones most often missing. Practise them on purpose.
Trying to be deep in everything. The aim is a T shape: working level across the map and one real strength.
Never deploying. Code that runs only on your laptop teaches half the lesson. Put every practice project somewhere it keeps running.
Rating yourself kindly. An inflated rating produces a plan that skips your real gaps. Ask a friend or colleague to check your ratings against your work.
Waiting until you are ready. You will not feel ready. Build a first small thing for a real person soon, and learn from what goes wrong.
Chasing the newest tool. Tools change quickly. The ideas under them, such as breaking down a problem, reading data critically and explaining clearly, last much longer.
Key takeaways
Eight skills cover most of the role: programming, data and SQL, interfaces and integration, cloud and deployment, security basics, working with language models, discovery and listening, and writing and presenting.
The goal is a T shape: a working level across all eight and one or two real strengths.
The human skills, discovery and writing, are the ones most often skipped, and they decide whether technical work is pointed at the right problem.
A self-rating against a target turns a vague worry into a number of hours and weeks, and a higher target costs much more than it appears.
Projects that cross several skills, deploy somewhere real and come with a short written account build skills and a portfolio at the same time.
Small regular hours, regular re-rating and early feedback matter more than intensity.
Check yourself
1. Name the eight skills on the map.
Programming, data and SQL, interfaces and integration, cloud and deployment, security and access basics, working with language models, discovery and listening, and writing and presenting.
2. What does the T shape mean, and why is it a better goal than depth in everything?
A working level across all skills plus one or two real strengths. It is achievable, gives you something real to offer from day one and lets you cope with the variety of customer projects.
3. With a target of 6, your ratings leave gaps totalling 18 levels. At 15 hours per level and 9 hours a week, how many weeks does it take?
18 × 15 = 270 hours, and 270 ÷ 9 = 30 weeks.
4. Why do engineers tend to underrate the human skills when they rate themselves?
They are harder to measure and feel less like study, so the profile stays strong where it already was. An honest rating, checked by a colleague, usually finds the gap there.
5. What four features make a good practice project?
It solves a real problem for a real person, touches several skills, runs somewhere other than your laptop and comes with a short written account.
Try this
This exercise takes about forty minutes and gives you a personal plan.
1. Rate yourself from 0 to 10 on each of the eight skills, using 6 as a working level. For each rating, write one sentence of evidence: a thing you did that proves it. If you cannot write the sentence, lower the rating.
2. Ask one person who has seen your work to check three of your ratings and tell you if any seem too high or too low.
3. Enter your ratings in the simulator above. Use a target of 6 and an honest number of study hours a week. Write down the total gaps, hours and weeks.
4. Circle your two largest gaps and your one strongest skill. The strongest is your spike. Write one sentence on how you would use it in the role.
5. Choose one of the three practice projects, or invent one with a real person, that touches at least three of your gaps. Write what you will build, who it is for, where it will run and the date you will show it to them.
6. Book three one-hour slots in your calendar for the next two weeks to work on it.
A good result is a one-page plan: your ratings with evidence, your spike, your two biggest gaps, one project with a name, a person and a date, and three booked hours. Come back in a month, re-rate yourself and update the plan. This plan is also the first step of the one-page document that a forward deployed engineer writes at the start of every project, which later modules cover.
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 engineers' own descriptions of the traits and skills that matter in the role, such as technical decomposition, autonomy, user empathy and understanding business strategy, and the remark that each person's skill set is different. These are company staff describing their own roles.
The eight-skill map, the working-level descriptions, the hour estimates, the three people and all figures are the author's teaching illustrations, not data from a survey, an employer or a certification.
Tags: Forward Deployed Engineer Skills Careers Learning plan Beginner