Send Q&A with Jeff Owens, Lead DevOps Engineer

Building reliable systems at scale through automation and collaboration with Lead DevOps Engineer, Jeff Owens

In this edition of our Q&A series, we speak with Jeff Owens, Lead DevOps Engineer at Send, about what it takes to keep a fast-growing underwriting platform running smoothly. From building resilient infrastructure and embedding security into delivery pipelines, to enabling teams to move quickly with confidence, Jeff shares how DevOps at Send is as much about people and collaboration as it is about technology.

Can you walk us through your role and a typical day?

The honest answer is there isn’t really a typical day, and that’s part of what makes it enjoyable.

My role sits across infrastructure, automation, security, and delivery. At a high level, it’s about maintaining a reliable platform and helping engineering teams ship software safely and quickly as we scale. A lot of that comes down to automation. The more we can automate, the more consistent and predictable everything becomes, whether that’s deployments, infrastructure changes, or how teams interact with the platform.

Day to day, it really varies. I might be digging into an issue, supporting a partner integration, or helping shape a client-facing requirement. The next, I could be building a proof of concept, improving our delivery pipelines, or working on longer-term platform design.

And then there’s the people side: mentoring, pairing with engineers, and helping teams grow. That part is just as important as the technical work.

What drew you to Send?

I was looking for something with real ownership.

Coming from a cloud consultancy background, I’d spent years moving between different businesses and challenges, which I really enjoyed. But I reached a point where I wanted to go deeper, to own a platform, see it evolve, and actually live with the impact of the decisions you make.

Send offered that. Not just in terms of DevOps responsibility, but across the whole platform, automation, reliability, delivery, and how it connects into the wider business. The fact it sits at the core of how clients operate made the work feel meaningful.

Just as important was the team. From the early conversations, it was clear there was a pragmatic, collaborative culture, focused on solving problems properly, not over-engineering them. That resonated with how I like to work.

What’s it like working at Send?

Trust and ownership are probably the two things that stand out most.

People are encouraged to speak up, share ideas, and get involved in solving problems, regardless of role or title. That creates a really open environment where people genuinely help each other move forward.

The DevOps team in particular works closely together. We challenge ideas, support each other when things go wrong, and keep things moving. It’s a proper team effort.

Over time, that environment has changed how I approach my work. Early in my career, I was very focused on the technical problem in front of me. Now I’m much more aware of the wider impact on engineers, on delivery, and on the business. A big part of my role is helping create an environment where teams can do their best work.

What shaped your DevOps approach before Send?

I started as a VMware engineer working with physical and virtual infrastructure. That early experience really shaped my thinking around reliability; when you’ve dealt with server failures in the middle of the night, you quickly learn the value of resilience and preparation.

Early on, I gravitated towards automation. I was always looking for ways to reduce manual work and make systems more consistent.

From there, I moved into cloud consultancy, working across a wide range of businesses and environments. That exposure was invaluable; it sharpened my problem-solving skills and gave me a broad view of how different teams approach similar challenges.

Across all of that, a few principles stuck with me: build for reliability, automate where it adds value, and always look for a better way of doing things.

How does Send balance speed and stability?

For us, it comes down to confidence. If you trust your pipelines, your testing, and your automation, you can move quickly without taking unnecessary risks.

We focus heavily on making delivery repeatable. Every change goes through a consistent pipeline with automated checks and testing, and nothing reaches production without passing through staging first. That consistency removes a lot of uncertainty.

The goal isn’t to choose between moving quickly or maintaining stability, it’s to build the right foundations so both can exist together.

We also put a big emphasis on visibility, good logging, monitoring, and alerting so we always understand what’s happening in real time.

How do you approach security and compliance?

Security is built into how we design and deliver everything. We use AWS best practices as a baseline and apply those principles consistently across infrastructure and access controls. The aim is to make the secure way the default way.

A lot of this is embedded in our continuous integration and continuous delivery pipelines. We run automated checks, vulnerability scanning, and testing as part of the delivery process, so issues are caught early rather than after the fact. We also carry out regular reviews and audits to make sure we’re maintaining a strong security posture.

Ultimately, we’re dealing with systems our clients rely on, so security and compliance aren’t optional extras, they’re part of the trust we build with them.

A challenge you’re proud of?

As the business scaled, our release process started to show strain. One of the biggest issues was inconsistency in how applications and configurations were versioned, which made releases harder to track and less predictable.

I worked on redesigning the pipelines to introduce a more structured versioning approach and a clearer staged release process. The goal was to make it obvious what was going live and reduce room for error.

I worked closely with another lead on the build and software side to streamline the process and remove bottlenecks without adding complexity.

The result was a much smoother release flow. Build times dropped by around 37%, but more importantly, releases became more predictable and far less stressful for the engineers using them.

How is DevOps at Send different?

The biggest difference is that DevOps isn’t a separate function here; it’s embedded in how engineering works.

There’s shared ownership across teams, rather than DevOps being a handoff point. That changes the dynamic completely. There’s also a strong drive to keep improving. If something works, that’s not the end point, it’s just the starting point for making it better.

We also adopt new tools and approaches where they make sense, whether that’s automation improvements, AI-driven tooling, or serverless technologies. But it’s always pragmatic, we only bring things in if they genuinely solve a problem.

What excites you most about the future?

Scale is the big one.

As we grow, the platform evolves with new demands around performance, reliability, and delivery. That keeps things interesting because you’re constantly solving new problems.

There’s also a lot of work already underway around new ideas and proof of concepts, particularly around AI and new ways of building and shipping software. That curiosity and willingness to experiment is something I find really exciting.

And finally, the team itself. As we grow, we’re bringing in new perspectives and skills, which naturally pushes us forward.