Staff Software Engineer - Services Platform

Mercury
San Francisco +1 more
Remote

Who this role is best for

Geared toward infrastructure engineers with strong Kubernetes and service platform experience comfortable with defining and standardizing cross-team processes. The role is based in San Francisco, New York, or Portland, or offers remote options within the U.S. or Canada.

Best fit for

  • Candidates with experience in service-to-service authentication and distributed systems infrastructure
    — “Have designed or materially owned service-to-service authentication, workload identity, service discovery, service mesh, or related distributed-systems infrastructure.”
  • Individuals who can shape infrastructure thinking and mentor others in a growing organization
    — “Mentor engineers and shape infrastructure thinking beyond the systems you directly own.”
  • Engineers who prioritize self-service tooling and platform usability for product teams
    — “Make observability self-service so product engineers can understand and debug their systems without routing every question through Infrastructure.”

Things to consider

  • The role demands a balance between technical depth and organizational influence, not just coding skills
    — “The hardest problems won’t be solved by writing code. You’ll need excellent judgment about what is worth standardizing, what should stay flexible, how quickly we can move, and how to bring a large engineering organization along with you.”
  • Adoption and ergonomics are as critical as technical architecture in this role
    — “Think of internal platforms as products. Adoption, ergonomics, defaults, documentation, and escape hatches matter alongside technical architecture.”

How to stand out

  • Highlight past platform design contributions that improved team adoption and reduced operational complexity
    — “Experience building an internal developer platform or service infrastructure at a scaled engineering organization would be particularly useful”
  • Showcase examples of self-service tooling you built for application engineers
    — “Have experience building self-service observability or operational tooling for application engineers.”
  • Emphasize your ability to make technical tradeoffs and communicate them clearly to engineering teams
    — “Communicate technical tradeoffs clearly enough that engineers understand both the decision and the reasoning behind it.”
Pace · SteadyCollaboration · HighAutonomy · HighDecision Impact · Company

Derived from job-description analysis by Serendipath's career intelligence engine.

What success looks like

  • define and build the platform for deploying and operating services
  • own the strategy for service ecosystem
  • create a paved deployment path
  • evolve service runtime architecture
  • make observability self-service
Typical background
deep experience operating Kubernetes in productiondesigned or materially owned service-to-service authenticationexperience building self-service observability

Skills & requirements

Required

KubernetesService-to-service AuthenticationService DiscoveryObservabilityDeployment ArchitectureFailure ModesMigrations

Preferred

Service MeshSelf-service ObservabilityOperational ToolingPlatform Design

Stack & domain

KubernetesService-to-service AuthenticationWorkload IdentityService DiscoveryService MeshSelf-service ObservabilityOperational ToolingFinancial RegulationsInternal Platforms As ProductsExcellent JudgmentStrong Opinions About Platform DesignAbility To Bring A Large Engineering Organization AlongNullSoftware EngineeringCloud InfrastructureDevOpsFintech

About the role

Original posting from Mercury via Greenhouse

At its height, the Venetian Arsenal could produce ships at a speed that were mostly unmatched in its era. Its advantage was not simply that its craftspeople worked faster. Venice standardized the pieces around them. Parts, processes, and responsibilities became reusable enough that shipbuilding became stamp and repeat, not creating from scratch every time.

Mercury's services ecosystem is reaching a similar transition.

As more of Mercury moves beyond our core Haskell monolith, product teams are increasingly building and operating independent services. That gives teams more flexibility, but it also creates a new class of infrastructure problems. How should services authenticate to each other? How should they be discovered? What does a safe deployment look like? How does an engineer understand whether their service is healthy? And how do we answer those questions once, rather than asking every product team to build its own version?

We’re looking for a Staff Infrastructure Engineer to become a technical owner for Mercury’s services platform.

You’ll help define the paved road for building and running services at Mercury. This is a deeply technical role, but the hardest problems won’t be solved by writing code. You’ll need excellent judgment about what is worth standardizing, what should stay flexible, how quickly we can move, and how to bring a large engineering organization along with you. We see this role as the trailblazer for several more engineers to follow so the foundations and relationships you build across the org will pay off for those who come after!

In this role, you’ll:

Define and build the platform Mercury engineers use to deploy, operate, and evolve services.

Own the strategy for service ecosystem at Mercury including identity, authentication, discovery and communication

Work with product stakeholders and Release Engineering to create a paved deployment path with strong defaults for rollouts, rollbacks, configuration, secrets, and operational safety.

Help evolve Mercury’s service runtime architecture, including our use of Kubernetes, while keeping existing services healthy through the transition.

Make observability self-service so product engineers can understand and debug their systems without routing every question through Infrastructure.

Partner closely with Release Engineering, Security, and product engineering teams to create infrastructure that is compliant with financial regulations and useful enough that teams actively want to adopt it.

Find the highest-leverage gaps in our services ecosystem and ship pragmatic improvements instead of waiting for a perfect future architecture.

Establish patterns that let Mercury support many more services without multiplying operational complexity at the same rate.

Mentor engineers and shape infrastructure thinking beyond the systems you directly own.

You should:

Have deep experience operating Kubernetes in production and strong instincts around deployment architecture, failure modes, and migrations.

Have designed or materially owned service-to-service authentication, workload identity, service discovery, service mesh, or related distributed-systems infrastructure.

Have experience building self-service observability or operational tooling for application engineers.

Have strong opinions about platform design, paired with the judgment to know when not to build something.

Think of internal platforms as products. Adoption, ergonomics, defaults, documentation, and escape hatches matter alongside technical architecture.

Be able to gain alignment across teams with different goals and perspectives without requiring unanimity or creating unnecessary friction.

Communicate technical tradeoffs clearly enough that engineers understand both the decision and the reasoning behind it.

Enjoy operating at the boundary between deep technical work and broad organizational leverage.

Experience building an internal developer platform or service infrastructure at a scaled engineering organization would be particularly useful, but we care more about the systems you built, the decisions you made, and whether other teams successfully adopted them than the logo on your résumé.

Mercury’s infrastructure is evolving rapidly every day. The service ecosystem is large enough that these problems are real, but young enough that a great engineer can still shape the fundamentals.

If you want to build the standards that make the next fifty services feel far less exciting to operate than the first ten, we’d love to talk.

*Mercury is a fintech company, not an FDIC-insured bank. Banking services provided through Choice Financial Group and Column N.A., Members FDIC.

Mercury values diversity & belonging and is proud to be an Equal Employment Opportunity employer. All individuals seeking employment at Mercury are considered without regard to race, color, religion, national origin, age, sex, marital status, ancestry, physical or mental disability, veteran status, gender identity, sexual orientation, or any other legally protected characteristic. We are committed to providing reasonable accommodations throughout the recruitment process for applicants with disabilities or special needs. If you need assistance, or an accommodation, please let your recruiter know once you are contacted about a role.

#LI-ME1

Total Rewards

The total rewards package at Mercury includes base salary, equity (stock options/RSUs), and benefits.

Our salary and equity ranges are highly competitive within the SaaS and fintech industry and are updated regularly using the most reliable compensation survey data for our industry. New hire offers are made based on a candidate’s experience, expertise, geographic location, and internal pay equity relative to peers.

Our target new hire base salary ranges for this role are the following:

US employees (any location):$239,000—$298,800 USDCanadian employees (any location):$225,900—$282,400 USD

Source: Mercury careers (Greenhouse)

Similar roles

More roles at Mercury