Elevate your engineering expertise to new heights by joining a team of exceptionally talented professionals and position yourself among the top tier in site reliability.

As a Senior Lead Site Reliability Engineer at JPMorganChase within the Chief Technology Office, SRE Enablement, you work with your fellow stakeholders to define non-functional requirements and availability targets for the services in your application and product lines. You will ensure those requirements are accounted for in your products' design and test phases, that your service level indicators are effectively measuring customer experience, and that service level objectives are defined with stakeholders and implemented in production.

What makes this role different from most site reliability engineering roles in the firm: our team does not run a single application. We set the reliability and observability standards that whole platform organisations are held to, and then we get them adopted across engineering teams we do not own. The estate runs to many dozens of applications across several technology towers. You will spend as much time persuading engineers of a standard as implementing one, and the standards you set are enforced at the production gate rather than suggested in a document.

Our core method is the observability assessment, and you will run them end to end. That is one process with four outputs, and you produce all of them: the user journeys as the customer would describe them, the map of which alerts actually cover each step of those journeys, the service level indicators for the service level objectives that matter to the journey rather than to a component, and a failure modes and effects analysis derived from that journey work. Each step surfaces the gaps for the thing it just produced. You then design and run a chaos gameday to test whether the failure modes and effects analysis was right, because such an analysis is a hypothesis until something breaks on purpose.

Job responsibilities

• Creates and delivers high-quality designs, roadmaps, and programme charters alongside the engineering team
• Runs observability assessments end to end: user journeys, alert coverage mapping, journey-level service level indicators and service level objectives, and a design-phase failure modes and effects analysis; then designs and runs the chaos gameday that tests it
• Scores applications against the production-readiness bar and holds the line at the gate — a completed failure modes and effects analysis and a passed gameday are conditions of go-live in our organisation, not recommendations, so your assessment is the thing standing between an application and production
• Acts as a key resource and mentor for technologists in your area seeking advice on technical and business issues, and serves as a culture carrier and site reliability adoption champion for your team
• Collaborates with others to create and implement observability and reliability designs for complex systems that are robust, stable, and do not incur additional toil or technical debt
• Replaces whole-service and component-health measurement with journey-level indicators, working out which alerts and service level indicators an application should actually have and proving the indicator moves when the thing it measures breaks
• Proves an indicator can report a breach before trusting it — querying equations against the metrics store rather than reading them, because plenty of definitions look correct and return nothing
• Uses enterprise-authorized AI capabilities within the work environment to accelerate reliability design and operational decisioning (e.g., incident and post-incident analysis and requirements traceability), validating outputs and handling operational data according to sensitivity and security requirements
• Applies those capabilities at estate scale rather than one service at a time, helping design and run automated screening across the estate and validating what it returns
• Drives evolution and debugging of critical components by understanding application and platform interdependencies and limitations
• Contributes across the breadth of what the team does — which in any given quarter has included reliability assessments and production-readiness reviews, chaos gameday design and delivery, service level objective quality analysis at scale, migrating and rationalising service level objective estates between platforms, defining alerting standards, resiliency and recovery evidence for audit, and building the small internal tools that make all of the above repeatable

Required qualifications, capabilities, and skills

• Formal training or certification on site reliability engineering concepts and advanced applied experience
• Brings an advanced understanding of site reliability culture and principles and a track record of demonstrating how to implement site reliability within an application or platform
• Advanced knowledge and experience in observability such as white and black box monitoring, service level objectives, alerting, and telemetry collection
• Hands-on fluency writing and debugging queries against a time-series metrics store — PromQL or equivalent — as a daily activity rather than an occasional one
• Practical experience defining service level indicators and service level objectives from user journeys, and the judgement to distinguish a customer-facing indicator from a component health check
• Demonstrated experience using enterprise-authorized AI capabilities within the work environment to improve reliability engineering workflows, with strong validation habits and awareness of data sensitivity
• Ability to set team practices for safe AI usage in operations (e.g., review and approval expectations and escalation paths) while maintaining resiliency, security, and auditability outcomes
• Advanced knowledge of software applications and technical processes with considerable depth in one or more technical disciplines
• Strong communication skills and a desire to mentor and educate others on site reliability engineering principles and practices
• The ability to communicate findings an engineering team may not want to hear — with evidence — while maintaining productive working relationships

Preferred qualifications, capabilities, and skills

• Experience with failure modes and effects analysisor an equivalent structured failure-analysis method, and the ability to run the exercise with an application team rather than write it for them
• Experience designing and running chaos or fault-injection experiments, with tooling such as Gremlin or AWS Fault Injection Simulator, and specifically designing experiments to test whether anyone notices — not only whether something breaks
• Hands-on experience with Dynatrace, Prometheus or Cortex-based metrics platforms, and Grafana
• Experience with error budgets as an input to delivery decisions, including what happens when one is exhausted
• Familiarity with resiliency and recovery governance: recovery time and recovery point objectives, application recovery plans, and the evidence an internal audit expects to see
• Experience working across lines of business or legal entities where you have influence but no direct authority, and comfort operating in a globally distributed team with the autonomy that implies