> Markdown version of [/jobs/ext/3742908-technical-product-owner-devops-platform-uk](https://www.wearedevelopers.com/jobs/ext/3742908-technical-product-owner-devops-platform-uk). Every page supports `.md` or `Accept: text/markdown`. Links point to the HTML versions so they work for humans too. Agent guide: [/agents.md](https://www.wearedevelopers.com/agents.md). --- # Technical Product Owner, DevOps Platform - UK - **Company:** Oneview Commerce - **Location:** London, UK (Remote available) - **Experience:** Expert - **Salary:** £77,395.0 - **Contract:** Permanent contract - **Skills:** JavaScript (Programming Language), Artificial Intelligence, Amazon Web Services, Software System Penetration Testing, Bash Shell, Unix, Cloud Computing, Cyber Security, Continuous Integration, Linux, DevOps, Github, Monitoring of Systems, Python (Programming Language), Reliability Engineering, Ansible, Zero Trust Network Access, Requirements Traceability, Software Engineering, Datadog, Circleci, Google Cloud, Delivery Pipeline, Git, Cloudformation, Gitlab-ci, Kubernetes, Cloudwatch, Terraform, Splunk, AIOps, Appdynamics, Software Version Control, Devsecops, Docker - **Published:** October 15, 2026 - **Apply:** https://www.adzuna.co.uk/jobs/details/5928720435 ## About the Role * 2+ years as a Product Owner, Technical Product Owner, or in an equivalent backlog-owning role. * 5+ years in DevOps, security operations, platform engineering, or site reliability engineering, with working experience in each of the following areas, using these or comparable tools: + Version control: Git + CI/CD: CircleCI, GitLab CI/CD, GitHub Actions + Cloud platforms: AWS, Google Cloud + Containers and orchestration: Docker, Kubernetes + Infrastructure as code: Terraform, CloudFormation, Ansible + Scripting: Python, Bash, JavaScript + Monitoring and observability: Datadog, AppDynamics, CloudWatch, Splunk + Operating systems: Linux, UNIX * Working knowledge of security practice for cloud infrastructure and delivery pipelines, including access control, secrets handling, and pipeline guardrails. * Able to run an intake conversation with an engineer and come out of it with a complete requirement. Knows enough to spot what the engineer left out and what the change touches downstream. * Writes acceptance criteria that account for adjacent systems, integrations, and existing platform behavior as well as the story itself. * Translates business requirements into language a technical audience can act on, and technical constraints into terms a business stakeholder can decide against. * Has ranked infrastructure or platform work against visible feature or customer work, and defended the ranking to stakeholders. * Negotiation and conflict resolution: Has declined a request from a senior stakeholder, explained the reasoning, and kept the relationship intact. * Has coordinated dependencies across multiple internal teams and external parties, and run a dependency tracker that the other teams on the program used. Preferred skills & experience * Point of sale experience. * Has worked in a shared services or internal platform team serving internal customers with competing priorities, and can describe how the queue was managed. * Has been on call, and knows from experience what unplanned work does to a team's ability to deliver. * DevSecOps principles, such as shifting security left and zero trust. * Platform engineering and GitOps: internal developer and monitoring platforms, self-service infrastructure, declarative deployment. * Reliability and resilience practice such as chaos engineering, penetration testing requirements, and disaster-recovery drills. FinOps awareness for cloud cost accountability. * AI and AIOps fluency, across both the platform (AI-assisted automation, predictive monitoring, self-healing pipelines) and the backlog (story generation, acceptance criteria drafting, requirements traceability). * Has implemented an operational improvement in a past role that measurably improved the speed or quality of a delivery team's work, and can describe the change and its measured effect. * Certifications such as AWS, Google, or Microsoft DevOps credentials. ## Description OneView is looking for a Technical Product Owner with a DevOps engineering background to own the flow of work into our DevSecOps team. The team builds and secures the platform every other team here depends on, which makes it the most contended team in the company. Work reaches the team from two sources: requests from software engineering, QA, agile delivery, product support, customer implementation, security, and leadership; and the Platform Engineering roadmap, which includes building our internal developer platform (IDP). You decide what the team takes on, in what order, and what it declines, and you will say "no" and "not yet" more often than "yes". You report to the Sr. Director of Platform Engineering, who leads the DevSecOps pillar and sets product vision, strategy, and the roadmap, with input from the VP of Engineering, the Chief Architect, and the team's engineers. You work closely with the Sr. Director while it is drafted. The Sr. Director owns how the work gets done (technical approach, standards, assignment, and quality), and you own priority. Expect the Sr. Director and others more senior than you to challenge your ranking. You are expected to defend it with evidence and make adjustments when a stronger case is made. The role needs hands-on DevOps knowledge. You cannot specify a pipeline change, a cluster upgrade, a secrets rotation, or a new set of guardrails without understanding what each one puts at risk. We use AI throughout our work and want you to find uses for it we have not thought of. We also expect you to do this job well if it were switched off tomorrow, because the priority calls and the stakeholder relationships depend on you. This is an individual contributor role with no direct reports. Responsibilities * Own the intake path into the DevSecOps team, and qualify every request at the point of arrival: the desired outcome, affected parties, impact, dependencies, and any hard due dates. Where a request specifies its own solution, establish the problem it is meant to solve before the team commits to that solution. * Rank inbound requests and Platform Engineering roadmap items on one backlog by urgency and value, publish the ranking, and keep it refined far enough ahead that an engineer can start without waiting on you for clarification. Make the trade-offs explicit, and answer to the teams whose work a ranking displaces. A stakeholder should be able to see what their request is weighed against and where it sits without escalating. * Bring the team's improvement ideas to the Sr. Director as roadmap proposals, with the problem, scope, and effort worked out with the team's engineers and architects. * Turn the Platform Engineering roadmap, including the IDP build-out, into backlog items the team can deliver, and keep their status current and published for the teams that depend on them. Report IDP adoption and user feedback to the Sr. Director. * Limit work in progress to what the team can finish, resist mid-sprint insertion, and make the cost of an interruption visible when one is unavoidable. * Translate requesters' needs into concrete platform, automation, tooling, and security requirements, written as stories with testable acceptance criteria that cover the impact of a failed change, rollback, access control, auditability, and cost alongside the functional outcome. * Own the intake of unplanned and obligation-driven demand, including post-incident remediation and work generated by compliance, audit, and customer security commitments, and sequence it against everything else. * Coordinate dependencies across internal teams and third-party vendors, and surface them early enough that they do not stall the queue. * Report on flow: request-to-delivery lead time, work in progress, throughput, queue depth, the proportion of unplanned work, and the split between inbound requests and platform initiatives. Use the numbers to argue for more capacity or more automation.