DevOps

DevOps Engineers enable our engineering teams by delivering standardized CI/CD pipelines, secure coding frameworks and reference architectures that accelerate development while maintaining high reliability standards. The product is the paved road: the fastest way to ship should also be the safe way, and the development teams who use it are the customers.

The CI/CD platform is production. DevOps Engineers are on call for it, because a broken pipeline is an incident for every team behind it, and the paved road is judged by adoption and developer satisfaction as well as by DORA numbers.

You will own features end to end: the specification, the code, the tests and how it behaves in production. This is an individual contributor role with no direct reports, and you are the engineer who answers for whether what you shipped actually works.

The pull request is the visible part. The job is the machine behind it: turning a loosely worded need into something precise enough to build against, naming what can break before it does, proving the change is correct rather than asserting it, and staying with it once it is live.

How we work

• Business alignment and focus come first. Engineering here exists to move the business, not to be busy. You will know which few things matter most this month and why, say so when the work in front of you is not one of them, and land what you committed to on dates the business can plan around, at a quality that does not come back as an incident or a customer escalation.
• Predictable, reliable delivery of quality software is the output of this job, and everything below is in service of it.
• This job gets more hands-on every quarter, not less. The volume of code goes up while the time you spend typing it goes down, so the value moves to the two ends of it: what you specify, and what you verify. You will stay close to production, run the AI harness daily, read code you did not write, and keep your technical judgment current rather than remembered.
• Whoever ships it owns it, regardless of what wrote it. Most code is AI-generated now, so the judgment moved to either side of it: specifying exactly what to build, and verifying that what came back is correct, secure and operable. An agent wrote it is not a defense. Your name is on the merge.
• You do not need to own the roadmap to know why the work matters. You will not be the Product counterpart at this level and you are not expected to be. You are expected to understand what the customer gets and what the business gains from the thing you are building, and to ask before you build the wrong thing correctly. The engineers who move fastest here are the ones who ask that question early rather than at the review.
• You go on call for what you build, and you take your turn on the rotation. Engineering declares risk and timelines in writing for the business to accept, and that includes yours: when a date is at risk you say so early, with evidence, rather than quietly.