Sr Staff Software Engineer

Role summary

The Senior Staff Software Engineer (IC5) on HR Service Delivery sets and owns the technical direction for model-driven capability across the HR domain and the surfaces adjacent domains build on top of it. The work is agentic and conversational experiences that interpret an employee's, manager's, or HR agent's intent, reason over profile, case, catalog, policy, and knowledge context, invoke tools, and act on the user's behalf — but the unit of ownership is the architecture, the standards, and the evaluation infrastructure that let multiple teams ship those experiences safely, not a set of features.

This is not a machine learning or AI research role; the engineer does not train foundation models.

It is also distinct from traditional staff-level full-stack engineering, where systems follow deterministic logic rather than selecting execution paths at runtime.

Two consequences shape the work.

First, the most important logic often lives in natural language — instructions, prompts, tool descriptions, guardrails, escalation rules — which must be engineered, versioned, and reviewed with the same discipline as code, and which needs an architecture once more than one team is authoring it.

Second, because behavior is probabilistic, correctness is established by measuring behavior at scale rather than by asserting fixed outputs, which makes evaluation a platform investment rather than a per-feature activity.

HR sharpens both points along two independent axes.

Accuracy.

An agent answering on payroll, benefits, leave, or a lifecycle event touches statutory entitlement, jurisdiction-specific policy, and an employee's pay.

A confidently wrong output is not a bad answer; it is a missed enrollment window or an incorrect leave balance acted on in good faith.

Audience.

HR data is among the most sensitive on the platform, and correctness of content is not sufficient.

An answer grounded in a record or knowledge article the requestor is not entitled to read is a data exposure even when every fact in it is true, and manager-scope and employee-scope views of the same question have different correct answers.

Enforcement belongs in the retrieval and tool layer, not in a request to the model, and at this level you own that being true by construction across every team building in the domain.

The distinguishing expectation at IC5 is that the hardest problems arrive unframed.

You decide what the domain should do about them, commit the organization to an approach, and are accountable for that approach across releases — including for the decisions that turn out wrong.

What you do Set the AI architecture for the domain

Own the architecture of model-driven capability across the employee lifecycle: how agents are decomposed and composed, where reasoning happens, how context is assembled and bounded, how tools are exposed and described, and how autonomy is delegated and revoked.

Establish the reference patterns other teams build against, and the boundaries between what is a shared platform concern and what each product area owns.

Make the calls with multi-release consequences — model selection and migration, orchestration approach, build-versus-adopt, and the cost, latency, and quality tradeoffs behind each — and own the outcome.

Define where autonomy goes, and where it does not

Decide, as a matter of domain policy rather than per-feature design, which HR actions an agent may take, which require a human decision point, and which no agent should attempt.

Anything that changes pay, employment status, or a restricted record, and anything touching employee relations or investigation, needs a human in the path by construction.

Then build the mechanisms that make those constraints structural and hard to violate accidentally, so that a team shipping a new capability inherits the boundary instead of re-deriving it.

You hold the authority to refuse a shipping decision on these grounds, and are expected to use it.

Own the shared instruction and tool-description architecture

HRSD ships as product: customers configure, extend, and override the instruction and tool surface on their own instances, and adjacent domains build against it.

Treat it as a versioned contract with upgrade-safe extension points, deprecation paths, and compatibility guarantees.

Own how that surface is structured, reviewed, and evolved across teams — including the authoring standards, the review bar, and the regression coverage that make natural-language logic maintainable at organizational scale rather than only within one codebase.

Build the evaluation infrastructure the organization ships against

Own evaluation as leverage: the golden datasets, multi-turn suites, judge calibration, CI gates, and drift detection that let many teams change behavior safely and quickly.

Extend coverage to the HR-specific failure classes — access-boundary violations in retrieval and citation, cross-scope leakage, jurisdictional and policy-variant correctness — and keep it meaningful across the range of customer configurations rather than a single reference environment.

Define the resolution, containment, and quality metrics the domain is measured on, be the person who can say whether they are instrumented correctly, and raise the standard of evidence required before a behavioral change ships.

Frame problems the organization has not yet framed

Identify the risks, gaps, and structural weaknesses in model-driven behavior that no one has articulated yet, quantify them, and drive them to a decision.

This includes the failure classes that only appear at scale or in specific customer environments, the second-order consequences of a model or platform change, and the places where current practice will not survive the next generation of capability.

Bring these to product and engineering leadership with the analysis and the recommendation, not the problem alone.

Direct AI coding agents, and set how the organization does

Convert ambiguous problem statements into testable specifications with explicit scope, constraints, non-goals, and acceptance criteria; decompose work into agent-sized tasks; and supervise parallel workstreams.

Beyond your own delivery, define what accountable agent-assisted engineering looks like for the domain — specification standards, review expectations, verification harnesses — and hold the line on it.

You own the result regardless of what produced it, and you own the norm.

Own production quality, safety, and reliability across the domain

Own the observability and safety posture for agentic behavior: conversation quality, containment, hallucination rate, tool-selection error, unsafe or unauthorized action, and the paths where user-supplied content — case notes, inbound email, attachments, authored knowledge — enters agent context as an injection vector. Because HR conversation content is itself restricted, design diagnosis that works without exposing what was said. Lead root-cause analysis on the incidents no one else can resolve, hold the distinction between a genuine model failure and a platform or configuration failure presenting as one, and close the loop from production failure back into specification and evaluation.

Deliver hands-on where it matters

Stay in the code on the load-bearing parts: the hard integration, the risky migration, the prototype that settles an architectural argument, the incident nobody else can unblock.

Delivery at this level is selective and deliberate rather than continuous, and the expectation is that your hands-on work resolves uncertainty for others rather than absorbing feature scope.

Influence beyond the team

Represent the domain's technical position to engineering and product leadership, to customers, and to partner organizations.

Communicate capability and risk to non-engineering audiences without flattening either.

Build alignment across teams that do not report to you and whose priorities compete.

Grow staff-level engineers, raise the bar in technical review and hiring, and make the domain's practices around instruction authoring, evaluation, and accountable agent use durable enough to outlast your involvement in any one project.