About the role

SteelEye, now merged with FundApps, provides communications, trade and order surveillance to some of the world’s largest financial institutions.

As a Principal Engineer you will set technical direction across the Surveillance estate and lead the Staff Engineers who own its hardest problems. Delivery sits with the teams building our products. What sits with you is whether the whole thing holds together: whether we know production is working, whether the architecture is coherent, whether the security model makes sense end to end, whether the standard of engineering craft is rising, and whether our most senior engineers are getting better.

Our clients expect strong technical assurance and our platform runs across AWS and Azure. The decisions you influence determine how safely teams can make changes, how quickly we can activate clients and how efficiently we can operate.

This is a Principal role with real team leadership attached, and it stays technical. You will stay hands on: reviewing architecture, reading and writing code, and joining incidents. The role moves between deep technical detail and a 10,000 foot view, often on the same day.

What You'll Be Working On

Reliability, observability and operational correctness

The priority is not simply whether the platform is up, but whether it is doing its job: client feeds arrive completely, surveillance runs against the right window and expected alerts fire.

You and the team will establish patterns for correctness monitoring, escalation, incident response and disaster recovery, allowing product teams to define their own alerts, service levels and response playbooks

Software craftsmanship and change safety

Alongside correctness, change safety is our other top engineering priority: the ability to change the platform frequently, in small increments, with confidence that nothing has quietly broken. That means tests that earn trust, reviews that catch design problems rather than typos, deployment that is boring, and the discipline to keep it that way under pressure.

You will own the standard of engineering craft across Surveillance: what good looks like, how it is taught, and whether it holds when nobody is watching.

Architectural coherence

Each team will make sensible local decisions. Your job is to make sure they add up: that we are not solving the same problem three ways, that the interfaces between domains are deliberate, and that the estate can still be reasoned about in two years.

You will set the technical direction others plan against, including how client environments are managed across their lifecycle and how software reaches production through GitOps and infrastructure as code.

Security architecture

Not governance, which sits with our Security team, but the engineering picture: how client environment isolation actually works, where the boundaries are, how privileged access is granted and removed, and which risks we have consciously accepted. This includes workload identity, SCIM 2.0 and enterprise identity integration for client provisioning.

Individual teams will secure their own patch. Somebody has to own how it fits together.

Growing the Staff Engineers

You will manage our Staff Engineers. That means growing their scope rather than directing their work: helping them take on problems larger than a single team, raising the standard of design review and technical writing, and building a bench that does not route through you.

Cost and unit economics

Cloud cost grows as we add new clients, so it needs to be an engineering concern.

You will work with the teams building our products and our FinOps engineering effort to improve optimisation, capacity strategy and client-level cost visibility. Cost is a shared responsibility, not something owned in isolation.

Enterprise client assurance and commercial support

You will help turn technical assurance around areas such as environment segregation, promotion controls, change management, data residency and disaster recovery into repeatable capabilities rather than bespoke exercises.

You will also review deals for technical risk and represent our architecture with client CISOs and technical stakeholders.

Two boundaries

Security policy, SOC 2 and ISO 27001 certification, the security risk register and the compliance programme are owned by our Security team.

You own the engineering controls and technical evidence they depend on, working closely with Security rather than running a compliance function.

Delivery is owned by the teams building our products. You own whether it coheres. Neither boundary makes you an approval gate.

What success looks like

The technical direction is already established. You will inherit goals in flight and formulate plans to deliver the desired outcomes.

We want someone who can get close to the estate and team quickly, build on what is working and move at pace rather than returning to first principles.

Success means teams can move safely and faster because of the platform and the standards, with less operational toil and a growing proportion of engineering time spent on elective work rather than keeping the lights on.

That means:

• Client onboarding becomes increasingly automated end to end.

• Observability lets teams answer common operational questions without elevated production access.

• Change is frequent, small and reversible, and incidents do not scale with deployment frequency.

• Product teams have better visibility into client-level cost and margin.

• Each area has clear ownership and no single person becomes a dependency, including you.

• Our Staff Engineers are operating at greater scope than when you arrived.

What You'll Bring To The Team

You have depth somewhere real, and it does not have to be ours. We are not looking for a specialist in one layer. You might have built your reputation in distributed systems, data platforms, application and product engineering, machine learning, or platform and infrastructure. What matters is that somewhere in the stack you went deep enough to earn the respect of very good engineers, and that you can bring that judgement to areas where you are not the expert.

You have a track record of hands-on, material impact. Not architecture decks, and not delivery you delegated. Things you personally designed, built, or unblocked by getting into the detail, where the outcome mattered commercially and you can explain both the mechanism and the tradeoffs you accepted.

You have enough breadth to challenge a specialist. You will be accountable for areas where someone on your team knows more than you do. You should be able to ask the question that exposes the weak assumption, and to recognise when you are being told what you want to hear.

You have led senior engineers and know how to give strong people meaningful ownership rather than routing decisions through yourself. You can name engineers whose trajectory changed because of you.

You have raised the engineering standard of teams beyond your own. You have opinions about testing, review and change safety that you have actually implemented, and you can tell the difference between a team that has adopted the practices and one that has adopted the vocabulary.

You are comfortable working across distributed engineering centres, and you know that raising craft at distance happens through pairing and review rather than through standards documents.

You treat developer productivity as an engineering outcome rather than a side effect. You have measurably improved how quickly other engineers ship, through paved paths, faster feedback and removing the need to understand internals in order to work safely.

You understand security as engineering controls rather than process, including identity and access management, privileged access, workload identity and client environment isolation. You are comfortable working in environments where enterprise customers expect technical assurance and can hold your own with a client CISO.

You are equally comfortable moving between architecture, code, incidents, client conversations and commercial considerations.

We are particularly interested in people who came up through engineering and infrastructure before moving into platform and security leadership.

Our estate, for context

AWS and Azure · Kubernetes and EKS · Terraform · Helm · GitOps · CI/CD · Elasticsearch · Kafka · PostgreSQL · ClickHouse · Python services · observability and Prometheus · multi-fleet, multi-cell client environment architecture · cloud and Kubernetes security

Nobody knows all of it well. You should recognise most of it and be genuinely deep in some of it.

How you work

You think in systems, and you treat reliability, security and developer productivity as the same engineering problem rather than three competing ones. You prefer automated guardrails to manual approvals, paved paths to documentation and evidence to assertion.

You are credible in a board conversation and credible in a code review, and you do not treat those as different people.