Senior Forward Deployed Engineer
Deployed into an owner's programme to build the system that has to hold, and, on other engagements, to establish what is actually true about one somebody else built.
- Engineering
- Senior
- 5–10 years experience
- Full-time
- Remote, with time on site at owner premises
Send us what you've delivered and owned, and one thing you'd want checked on a delivery you've seen. Two paragraphs is enough.
About Pelagram
Who you'd be joining.
Pelagram is an independent technical assurance firm. When an enterprise has business-critical software built — by a contracted firm or its own delivery team — we represent the owner: we define the obligations the delivery must meet — security, data sovereignty, recovery, reliability, performance — and verify, with evidence, that it meets them, through the build and into production.
To make enterprises confident in the software built in their name — by defining the right obligations and proving, with evidence, whether they are met.
- What we do
- Build business-critical software as a delivery partner, and independently assure software built by others.
- Who we act for
- The enterprise that owns the delivery — never the builder, and never both on the same programme.
- How we're set up
- A small practice, remote by default, deployed into the owner's programme rather than run from an office.
- What we publish
- The standard we work to and the constraint that keeps it honest are both public documents, not internal policy.
Life at Pelagram
A culture built around the judgment of the person doing the work.
A small practice, a published standard, and no layer between the person who did the work and the executive who acts on it.
More on how you'd grow here.
- How we care
- We care about our people. It's the driving motivator for how we plan the work, how we staff it, and how we back the person who signs it. Care here is more than benefits and perks — it's being surrounded by people who want to invest in you, and it shows up when a conclusion is unwelcome: the position is Pelagram's, and not yours alone.
- How we work together
- Flexibility is the norm. We're remote by default and on site when the work is there — an evidence session, a go-live, a board sitting — and the interesting decisions stay with the people doing the work rather than moving up a layer.
- How we make a difference
- We encourage our people to close the distance between what a delivery claims and what is true, on the systems people have no choice but to depend on: payments, patient records, claims, freight, public services. A backup nobody has restored is a claim; the work turns it into a fact or a finding.
- How we reimagine the possible
- Just because it worked yesterday doesn't mean it will work today. The Rules are amended by the people doing the work, and evidence that satisfied us last year does not automatically satisfy us now.
- How we act with integrity
- Acting with integrity is part of the everyday conversation here, because it is also the product. The standard is public and is not relaxed when the delivery is our own, and the independence policy binds you personally — no stake in a builder you may assess, and no side work for a party to a delivery you assure.
The role
Senior Forward Deployed Engineer, in detail.
Forward deployed means you work where the system is: inside the owner's programme, in the environment itself, and in the room where the design is argued.
Business-critical software fails in ways a delivery plan never shows: the restore that was never run, the pipeline gate that can be bypassed, the failure path nothing traces. Both halves of Pelagram exist to close that gap.
The seniority isn't decoration. On a build you are making the calls that decide whether the system survives its first bad day. On an assessment you're usually the most technical person in a room where everyone else built what you're examining, and your conclusion has to hold in front of them.
What you'd do
-
Build the system
Architecture, infrastructure and IaC, integrations, data, the release path, and the observability that makes it operable. Then you run it, through go-live and into production, with the pager.
-
Produce the evidence as you go
The restore actually performed, the recovery path exercised against its target, the acceptance criteria met and shown. Part of shipping, not a document written afterwards.
-
Set the obligations
Translate an owner's risk into a measurable standard of care: security, residency, recovery targets, availability and performance, and the criteria that gate go-live.
-
Examine what others built
Witness the restore, read the infrastructure as deployed rather than as documented, pull the traces, reproduce the load test, check the access model against what the console shows.
-
Write conclusions that survive argument
Verdict, evidence, severity, and what the owner should do — in language a board can follow and an engineering team can dispute on the facts.
-
Leave the owner in command
Whether you built it or assessed it, the owner should be able to run it and keep proving it after you've gone.
Experience we require
Senior · 5–10 years
-
Five to ten years building software, with time spent on systems where failure was expensive rather than embarrassing.
-
You've run business-critical software in production and carried the pager for it — operated it, and been present when it broke.
-
Real depth in at least two of: cloud infrastructure and IaC; data platforms and migrations; security engineering; distributed systems, reliability, and performance; release engineering and CI/CD.
-
You've reviewed architecture you didn't design and produced a written opinion someone made a decision on.
-
You've been on at least one side of a recovery exercise, a security review, or a go-live gate that was genuinely at risk.
-
You write. There's a document you produced that a non-engineering executive read and acted on.
-
You can hold a finding under pressure from the people whose work it concerns, and change it when, and only when, the facts change.
Useful, and not a filter
-
SOC 2, ISO 27001, GDPR, or sector-regime exposure.
-
Prior consulting or client-facing delivery.
-
Experience on the vendor side of an outsourced build, which is the single best preparation for reading one.
Independence, and what it asks of you.
Anyone working on an assurance engagement is bound by our independence policy. It carries obligations for individuals, not only for Pelagram. The full policy is published.
-
No stake — equity, options, advisory shares — in a builder or a vendor whose product you may assess.
-
Personal relationships with anyone on a delivery team are declared before the engagement starts, and recorded.
-
No side work for a party involved in a delivery you assure, during or immediately after.
-
One role per delivery. Where Pelagram builds, nobody from Pelagram assures it.
Conditions of the role
- Travel and time on site at owner premises, scoped per engagement.
- You'll move between building and assessing, and the engagement decides which, not you.
- Everything you ship carries its evidence, and that holds on the engagements where the pressure is to move faster.
Compensation
We state the band in the first conversation, before you spend a day on the process.
Our hiring process
- 01 Send us a note
- 02 A conversation
- 03 A working session
- 04 Terms
You'll have a decision, with the reasoning behind it, within ten working days of the working session — either way.
Send us what you've delivered and owned, and one thing you'd want checked on a delivery you've seen. Two paragraphs is enough.