Role Overview

This is a platform / DevOps engineering role embedded within a NetDevOps partnership model — a hybrid structure where network engineers own network design and configuration intent, while this hire owns the automation, CI/CD tooling, and delivery pipeline that turns that intent into safely deployed, self-service infrastructure.

This is not a traditional network engineering role. The candidate is not expected to hold routing/switching expertise (e.g. CCNA/CCNP-level knowledge). They are expected to be the automation backbone that enables network engineers to work productively without needing to touch Jenkins, Helm, or Kubernetes directly.

Core outcome: network engineers should be able to push changes through Git and trust the pipeline to validate, test, and deploy those changes — without requiring DevOps hand-holding for every change

Key Responsibilities

CI/CD Pipeline Engineering (Jenkins / Groovy)

•      Design, build, and maintain Jenkins declarative and scripted pipelines

•      Develop and maintain custom Groovy shared libraries used across multiple pipeline jobs

•      Diagnose and fix broken or flaky pipeline jobs, often under time pressure

•      Manage Jenkins plugin ecosystem, agent/node configuration, and credentials management

•      Implement pipeline stages for linting, testing, artifact publishing (Nexus), and deployment gating

Application Deployment on OpenShift / Kubernetes

•      Package and deploy applications using Helm charts (authoring and maintaining charts)

•      Manage OpenShift-specific constructs: routes, projects/namespaces, security context constraints, resource quotas

•      Handle rolling updates, rollback strategies, and environment promotion (dev → staging → prod)

•      Troubleshoot pod failures, resource constraints, and in-cluster networking issues

GitOps Enablement (Network Engineer Self-Service)

•      Build GitOps workflows that let network engineers submit changes via Git for automated validation and deployment

•      Define branch protection, PR/merge request gating, and approval workflows balancing safety and speed

•      Create templates and scaffolding so network engineers can self-serve without deep Kubernetes knowledge

•      Own the adoption curve — this is as much a change-management and UX problem as a technical one

Automation Tooling (Python / Bash)

•      Write production-quality Python: modular, tested, documented, with proper exception handling

•      Build pipeline utilities, monitoring/alerting glue code, Ansible playbook wrappers, and reporting scripts against Prometheus/Telegraf data

•      Use Bash for lightweight automation, cron-driven tasks, and Linux system-level operations

Code Review, Debugging & Documentation

•      Review pull requests from network engineers submitting GitOps changes (pipeline/config correctness)

•      Root-cause pipeline failures with strong Jenkins log-reading and debugging discipline

•      Maintain runbooks, onboarding guides, and pipeline architecture documentation

Must-Have Requirements

•      Jenkins expertise with Groovy scripting — non-negotiable; must have authored custom shared libraries, not just consumed existing Jenkinsfiles

•      5+ years of production-quality Python development

•      5+ years of DevOps / platform engineering experience

•      Strong Git proficiency (branching strategies, PR workflows, merge conflict resolution)

•      Solid Linux / Bash scripting skills

•      Self-motivated, able to operate with minimal oversight in an async environment

•      Strong written English communication skills — critical given the Teams-based async-first culture

Technology Stack

• CI/CD: Jenkins, Groovy (shared libraries)

• Container Platform: OpenShift (Kubernetes), Helm
• Config Management: Ansible
• Artifact Management: Nexus
• Monitoring/Observability: Telegraf, Prometheus, Grafana
• Languages: Python, Bash
• Version Control: Git (GitOps workflows)

In the first 30 days, the candidate is expected to fix broken pipelines and update critical applications, which tests how fast they can debug Jenkins and Groovy issues within existing, likely messy, tech debt. Between 30 and 90 days, GitOps workflows should be fully operational with engineers using them confidently, testing cross functional enablement, meaning both the technical build and the ability to drive adoption and change management among network engineers. By the 6 to 12 month mark, the goal is full automation maturity with a stable toolchain, which tests long horizon platform ownership rather than just task execution.