Palantir Architect 100% Remote
Integrations Solution Lead or Lead Solution Architect – Palantir & Integrations.
Role Context
My role is general / cross-domain architecture across Service Solutions and Digital Solutions. I focus on enterprise architecture, target-state patterns, governance, ownership boundaries, integration/data patterns, and major solution decisions.
The reason I’m helping define this role is because a lot of the work this person should own is currently landing with me by default: intake, triage, solution shaping, coordination, incident/RCA follow-up, documentation, production readiness, and support handoff for Palantir/integration topics.
The new person should work closely with me, but not depend on me for every step.
Simple boundary:
This person owns execution clarity. Enterprise Architecture owns architecture judgment.
Role Summary
We need someone who can own the messy middle between architecture direction and production reality.
This person should be able to take an ambiguous ask, clarify the path, pull the right people together, track blockers, drive documentation, coordinate incidents/RCA follow-up when needed, make sure support readiness is covered, and escalate only true architecture decisions.
Suggested Role Titles / Search Terms
Please search broader than only “Palantir Engineer.” Good candidate titles may include:
- Palantir / Integrations Solution Lead
- Lead Solution Architect – Palantir & Integrations
- Palantir Foundry Solution Architect
- Forward Deployed Engineer / FDE
- Technical Product Owner / FDE
- Integration Solution Architect
- Data Platform Solution Lead
- Foundry Application / Ontology Lead
The title matters less than the behavior. We need someone who can lead workstreams end-to-end.
What This Person Should Own
- Palantir / Foundry request intake and triage
- Integration solution shaping across APIs, Databricks, MDM, source systems, SOA, Service Bus, etc.
- Working sessions, owners, blockers, and follow-through
- Incident and RCA coordination for Palantir / integration issues
- Data contract and API readiness tracking
- Production readiness, runbooks, and support handoff
- Stakeholder updates, meeting notes, and decision logs
- Escalation to Enterprise Architecture only when needed
Must-Have Candidate Traits
- Palantir / Foundry exposure
Ideally hands-on with datasets, pipelines, ontology, actions, functions, apps, data connections, or production workflows.
- Strong integration experience
APIs, source systems, data contracts, batch/event patterns, Databricks, Azure, SOA/middleware, or similar.
- End-to-end ownership
Can take vague work and drive it to a supportable outcome without waiting for perfect clarity.
- Production mindset
Understands incidents, RCA, monitoring, runbooks, production readiness, and support handoff.
- Stakeholder leadership
Can lead without formal authority, run working sessions, push for owners/dates, and drive closure.
- Architecture judgment
Knows when to resolve something independently versus when to escalate for EA/governance/ownership decisions.
Candidate Red Flags
I would be cautious with candidates who are:
- Only dashboard/reporting focused with Palantir listed as a keyword
- Only project managers without technical integration depth
- Only deep engineers who need someone else to manage stakeholders, blockers, documentation, and support handoff
- Senior enterprise architects who only want strategy and not execution
- Unable to explain a production issue, integration issue, or ambiguous delivery problem they personally helped drive to closure
Palantir Experience Guidance
Palantir / Foundry experience is important and should be prioritized. That said, if the candidate has very strong integration solution leadership, production support mindset, and end-to-end ownership behavior, I would still consider them even if their Palantir exposure is lighter. The key is whether they can learn fast and lead in ambiguity.
Screening Questions
Here are the questions I’d recommend using for first-pass screening:
- Tell me about a Palantir Foundry solution you helped deliver end-to-end.
- What Foundry components did you personally work with? Datasets, pipelines, ontology, actions, functions, apps, data connections, etc.?
- Tell me about an integration-heavy project you led. What systems were involved?
- Have you owned or coordinated production support, RCA, runbooks, or support handoff?
- How do you handle an unclear ask where the source system, owner, and data contract are not clear?
- Have you led cross-functional teams without direct authority?
- What would you do if a Foundry action failed because a downstream API was returning 503 errors?
- How do you distinguish between a routine delivery issue and something that needs architecture escalation?
- What artifacts do you normally create to keep a workstream under control: decision logs, action trackers, runbooks, data contracts, support handoffs, etc.?
- Describe a time you inherited a messy technical problem with unclear ownership. How did you drive it to closure?
Never miss an opportunity! Create an alert based on the job you applied for.