Write it down.
Decisions that only exist in a meeting are decisions that get made again in six months. Designs, trade-offs and the reasons for a rejection are written before the work starts and stay readable afterwards.
Careers
Small teams, long tenure, and software people keep for a decade.
4,200 people across six offices, building the applications an organisation runs its operations on. Ten roles are open. Every posting carries its salary band, because withholding it only ever benefits us.
- People
- 4,200
- Median tenure
- 5.8 years
- Open roles
- 10
- Offices
- 6
What it is like
Long-lived systems, and the people who wrote them still here.
Most of what we build is intended to run for fifteen years inside an organisation that cannot easily change it. That shapes the work more than anything else: careful interfaces, migrations planned before features, and a strong bias against clever solutions to problems that were not going to hurt anyone.
It also means the person who designed the entitlement model in 2015 is two desks away and can tell you why it is the shape it is. Very little institutional knowledge here is archaeology.
The trade is that this is not a place to ship something in a weekend and see what happens. Changes to the platform are reviewed, staged and reversible, and that discipline is not optional for anyone.
How we work
What is actually expected of you.
Six statements that get quoted in code review often enough that they are worth writing on a page.
Own the whole thing.
The person who builds a component operates it. There is no separate team to hand a defect to at five o'clock, which turns out to be the most reliable pressure on quality we have found.
Say the difficult thing early.
A slipping date, a design that will not hold, a customer commitment nobody can meet, all of these are cheap in week two and expensive in week ten. Raising them is expected rather than tolerated.
Fix the cause.
Every incident above severity three produces a change to a system, not a change to a runbook. Where the honest cause is a process or a staffing decision, that is what the report says.
Small teams, long tenure.
Teams are six to nine people and they stay together. Median tenure is 5.8 years, which is the single number we watch most closely, because a platform this interconnected is mostly held in people's heads.
Boring where it counts.
Storage, authentication and billing change slowly and deliberately. Nobody gets promoted here for rewriting something that worked.
Benefits
What comes with the job.
The same package everywhere, adjusted only where local law or the cost of medical cover makes that impossible. Nothing here is discretionary or conditional on performance.
Pay
- Salary bands published internally and on every job posting
- Reviewed annually against market data, with the data shown to you
- No individual negotiation on the band: the same role pays the same
- Share options for every permanent employee, vesting over four years
Time
- Thirty days' holiday plus public holidays, and we check that you take it
- A four-day week in August, at full pay, across the whole company
- Sabbatical of two months, fully paid, after five years
- Genuine flexibility on hours; core overlap is four hours a day
Health and family
- Private medical cover including mental health, from the first day
- Twenty-six weeks' parental leave at full pay for any parent
- Fertility and menopause support through an external provider
- Pension contribution of 9 per cent, not conditional on matching
Work
- Remote, hybrid or office. Decided by the team, not by policy
- A budget for the machine you want, replaced on a three-year cycle
- £2,400 a year for training, conferences or a course, no approval needed
- Two paid days a quarter for open-source or community work
Open roles
What we are hiring for.
Ten positions, each with the band, the team and the location stated. If none of them fit but you think you should work here, write to careers@cedxsystems.com and say why.
10 open roles across the company.
Entitlements decide what every one of the 132 applications is allowed to show a given person. The model is nine years old, correct, and slower than it should be under tenants with deep organisational hierarchies. This role owns the next version of it.
What the job is
- Own the evaluation path that every product calls before rendering anything a permission can hide.
- Design and land a revised policy model without a breaking change for existing tenants.
- Work directly with three or four product teams at a time on how they express their own permissions.
- Hold the latency budget: entitlement checks are on the critical path of every page in the estate.
What we need from you
- Substantial experience with authorisation systems. RBAC, ABAC, relationship-based, or something you had to invent.
- Comfortable making a change that several hundred engineers depend on, and staging it so nobody notices.
- A record of writing the design document before the code.
- Apply to
- careers@cedxsystems.com
- Reference
- sta-189
You are the engineer in the room when a bank moves its first workload onto the platform. Roughly a third of the job is configuration, a third is data, and a third is convincing a risk committee that the plan is sound.
What the job is
- Lead the technical workstream on two or three concurrent implementations.
- Write the migration plan, including the rollback, before any data moves.
- Sit with the customer's operations team through the first two month-ends after go-live.
- Feed recurring friction back to product with enough evidence to get it fixed.
What we need from you
- Experience implementing enterprise software inside a regulated organisation.
- SQL you can write without looking things up, and enough scripting to move data safely.
- Willingness to travel to a customer site around two days a week.
- Apply to
- careers@cedxsystems.com
- Reference
- imp-182
The Frankfurt region holds data that legally may not leave it. This role keeps that region inside its availability target while it grows, and keeps the isolation guarantee true in practice as well as on paper.
What the job is
- Carry the pager on a one-week-in-six rotation for the EU control plane.
- Own capacity planning for a region that has grown by roughly 40 per cent a year.
- Run incident review, and write the version of the report the customer sees.
- Prove regional isolation continuously rather than annually.
What we need from you
- Production experience with Kubernetes, Postgres and at least one message bus at scale.
- Calm and specific in an incident, and prepared to be the person who says stop.
- Working German is useful for the audits, but is not required.
- Apply to
- careers@cedxsystems.com
- Reference
- sre-91
Ledger was the first product CEDX shipped and is still the one customers audit hardest. This role owns the posting engine and the close: the parts where being approximately right is the same as being wrong.
What the job is
- Own the roadmap for postings, reconciliation and the period close.
- Work with the finance teams of six design-partner customers every quarter.
- Decide what does not get built, and write down why.
- Represent Ledger's needs in the platform's data and audit design.
What we need from you
- You understand double-entry accounting well enough to argue with a controller.
- Experience owning a product where correctness is a regulatory matter.
- Comfortable saying no to a large customer with a specific reason.
- Apply to
- careers@cedxsystems.com
- Reference
- pro-154
Every action in the estate lands in one audit trail. This role turns that stream into detections that are worth waking somebody up for, and handles the ones that are.
What the job is
- Build and tune detections across platform, product and customer-tenant activity.
- Lead response for security incidents, including the customer notification.
- Reduce the false-positive rate, which is currently the main constraint on coverage.
- Run purple-team exercises with the platform teams twice a year.
What we need from you
- Hands-on detection engineering in a SaaS environment, not only in an enterprise SOC.
- Fluency in at least one query language over large event data.
- Eligible for UK security clearance, or willing to apply.
- Apply to
- careers@cedxsystems.com
- Reference
- sec-189
CEDX OS is documented well in places and not at all in others. This role owns the platform reference (identity, events, integration and entitlements) and holds the line on it as the surface grows.
What the job is
- Write and maintain the platform reference, including every code sample in it.
- Review the documentation attached to each platform release before it ships.
- Run the style guide, and defend it in review.
- Test your own instructions against a clean tenant before publishing them.
What we need from you
- Published technical documentation for a developer audience.
- Able to read the code you are documenting, in at least one of TypeScript, Go or Python.
- British English, and strong opinions about the comma.
- Apply to
- careers@cedxsystems.com
- Reference
- tec-175
Fifteen to twenty named accounts across the region, most of which already run one or two CEDX products and could run twelve. The work is expansion far more than it is new logos.
What the job is
- Own the commercial relationship for a defined set of accounts.
- Build the multi-year platform case with the customer's own finance team.
- Bring implementation and support into the deal early rather than after signature.
- Keep the forecast honest, including when it moves the wrong way.
What we need from you
- A record of enterprise software sales in the region across more than one country.
- Comfortable with a long, committee-driven purchase.
- You have walked away from a deal that was going to fail in delivery.
- Apply to
- careers@cedxsystems.com
- Reference
- acc-147
Most customers arrive carrying twenty years of records in a system nobody has fully understood since the person who built it left. This role gets that history onto the platform without losing any of it.
What the job is
- Profile source systems and write the mapping, including everything that cannot be mapped.
- Build and rehearse the cutover, twice, against production-scale volumes.
- Own reconciliation: the counts have to agree before anyone signs anything.
- Hand over to the customer's team with documentation they can maintain.
What we need from you
- You have run at least one migration that went badly and can explain what you changed afterwards.
- Strong SQL and comfort with messy, undocumented legacy schemas.
- Patience for the last two per cent of records, which take half the time.
- Apply to
- careers@cedxsystems.com
- Reference
- mig-140
One hundred and seven products share one component library and one contrast guarantee. This role owns the components themselves (the code, not the drawings) and the tooling that keeps every product's accent legible.
What the job is
- Build and maintain the shared component library used by every product team.
- Own the colour system, including the per-hue contrast solving that makes it safe.
- Review product interfaces against the system and fix the system when it is the problem.
- Keep accessibility conformance measurable rather than aspirational.
What we need from you
- Production React and CSS at a level where you are the person others ask.
- Real working knowledge of WCAG, not a checklist familiarity with it.
- Interest in colour science is an advantage; we will teach the rest.
- Apply to
- careers@cedxsystems.com
- Reference
- des-105
Cover for a maternity leave, supporting the Data Protection Officer across records of processing, transfer assessments and the growing volume of customer due-diligence questionnaires.
What the job is
- Maintain the record of processing activities across all product lines.
- Draft and review transfer impact assessments for new regions and sub-processors.
- Respond to customer security and privacy questionnaires within the agreed turnaround.
- Support data subject requests end to end.
What we need from you
- Working knowledge of the UK GDPR and the EU GDPR in practice, not only in outline.
- Experience in a processor rather than only a controller organisation is an advantage.
- Able to give a plain answer to a question a lawyer asked in a complicated way.
- Apply to
- careers@cedxsystems.com
- Reference
- dat-161
Hiring
How the process runs.
Four stages over two to three weeks. The practical session is paid, and no stage asks you to work for free or to solve a puzzle you will never see again.
- Stage one
A conversation, not a screen.
Forty-five minutes with the hiring manager, who has read your application themselves. You will be told the salary band, the team, and what the first six months actually involve before you are asked anything difficult.
- Stage two
A technical discussion about your own work.
Ninety minutes with two engineers, spent on something you have built. There is no whiteboard algorithm and no take-home exercise; we would rather talk about a real system you understand deeply than a toy one neither of us cares about.
- Stage three
A practical session.
Three hours, paid at your day rate, working on a problem drawn from the team's actual backlog with one of its engineers. You keep the code and we do not use it. This stage can be scheduled in the evening or at a weekend if that is easier.
- Stage four
Meet the team, and ask them anything.
An hour with two or three people you would work with daily, with no manager present and no assessment attached. Its only purpose is to let you find out what we are actually like from people who are not selling.
- Decision
An answer within three working days.
Offers include the band, where in it you sit and why. If the answer is no you get a specific reason rather than a form, and you are welcome to apply again after six months.
Adjustments.
Tell us what you need and we will arrange it, extra time, written questions in advance, a different format for the practical session, or a break structure that works for you. You do not have to explain why, and the request is not visible to the people assessing you.
Early careers.
We take twenty-four graduates and eight apprentices a year into a two-year programme across platform, product and services. Applications open each January and do not ask for a degree classification, a named university, or a covering letter.
Applying
Nothing here is filtered by an algorithm before a person reads it.
Applications go to a hiring manager, not to a keyword screen. Expect a reply either way within ten working days, and a specific reason if the answer is no.