Principal of backend

Scheme Serve is insurance software like no other.

Scheme Serve is insurance software like no other.

Hosted in the cloud for MGAs, brokers and insurers, the Scheme Serve platform boasts unique flexibility, unstoppable innovation and truly Obsessive Support.

Started in 2000 by our CEO, Adam, Scheme Serve has grown from strength to strength, never having taken outside investment. We're proud of how far we've come and how loyal we've stayed to our Core Values.

We're fully remote (we were doing it before it was fashionable!), although we get together twice a year for Team Retreats.

We prize self-development and encourage everyone to keep learning and challenging themselves. Free books? Mentoring? Professional development? You got it.

We also offer flexible working, paid charity days, a fantastic, relaxed and open company culture and free biscuits through the post.

We genuinely believe this is the best place you could ever work.

If you're excited, good! So are we.

Come and join the Insurtech revolution!

We're looking for an exceptional Principal Backend Engineer to help make backend engineering across Scheme Serve better.

You’ll be one of the most technically experienced engineers in the organisation and the CTO’s primary technical partner for backend engineering, helping shape our architecture, engineering principles and technical direction.

But this isn’t primarily a feature delivery role and your job isn’t to personally build everything you help design.

You’ll work alongside engineers and teams, helping solve difficult problems, challenging their thinking and developing their technical skills and judgement.

This is a deeply technical role.

You’ll need the depth to understand complex backend systems, architecture, security, performance, resilience and maintainability; review designs and implementations; spot risks; and challenge experienced engineers.

But technical knowledge alone isn’t enough.

We want someone who understands there isn’t always one “correct” way to build software.

Patterns, standards and best practices are useful tools. They aren’t commandments.

That means understanding the problem, business, existing platform, risks and likely future – and making pragmatic decisions based on the trade-offs.

Sometimes the right answer will be a new service or technology.

Sometimes it’ll be improving what we already have.

Sometimes the boring solution really is the best solution.

We’re quite comfortable with that.

Success in this role comes through influence rather than authority
.

We don’t want every difficult technical decision to end with:

“We’d better ask the Principal Engineer.”

If an engineer proposes an approach you disagree with, we don’t just want you to replace it with your own.

Understand their thinking. Ask questions. Challenge assumptions. Explore the trade-offs. Share your experience.

And be prepared to change your own mind too.

The goal is to leave that engineer better equipped to solve the next problem, not just holding the answer to this one.

Your technical impact should multiply through the people around you.

You’ll remain close enough to the code to understand what’s actually happening and occasionally roll up your sleeves to prototype, investigate a difficult problem or unblock a team.

But if after a year you’ve personally written loads of brilliant software while everyone around you is working exactly as they were before,
we haven’t succeeded
.

Our platform has been evolving for more than 25 years.

At…