Senior Lead Engineer, Platform Engineering and Cloud Resilience

Job Description

Job Description

About Sapience AI

Sapience AI is the collective intelligence platform for professional communities. We sit above the CRMs, AMS platforms, and knowledge bases that organizations already run, and we turn the expertise scattered across them into something every member can search, act on, and share.

The intelligence a community needs is already inside it. Most organizations just cannot reach it. Knowledge lives in silos, in legacy systems, in the heads of a few experts, and in fragmented records no one can connect. We change that.

Our work is grounded in four commitments: technology elevates people and never replaces them, the best expertise is already inside the community, everything is built on trust, and every deployment is purpose-driven for the organization it serves.

Let's achieve more, together.

Where this role sits

Every customer we serve runs in its own isolated environment on Google Cloud, provisioned by Terraform and operated to an enterprise zero trust security standard. The organizations we serve range from small professional communities to very large ones, and the platform has to carry the largest of them across more than one region.

Today the platform is run by our Cloud Architect with two platform engineers (DevOps and platform engineering) who carry the day-to-day work across time zones. As the customer base grows, cloud architecture and cloud operations each need an owner of their own. This role takes operations: This position owns how changes reach production and how the cloud estate is run day to day, and this position leads the existing platform engineers. This position also supports, and is a resource to, the Sapience AI | Senior Lead Engineer, Platform Engineering and Cloud Resilience Page 1 support staff, the help desk, and the knowledge base behind it — so that it has an owner who is not this role and not the Cloud Architect. The Cloud Architect keeps cloud architecture, our Security Architect keeps security, and this position supports and assists the Cloud Architect in building the next generation.

This is an onshore lead. This position leads the platform engineers on forward-thinking endeavors distributed across time zones. The primary responsibility of this role is to lead the platform engineers, inspire them, assist them in their professional development while supporting a 24/7/365 platform.

Why this role exists

A platform that provides isolated environments for every customer needs an operations owner with the depth to run it and the judgment to say when it is not ready. Architecture and operations are different disciplines; as more customers land, each deserves a lead whose attention is not split. This role is the operations lead, with two platform engineers already in place to lead.

This role exists so that operations has an owner who came up through support and has run production at scale, so that the Cloud Architect's time goes to the next tier rather than today's deploy, and so that the support function gets built by someone who has built one before — without that person becoming the support desk.

Ownership

This position holds five areas of responsibility, and this role assists on a sixth. Each of the five is this role's to run and improve.

1. Platform operations and the path to production. Own the merge-to-production path for the platform and the shared services it depends on: pull request review, the plan-and-apply discipline, deployment dispatches to customer environments, rollback. Own the automated quality and security gates on that path and keep them fast enough that nobody wants to route around them. This position is the merge authority for platform repositories.

2. Cloud operations. Own the day-two running of the Google Cloud estate: project and environment lifecycle, IAM and workload identity hygiene, quotas and reservations, cost visibility, certificate and key rotation, patching and version pins, drift. Build NOC-grade dashboards of the platform, so that the health of every customer environment, the path to production, and the cloud estate can be read from one place at a glance. Own the audit trail, so that who holds what access and what is exposed are answerable questions.

3. Terraform and provisioning. Operate, review, and extend the Terraform that provisions every environment: module conventions, state layout, version pins, CI plan-gating, drift detection. The standard exists; this role keeps it enforced in CI, reviewing what other teams author against it, and this role is expected to improve upon it.

4. On-call and operational readiness. Design and run the on-call rotation and take a place in it. Own SLOs, runbooks that have been exercised, incident response and postmortems, and the readiness Sapience AI | Senior Lead Engineer, Platform Engineering and Cloud Resilience Page 2 gate self-operated stateful infrastructure must pass before release — and hold that gate when schedule pressure argues otherwise. Grow the platform engineers into people who can hold the rotation.

5. Architecture partnership. Be the operator's voice in cloud architecture: sizing and placement for new customer tiers, regional expansion, the data tier, cost. This position will not own the architecture, but rather every design will be built with input from this role and this position will have a say when it will not operate.

6. Help desk, support staff, and knowledge base — assist, not own. Support the intake and triage model, the response targets, interviewing for the first support hires, and the responsibility for runbook creation and organization knowledge-base structure the engineers and support staff will work from. You bring the pattern from having been in a support role before; the day-to-day queue is owned by the support lead once one exists.

AI-augmented ways of working

AI is embedded in how this platform is run, not added at the end. The standard is human in partnership: AI accelerates the work, this role owns the interpretation and the call. The role will inherit AI-assisted planning, triage, and review tooling and be expected to make it better.

What this role is not

– This partners with cloud architecture and security but does not belong to either. Operating what is produced; the Cloud Architect owns the design and the Security Architect owns the security posture. 

– This is not a takeover of other teams' application code. They keep authoring their services; they land them on this platform against the standard.

– This is not vector data design or graph modeling. This role operates the data substrate; its design is owned by the data team and the DBAs.

– This is not the help desk. This role helps build it and stays hands-on in the platform every day; once a support lead is in place, the queue is theirs.

What success looks like

– The Cloud Architect is out of the deploy path. Merges, applies, and dispatches run on this role's authority, with the audit trail to show it.

– The pager has an owner and a rotation. On-call covers every hour with named people, runbooks have been exercised, and incidents produce postmortems that change something.

– A support function exists and has an owner. This position will help design its intake, targets, and knowledge base, the first support hire is in place, and the repeat requests have become automation or self-service.

– The engineers this position leads hold the rotation. They run their shifts from task packets they can execute without this role, and at least one of them is on the path to lead.

– The Terraform standard holds. Teams author against it, CI enforces it, drift is caught by a job, not by an incident.

– New tiers land without a redesign. When the next customer at the top of the size range arrives, placement and sizing come from the model this position helped build.

Who you are

Experience coming up through support or operations and never losing the instinct for what it takes to keep people unblocked. Somewhere along the way you learned to read code, review a pull request, and write the automation that made the queue shorter, and you have run production on a public cloud at a scale where mistakes are visible. You have built the team that kept it running, and you would rather make a risk legible than say no.

Required qualifications

These are the qualifications we screen against. 

– Ten or more years operating production systems on a major public cloud, or direct operational ownership of a platform that sustained more than one million members or customers. 

– A support or operations background: Must have worked in, and then run, a technical support, help desk, NOC, or operations function — set its intake, its targets, and its on-call — and been accountable for its numbers. That is the pattern this position will help us build, not the desk this role will sit at.

– Google Cloud in production, at depth. GKE, Cloud IAM and workload identity, VPC networking, Cloud KMS, Cloud SQL or AlloyDB operations. This is a GCP platform; GCP depth is required, not preferred.

– CI/CD pipelines as a daily tool: Must have owned a merge-to-production path, its gates, and its rollback, on GitHub Actions or comparable.

– Terraform in production: must know module conventions, remote state, plan-gating in CI, drift. You can review what others write and improve what exists.

– Enough software engineering to be trusted with it: Must be able to read code, review pull requests with substance, write Python, and understand how software is designed, tested, and shipped.

– Has built or led an on-call program and held a pager in a rotation cycle.

– Has led or grown engineers — a support or operations team, or junior engineers brought to independence.

– Clear written communication to specialists and non-specialists: task packets, runbooks, postmortems, status.

– Authorized to work in the United States without sponsorship; able to work U.S. Pacific business hours and cover an on-call rotation.

Preferred qualifications

– Experience operating customer-isolated, single-tenant-per-customer environments at scale.

– Private networking, service perimeters, and software supply-chain controls on Google Cloud.

– Multi-region database operations on Cloud SQL or AlloyDB. ITIL or comparable service-management practice, applied to an engineering audience rather than imposed on it.

– Practical understanding of AI agents and agentic workflows in operations, including where they fail.

– Experience leading distributed or follow-the-sun teams across time zones.

– A degree in computer science or a related technical field is a plus, never a requirement.

How you work

The platform team lives by one motto: automate a secure world. Every item below is a way of doing that.

– Keep people unblocked. Know what a good support function looks like from the inside, and build the structure that lets someone else run it. 

– Hold a readiness line under delivery pressure, and make the risk legible instead of only saying no.

– Turn repeat requests into automation and make the automated, secure path the easy one.

– Measure before you claim, and prefer signal from systems of record over self-report.

– Write things down: task packets a junior engineer can run, runbooks that have been exercised, postmortems that name the fix. 

– Grow people on purpose. Hand work down with enough context to succeed, and review it in a way that teaches and educates. 

– Treat learning as the job: ramp fast, ask early, and change your mind when the evidence moves.

– Assume the best in your partners, share openly, and treat trust as something you build every day.

Services and tools

We do not screen on certifications. The platform runs on:

– Google Cloud: GKE, Cloud IAM, VPC networking, Cloud KMS, Secret Manager, Cloud SQL and AlloyDB, Cloud Run, Artifact Registry, Cloud Build. 

– Terraform, GitHub Actions, Self-Hosted Runners, Helm, Kustomize.

– Python, OpenTelemetry.

– Ticketing and chat tooling for intake and tracking; AI-assisted planning, triage, and review tooling.

Cross-functional partners

Work with every engineering team that ships on the platform; the relationship is a standard rather than a service desk. Partner with our Security Architect on identity, keys, perimeters, and the audit trail behind them. Partner with the DBAs on the data tier, operating it while they own its design. Lead the distributed platform engineers and report to the Cloud Architect, with whom you share the cloud architecture.

We review every application, and we encourage you to apply even if you do not match every line above. Research shows that talented people, especially those from underrepresented communities, often hold back when they do not meet every qualification. If that is the only thing holding you back, apply anyway.

Sapience AI is an equal opportunity employer. We are committed to a workplace where everyone, regardless of background, has a voice in building what comes next.

Base Salary: $160,000 - $180,000 + early equity

Generous health and wellness benefits

Sapience AI is an equal opportunity employer. We do not discriminate on the basis of gender, race or color, ethnicity or national origin, age, disability, religion, sexual orientation, gender identity or expression, veteran status, or any other protected characteristic. If you need an accommodation to complete our application process, let your recruiter know.