About Nexus

You don't have an AI story if you don't have your data story. That's where NexusOne comes in.

We're the converged data platform for the AI era — composable by design, built on an open-source foundation, and AI-native from the ground up. One identity, one governance envelope, one operational layer across every mainframe, data lake, warehouse, and streaming system in the business. For the first time, enterprises can bring their existing stack along instead of rebuilding it — and still give AI agents full context across the estate.

What we stand for is simple: sovereign data, interoperable systems, decoupled intelligence — delivered the way modern software should be. No rip-and-replace. No multi-year transformation. Our CEO Anu Jain puts it well: we turn the "ball of yarn" of data integrations into a unified engine — less like assembling car parts, more like buying the car ready to drive. 85+ open-source tools pre-integrated. AI-native automations that deploy and self-heal the stack without human toil. Forward-deployed engineers who build shoulder-to-shoulder with customer teams — hands on keyboards, not just on decks.

It's working, and fast. We're tripling revenue year over year, backed by Insight Partners, and running in production in environments most vendors won't touch. Our platform processes credit risk data for 90%+ of US small businesses — 40M+ — every month. Intent signals for 300M+ subscribers monthly for Africa's largest telco. The data and AI layer for a Top 3 US bank.

We're 100+ people across the US and India, headquartered in Atlanta. We think big, move fast, and don't mistake activity for progress. We hire people who'd rather ship the rocket than brief someone on it.

Check out this podcast of Anu talking about our solution here: https://www.youtube.com/watch?v=g8g50sv5GhQ

This is a 0-to-1 build job. There is no formal customer reliability function today — no runbook library, no ticket taxonomy, no clean intake model, no incident framework. You will build all of it, and you will build it AI-native from day one.

The Director of Customer Reliability Engineering owns NX1's customer reliability function end-to-end. Two co-primary teams underneath:

Customer Support — L1–L3 ticket flow, on-call, SLAs/SLOs, runbooks, knowledge management, customer-facing incident response. Covers both stacks (NX1-native and the inherited Cloudera book)
Production Engineering / SRE — the technical execution layer for customer environments NX1 operates. Platform upgrades (NX1 software AND Cloudera/CDP for the inherited book), monitoring and alerting infrastructure, automated response, production incident response, change-management discipline

Both report to you. Both are reliability-engineering disciplines. Together they're the operational engine that keeps NX1 reliable for every customer.

What this role is not: it is not the customer's onboarding owner (that's the Forward Deployed Engagement Manager). It is not the customer's commercial or executive-relationship owner (that's the Strategic Account Director on flagship accounts; the FDEM in Pattern B at mid-strategic). It is the operational engine that keeps NX1 reliable for every customer after the first workload lands — the function that makes the platform trustworthy at the bottom of the stack so the customer-facing roles can do their jobs at the top.

The dual-stack support reality. This role supports two genuinely different worlds in parallel:

The Cloudera book — a small number of customers we operate on CDH/CDP, Impala, Hive, HBase. Their day-to-day support runs through your function. Operating those environments as a managed service is owned by Forward Deployed Engagement Managers with Cloudera experience, not by this role. You need enough Cloudera fluency to support those customers credibly and to be a useful counterpart to the FDEMs running the Cloudera engagements.
The modern NX1-native stack — Kubernetes, Spark on K8s, Trino, Airflow, Iceberg, object storage, containerized orchestration. The strategic future and the dominant majority of the customer base. This is where your operating model design lives.

Cloudera proficiency is a working support competence; the modern NX1 stack is your design center. Candidates whose technical reflexes were formed in CDH/CDP will struggle to design support operations for a containerized platform — the patterns don't transfer. Cloudera fluency for support, NX1 fluency for design.

We are hiring earlier in a candidate's senior trajectory than the seat warrants, on a 2–3 level growth bet — the right hire scales from Director into VP of Customer Reliability or Chief of Customer over 24–36 months. See Risk we are accepting in the internal documentation below.

This is not a "scale an existing org" role. It's not a "run the team that's already there" role. The person we hire will personally write early runbooks, sit on early P1 calls, hire the first few engineers, and build the operating model that the team runs on for the next five years. If that sounds like maintenance work dressed up as a build job, this isn't the right role. If it sounds like the most interesting version of this work, read on.

The strategic bet behind this role: the L1 model from five years ago — eyes-on-glass, runbook lookup, human ticket triage — is the wrong starting point in 2026. We want a leader who designs the operating model around AI capabilities from the ground up, not someone who retrofits AI into a legacy support structure. The difference between "we use AI tools" and "the operating model is built around AI" is the difference between a 10-person team and a 30-person team doing the same work.

What You'll Own

Customer Support Operations (co-primary)

Design and build the L1–L3 support model from scratch — tier definitions, escalation matrix, on-call rotation, SLA/SLO framework, and the AI-native layer that makes it scale
Own 24x7 production support with hard SLAs across a growing enterprise customer base
Build the knowledge management and runbook infrastructure that support engineers and AI agents both rely on
Choose and configure the support tooling stack (ticketing, incident management, observability, status page) as deliberate design choices, not defaults
Drive operational comms during incidents: P1 cadence, postmortems customers can read, written substance for executive escalations (the Strategic Account Director or FDEM owns the customer-facing exec channel; you supply the operational truth)

Cross-Stack Support Coverage (Cloudera + NX1)

Provide credible L1–L3 support across both stacks. Your engineers triage and resolve issues for Cloudera customers as well as NX1-native customers — the support function is one team, even when the underlying tech is two
Design support tiers, on-call rotations, and capacity models that handle both stacks within a single operational frame, not two parallel orgs
Coordinate with the FDEMs running Cloudera-customer engagements: your team handles the day-to-day support tickets; the responsible FDEM (with Cloudera experience) owns the operational management of the customer's environment. Clear seam — you support, FDEM operates
Customer onboarding for delivery engagements is owned by the FDEM, not this role. The MSP engagement (customer relationship, narrative, commercial reality, scope, gross margin) is owned by the FDEM (Cloudera-variant). The MSP technical execution (upgrades, monitoring, automated response) is owned by the Production Engineering / SRE team described below.

Production Engineering / SRE (co-primary)

Build the production operations function from scratch — for customer environments NX1 operates (Cloudera-customer book today, NX1-operated customers as they come online). No upgrade discipline, no monitoring infrastructure, no automated response exists today. You'll build all of it
Own platform upgrades end-to-end: scheduling, pre-upgrade testing in dev/staging, production execution, rollback discipline, change-management hygiene. NX1 software upgrades on the customer environments we operate; Cloudera/CDP upgrades on the inherited book. The FDEM (Cloudera-variant) handles the customer-facing conversation about when and why; you own the how and the technical execution
Own the monitoring and alerting infrastructure: what gets measured, what triggers an alert, what's automated, what escalates to a human, what's documented as a runbook vs. a one-pager exception. Design AI-native from day one — automated response as the goal, human engagement as the explicit exception path
Own production incident response: when an alert becomes an incident, your team is on the call. Coordinate with the FDEM (customer-facing comms) and platform engineering (root-cause fix in the product) as needed. Postmortems on the operational side are written by you; platform-side fixes are written by engineering
Build the automation backbone: runbook execution automation, deploy/upgrade tooling, alert routing, escalation logic, automated remediation for known failure patterns. The bet is that AI-native operating instincts here are the difference between a 5-engineer SRE team and a 15-engineer one
Player-coach posture: personally credible in the work — you'll write early SRE automation, sit on early upgrade calls, lead early production rollouts. You will scale into a strategic-only seat over 24–36 months; for the first 12, you are the function on the SRE side as much as the Support side

AI-Native Operating Model

Design L1 as automation/AI-first from day one — not a 2025 legacy model with AI bolted on
Ship AI/agentic workflows into real support operations with measurable outcomes: deflection rate, time-to-resolution, headcount leverage
Build the data prerequisites (knowledge quality, ticket hygiene, runbook structure) that make AI workflows reliable
Maintain a clear-eyed view of where AI works today and where it doesn't — and design accordingly

People & Org

Hire and develop a team of support engineers and managed service engineers spanning US and India
Build sustainable on-call practices — real geo coverage, comp-time discipline, escalation hygiene
Grow ICs into leads and leads into managers as the org scales
Protect the team from pre-sales pull; build the handoff model with sales and customer success that keeps support engineers focused

Engineering & Commercial Partnership

Feed reliability substance into QBRs and renewal conversations — the SAD or FDEM chairs the customer-facing narrative; you supply the operational evidence (uptime, SLA performance, incident cadence, MTTR trend)
Build the voice-of-customer loop that converts reliability signal into product roadmap input through the platform engineering function
Connect support and reliability performance to ARR, retention, and expansion — not just CSAT

What We're Looking For

Required

8–12 years of experience; 4+ years in customer reliability, support, OR production engineering leadership
Has built a tiered support and/or production-engineering organization from 0-to-1 at a B2B SaaS or data platform company — ideally as a senior IC or first-time leader, not as a veteran of a 50-person org
Has run a global team of at least 15 people across at least two geographies (we want a builder coming up the curve)
Has personally led platform upgrade rollouts on customer-facing production environments and managed at least one rollback — upgrade discipline is a hands-on muscle, not a process muscle
Owned 24x7 production support with hard SLAs and live enterprise customer escalations
Recent operational experience (last 3 years) with Kubernetes-native, modern open-source data infrastructure as the primary stack — Spark, Trino, Airflow, Iceberg, object storage, containerized orchestration
Hands-on with modern observability and on-call tooling: OpenTelemetry, Prometheus, Grafana, PagerDuty / incident.io, structured logging, distributed tracing
Has actually shipped AI or automation into a support OR production-ops workflow with measurable outcomes — not "evaluating" or "exploring"
Bonus, not required: has operated as part of an MSP or managed service business. MSP engagement ownership lives with FDEMs in this org, not this role — but MSP exposure helps you coordinate effectively with them
High agency, builder over maintainer, founding mindset. Will write the playbook AND the early automation from a blank page
Bias toward written clarity. Runbooks, postmortems, status updates, exec briefs live in writing
Atlanta-based or genuinely willing to relocate

Strong differentiators

Cloudera/CDP familiarity as a secondary asset — useful for the inherited customer base, but not your primary operational identity
Built the support function more than once, or built once and scaled to 50+
Open-source community presence or contributions in the NX1 stack (Airflow, Trino, Iceberg, Spark)
Has been on the receiving end of vendor support as a customer and applied those lessons in design

What This Role Is Not

It is not a "scale an existing org" role. If your best story is running a 200-person mature support org, this isn't the right fit.
It is not an AI-augmented version of a legacy support model. The operating model is built around AI from day one.
It is not a pure MSP role. The center of gravity is customer reliability and support. MSP discipline is required as a subordinate dimension; it is not the primary lens.
It is not a process-governance role. We are not looking for ITIL certification. We are looking for someone who knows which process makes the team faster and which process is compliance theater — and can cut the latter.
It is not a Cloudera-focused role with NX1 as an afterthought. Cloudera is the inherited reality and a meaningful book of business; the modern NX1-native stack is the design center. Candidates whose technical reflexes were formed in CDH/CDP, HDFS, HBase, Impala, and Cloudera Manager will struggle to design for a containerized platform where services are ephemeral, observability is layered, and failures cascade differently. The right hire holds both — but the NX1 future is what the operating model is built around.
It is not the customer onboarding owner. Customer onboarding for delivery engagements is owned by the Forward Deployed Engagement Manager (FDEM). Your function receives the customer into ongoing operations after onboarding lands.
It is not the customer's executive-relationship owner. Customer-facing executive comms during major incidents are owned by the Strategic Account Director (flagship) or the FDEM (mid-strategic). You supply the operational truth those conversations are built on — incident sequence, root cause, recovery plan, postmortem — but you don't run the relationship.

Why You’ll Love Working at Nexus

At Nexus, we value people who want to grow — and support each other while doing so.

You can expect:

A collaborative team culture built on curiosity and respect
Challenging work where your contributions clearly matter
A leadership team that invests in learning and development
The opportunity to work at the intersection of cloud, data, and AI innovation

Ready to Apply?

If this role sounds like a great fit — or even close to one — we’d love to hear from you. We know that no candidate checks every single box, and we’re excited to meet people who bring curiosity, talent, and a desire to build meaningful work together.