Staff Engineer

The Savings & Investments domain is growing fast - from five clients in production to eight in 2026, including our first Tier 1 bank. The teams are capable and stable. What is missing is consistent, deep technical ownership at the architectural level: a clear picture of where the domain is today, where it needs to go, and a credible plan to get there without disrupting production.
 
The domain runs across two engineering teams: Savings & Payments and Investments, Pensions & Core. Both have strong engineering managers. This role is not a management role - it is the technical counterpart to the director, responsible for domain architecture, technical quality, and the depth of banking knowledge that complex clients increasingly demand.

What You'll Own

• Domain architecture

You maintain a clear, honest, living picture of the S&I technical landscape - services, data flows, integration points, dependencies, and risks. Not in a glossy diagram that no one reads. In working documentation that engineers actually use, backed by ADRs and tested against the code.

• Modernisation roadmap

The OFS savings and investments stack carries technical debt and has not evolved at the same pace as the lending platform. You will identify the highest-leverage improvements, sequence them pragmatically, and drive them through - working with and through the engineering teams, not around them.

• API completeness

Ohpen's strategic direction is API-first, with every capability exposed through well-designed, versioned APIs ready for agentic AI and large-scale client self-service. You will assess current API coverage in S&I, identify gaps, and own the plan to close them.

• Technical depth on client projects

For complex clients - particularly Tier 1 banks - you will be the technical counterpart in design conversations. You understand the domain well enough to say no credibly, to propose alternatives, and to make commitments you can actually deliver on.

• Observability and production quality

Incidents in S&I are currently detected too late. You will ensure the domain's services are properly instrumented -  OTAM/OpenTelemetry, meaningful alerting, clear runbooks — so the team knows about problems before clients do.

• Cross-team architectural coherence

Savings/Payments and Investments/Pensions operate largely independently today. You will provide the connecting thread: shared patterns, consistent API design, common data models where it makes sense, and early identification of divergence before it becomes expensive.


What Good Looks Like
In your first 90 days:
You have a documented, honest technical inventory of the S&I domain. You've done a code review in both team areas. You've sat with clients. You know where the bodies are buried and you've told the Engineering Director directly.

At six months:
The domain has a technical roadmap that is tracked and visible. API coverage is measurably improving. The teams trust your technical judgement. Client escalations have a clear technical owner.

At one year:
S&I is no longer perceived as the least modern domain in Ohpen engineering. Incidents are down. Onboarding new clients feels like a repeatable process rather than a bespoke scramble.

Reporting & Working Relationships
You report to the Engineering Director for S&I. You work closely with the Engineering Managers for Savings/Payments and Investments/Pensions, and with the central Architecture & Technology team. This is an individual contributor role - you do not manage people, but you are expected to raise the technical bar across the teams you work with.

Hard requirements 

• You have deep, firsthand knowledge of financial services software in the savings, investments, or pensions domain. Not adjacent. Not theoretical. You have built or materially evolved systems that hold client money, process fund transactions, or administer pension entitlements.
• You write code at a level that earns respect from senior engineers. C#/.NET is the primary S&I stack. You don't need to be the fastest developer in the room, but you need to be able to read a complex service, spot the problem, and propose a fix the team will actually consider taking.
• You have operated as a technical authority on live, regulated systems - not greenfield projects. You understand what it costs to be wrong in production for a bank, and your architecture decisions reflect that.
• You communicate in writing with precision and economy. Architecture decisions get written down. Trade-offs are documented. Engineers can read your ADRs and understand why, not just what.

 
Strong differentiators

• Multi-tenant SaaS architecture in financial services
• AWS-native platform experience (ECS, Lambda, RDS, DocumentDB, Terraform, OpenTelemetry)
• Pension administration - specifically Dutch pension structures (DC, defined benefit transitions, lifecycle investing)
• Experience working directly with DNB- or FCA-regulated institutions
• Track record of closing the gap between what the platform can do and what the API exposes