As a Hiring Manager for engineers, I get a lot of questions about our unique engineering model. Specifically, people want to know: what’s the difference between a Software Engineer and a Forward Deployed Software Engineer? I polled Palantirians from around the globe for their answers to these and other common questions from candidates. Whether you’re applying for a job here or you’re just curious about how we operate, I hope this post helps you understand how we build and deploy software, and what it’s like to work in these two roles.
Wait, what’s a Delta?
Software Engineers and Forward Deployed Software Engineers are our biggest engineering roles by headcount. Internally, we call them “Devs” and “Deltas.” (While you can guess the origin of “Dev,” “Delta” is a throwback to our early days, when each team in Business Development was named after a letter in the NATO alphabet.)
Devs (Software Engineers) develop and engineer our software platforms, Palantir Foundry and Palantir Gotham. Devs are part of Product Development, one of our four main divisions (the others being Business Development, Internal Development, and Sales). A Dev is part of a team that owns a platform component, such as Foundry Storage Infrastructure or Gotham UX, from end to end. Devs spend their time writing code and working with their team to make design and architecture decisions that impact code that will ultimately be deployed to many different customers for many different use cases.
In terms of responsibilities and skills, the Dev role at Palantir lines up with other companies, but our flat hierarchy and collaborative culture make it unique. “There’s a lot of autonomy at Palantir,” says Helen, who leads back-end development for a Foundry team. “I don’t have a manager who tells me exactly what to build and how to build it. Instead, I work with my team — me, a Product Manager, Product Designers, and front-end and back-end Software Engineers — to determine what architectural changes we need to make to support the product vision.”
Deltas (Forward Deployed Software Engineers) deploy our software platforms to customers. Deltas are part of Business Development, and their mandate is to achieve technical outcomes for our customers. As part of a team that directly supports one customer, a Delta focuses on technology-driven value creation: deploying and customizing Palantir platforms to tackle critical business problems. They measure success in terms of impact on the customer’s goal. For example, we work with manufacturers who want to reduce the number of defective products coming off the assembly line. To move the needle on that metric, a Delta uses Palantir products, a variety of languages, open-source tooling, and industry-standard build tooling, and their own creativity to devise a solution. You can think of a Dev’s focus as “one capability, many customers,” while a Delta’s focus is “one customer, many capabilities.”
A common misconception is that a Delta is a consultant. “We’re similar in that we both have the goal of making our customer become more efficient or better in some way,” says Elisa, a New York-based Delta. “However, consultants generally create a one-time analysis, recommendation, or solution to a specific problem, while at Palantir we work together with our customers to build a long-term solution that allows the customer to continuously improve themselves.”
“In my mind, the critical difference is that we are actually deploying existing software products to achieve the customer’s outcomes,” says Dyon, a Delta who works in our Abu Dhabi office. “A Delta does significantly more engineering and technical work than a consultant,” adds G.M., who works in São Paulo. Being a Delta “requires a degree of technical experience that is rare to see in consulting work.”
Several of the Deltas I spoke to also mentioned that they often contribute code back to the core product. “If what’s standing between a Business Development team and a successful outcome is a missing feature, capability, or bug fix in one of our platforms, it may make sense for them to spend time doing it,” says Ian, a Washington D.C.-based Dev who previously worked as a Delta, adding that it’s “important that they coordinate with the product team.” “Larger feature requests need to be validated against their roadmap and incorporated into it,” says Elisa. “As you’re developing your feature, you’ll be in constant communication with the team to ask them questions on the code, or to have them validate or review your changes.”
With these definitions in mind, let’s dive into some more reflections from my colleagues on what it’s like to be a Dev or Delta at Palantir.
What does the day-to-day of your role look like?
Ian (Washington D.C.): “Right now, I’m working on a pilot-stage capability for the Gotham platform, so my day-to-day feels like being a developer at a small startup. I’m working hand in hand with a team that’s piloting this capability with a customer to build out new features at a rapid cadence, while still making good decisions for the future of this young product.”
Helen (New York): “As the lead for back-end development on my team, I spend a few hours a week prioritizing, planning, and tracking work across the various work streams in my product. I meet with customer-facing teams to discuss their highest-priority product requests and determine how they fit into our roadmap. I write code and review my teammates’ code and perform support duties, like answering questions in Slack, debugging, and responding to support tickets.”
G.M. (São Paulo): “My ‘day-to-day’ changes month-to-month, which is a cool feature of my role! Some weeks, I spend most of my time developing and reviewing my team’s code, like a typical Software Engineer. Other weeks, I spend most of my time scoping the future of a project with a client, or working with users to make sure the things we’ve built meet their needs. The variations in the demands of my role make it exciting.”
Dyon (Abu Dhabi): “Most weeks, I spend a couple of days working at the customer premises, some of that time in meetings with technical or business stakeholders and the rest of the time monitoring, debugging, deploying, or configuring our software for that customer. Back in the office, I spend some time writing minor code changes, reviewing pull requests, and researching/planning customer solutions. The remainder of my time is spent communicating via email or VTC with our internal support and product development teams, and with my direct reports who are based in a number of remote offices.”
What are some examples of skills that are important for your role?
Matt (Palo Alto): “You need to be able to synthesize product feedback into a technical strategy, prioritize work effectively across a variety of different stakeholders, and implement features with clean and maintainable code.”
Ian (Washington D.C.): “The typical things a Software Engineer needs, along with some Palantir-specific skills around navigating the double-edged sword of relatively flat hierarchy. Depending on the project, you’ll need higher levels of empathy and interpersonal skill compared to many engineering roles.”
Elisa (New York): “A few come to mind:
- ‘Technical decomp.’ Our job is to take a high-level problem, ‘decompose’ or break it down, and design a solution. We need to be capable of understanding from the high-level business problem down to the lines of code you need to solve it.
- Autonomy and strong technical intuition. Teams are small, and projects move quickly. It’s important that you’re able to figure things out autonomously. Strong technical intuition helps you move fast as you learn a new coding language by yourself, figure out how to create a plugin, debug an issue in the platform, etc.
- Thoughtfulness and criticality. It’s important that you can analyze a situation and form your own opinion on what’s best. You’re given responsibility quickly, and trusted to make important decisions. For example, you’ll frequently need to decide whether to invest time building a feature your customer needs into the core platform, or to create something custom that we can deliver faster.”
Katherine (Washington D.C.): “We are a bit of an artists’ colony. Every FDSE has a unique skillset that makes them valuable, so it’s hard to pinpoint the exact set of skills required for success. Things like high user empathy, an ability and desire to understand business strategy, creativity in problem solving, and independence are some examples of skills I commonly see in successful FDSEs.”
What do you like most about your role?
Ian (Washington D.C.): “I like that I’m being asked to work on things that are technically quite challenging and that I actually care about what I’m building — the users, the use cases, and perhaps most importantly, the outcomes it enables.”
Matt (Palo Alto): “It’s awesome to be able to recognize a broad problem, solve it generally in the core product, and empower Palantirians across the company to better enable our users.”
G.M. (Sāo Paulo): “I like the variety my role offers. My main competency is engineering, but as a Forward Deployed Software Engineer I engage in so many other areas of the business. I feel that I’m constantly learning, constantly pushing my comfort zone, and there’s never a dull moment.”
Elisa (New York): “I can’t express how fulfilling it is to be given a really hard problem that is crucial for a large enterprise, and to plan and build a solution, and then watch the customer use what we build to resolve the problem.”
Katherine (Washington D.C.): “As I’ve moved from being an individual contributor to leading teams, I’ve really enjoyed gaining a bird’s-eye view. Being able to see lots of people’s work come together to produce something really valuable for our client is awesome. I also really enjoy engaging on business strategy and helping translate it into technical execution.”
What’s the coolest or most unusual thing you’ve done in your role?
Matt (Palo Alto): “My team got to tour an Airbus A350 that had just been completed.”
Helen (New York): “I did a three-month rotation in our Singapore office!”
Elisa (New York): “I visited a car manufacturing line where I got to be inside of a car during a quality test, where the car is run through a bumpy test track to test for loose parts.”
Katherine (Washington D.C.): “I’d have to say the coolest thing I’ve done at Palantir is demo our software to the Chief of Staff of a defense service. It’s so inspiring to get the chance to talk to some of the country’s leaders about our software’s game-changing potential.”
Dyon (Abu Dhabi): “Deploying to the Philippines in the aftermath of Typhoon Haiyan [as part of Palantir’s Philanthropy Engineering initiative] and directly applying our data integration, analysis, and visualization tooling to help deliver the most appropriate humanitarian supplies to the areas and people who most needed them was an inspiring application of technology to real-world problems.”
G.M. (São Paulo): “I deployed to Brazil on two weeks’ notice. A year later, I found myself giving an architecture talk to the clients’ engineers in Portuguese, which I learned during my time in Brazil.”
If you’re torn about which role to apply for, know that there’s a lot of movement between them, as we value gaining exposure to different problems and perspectives. “I spent roughly six months working in France as an FDSE, and have spent the last two years based in Palo Alto as a Dev on the Foundry platform,” says Matt. “My experience as an FDSE was really valuable in informing how I think about prioritization as a software engineer.”
Katherine agrees: “I think it’s great when Devs spend time ‘in the field’ to get a firsthand understanding of our users’ experiences.”
“Growth can take many forms at Palantir,” adds Dyon. “While my job title of Forward Deployed Software Engineer hasn’t changed in the seven years I’ve been at Palantir, my role has evolved and morphed into different facets. Many other people I’ve worked with have had much more radical shifts in their roles: from customer-facing to pure product development, and even on to HR roles.”
I myself have switched between these roles. I started as an FDSE, and deployed to the Middle East and Nordic countries. Then, I eventually became a tech lead across all of our international government customers, located in multiple countries and continents. Next, I moved to New York, where I switched to work with our customers in the private sector, before I landed in my current role on the Product Development team. Today, I work with people, growth, and hiring.
During my journey I’ve touched many different parts of the business: product, development, systems and infrastructure, design and architecture, business strategy, people management, and hiring. And at each step of the way, Palantir supported my development and encouraged me to pursue my interests.
In summary, while the goals and day-to-day of these roles differ, it’s easy to see common threads that make engineering at Palantir unique: minimal hierarchy, a collaborative environment, and laser focus on enabling critical outcomes for our customers. I hope this post gave you a better sense for what it’s like to be an engineer at Palantir. If you’re intrigued — I encourage you to apply!
— Interviews were conducted by Dr. Bruno Pontes Soares Rocha, who works at Palantir as a Hiring Manager.