Senior Network Automation Engineer
12+ years in network engineering and 15+ in telecom. I build the automation and platforms that let large service-provider networks be changed safely, at scale: Python and Go services, Kubernetes, Ansible, CI/CD pipelines, and the validation that keeps production healthy.
Projects from my time at Cox Communications, described at a high level. Happy to go deeper in conversation.
Internal platform aggregating topology, inventory, telemetry, and service data for 70,000+ network elements, used by 1,000+ employees. Python and Go microservices on Kubernetes, with dashboards, Redis caching, and Prometheus/Grafana monitoring.
A Python bootstrap that devices fetch over DHCP/HTTP, detect their own platform, pick the right software, and upgrade themselves across Juniper, Cisco, and Arista. Paired with a service that resolves the correct production config from a serial number. Used on 1,000+ turn-ups.
Staged Ansible/AWX workflows for 700+ IOS XR routers plus Nexus, Arista, and Juniper, with routing and service verification and failure gates. Raised safe concurrency from 2–4 devices to 10–20.
A Go-based platform, built on Containerlab, that creates reproducible network labs derived from production for testing, troubleshooting, and change validation.
Replaced manual Segment Routing deployments with staged workflows that validate the underlay before traffic activation. Automated streaming-telemetry deployment and per-device certificate rotation across four vendors.
Daily use of AI coding agents for development, review, testing, and documentation, plus controlled tooling that gives agents structured platform context while blocking direct production-device access.
Topology views from the internal network engineering platform I work on, rendered from live inventory and link data. They run from a small network to one of the largest.
Beyond my day job, I design, build, and operate software and infrastructure for a working livestock and hay farm. The code is private; I'm glad to walk through architecture and decisions in an interview.
A multi-cluster Kubernetes environment I designed and run end to end. ArgoCD is the source of truth for everything deployed; Kargo promotes first-party app images from dev to prod; Renovate keeps charts and third-party images current. Secrets are encrypted in Git with sops/age and decrypted in-cluster. A WireGuard mesh links the nodes so internal services never touch the public internet. Includes Prometheus/Grafana monitoring, SSO, S3-compatible object storage, Ansible-based node bootstrap, and documented backup and disaster-recovery procedures.
Every change goes through pipelines I built. Gitea Actions builds a container image on each push: feature branches publish a dev image, merges to main publish the release image, and every pull request builds its own tagged image. An Argo CD pull-request generator deploys that image as an ephemeral preview environment at a predictable URL, a bot comments the link on the PR, and the environment is torn down when the PR closes. Kargo then promotes release images through dev and prod stages, with Renovate opening dependency-update PRs and sops keeping secrets encrypted in Git. The same pattern ships the farm app, the website, the game server, and the server list.
A FastAPI and MongoDB web app for livestock, pastures, hay inventory and sales, fields, and equipment, with a retail store (Square payments) and an LLM-assisted equipment troubleshooting agent. I built the foundation: the data model, modular routes, role-based access control, API tokens, a CLI, and a test suite. We've grown it together with my farm partner, who was new to software development when we started and whom I mentored along the way.
The farm's public Flask site, with product pages, a contact form, a live Facebook feed, and QR-code landing pages for printed campaigns. The /shop storefront is a thin server-rendered client of the farm app's key-authenticated API, so pricing and inventory logic live in one place and the API key never reaches the browser.
A Return to Castle Wolfenstein mod and community server, written mostly in C. The game client is compiled to WebAssembly, so anyone can play in the browser with nothing to install; browsers can't send raw UDP, so the client reaches the server through a UDP-over-WebSocket bridge. Native players get a one-command install for Linux and Windows. The site adds live server status, a live-watch view, and game history. Runs on Kubernetes through the GitOps platform above.
A Go reimplementation of the Quake 3-style master server, which game servers register with so players can find them. It backs a public RTCW / ET server list that tracks online servers, player counts, mods, and master uptime over time. Deployed through the same GitOps pipeline.
The farm app keeps dated weights and events for every animal, plus hay inventory and equipment hours, so decisions can start from the record instead of memory. The litter comparison tool is the clearest example. Pick up to six litters and it lines them up by days since farrow (or AI date), so litters born weeks apart can be judged on equal footing. For each one it shows survivors and mortality, average and median weight, average daily gain, weight at 56 days, days to reach 50 lb, and the top individual growers, with middle-50% bands so one outlier pig doesn't mislead.
The point is to replace "that litter seemed good" with numbers when choosing which sows and boars to rebreed, which animals to keep as breeding stock, and which to sell or process. The same thinking runs through the rest of the app: weight alerts flag animals that are falling behind, and a maintenance dashboard shows which equipment is down or overdue. The screenshots below use fictional demo data, and the same boar produces the slowest litter with one sow and the fastest with another. That is the kind of result memory tends to miss, and the reason pairings get judged on the record rather than on any one animal.
Less More · From my self-hosted Git server, where this work lives.
Apr 2024 – Present
Cox Communications · Platform Engineering / DevOps / Network Automation
Build and support the internal network engineering platform. Python and Go services, Kubernetes, GitOps with Jenkins and ArgoCD, and shared production ownership of what the team ships.
Oct 2019 – Apr 2024
Cox Communications
Technical lead on a team chartered to stand up ZTP that grew into provisioning, validation, and upgrade automation. Led weekly reviews and mentored network engineers new to Python, Ansible, and software practices.
Apr 2014 – Oct 2019
Cox Communications
Production engineering across seven markets and 80+ hub sites. Led regional modernization, including the move from Cisco 7600s to ASR 9000, plus maintenance windows, escalations, and on-call.
2010 – 2014
Cox Communications
Started in inbound technical support and moved up to technical support lead. Then went into the field as a service assurance technician, gaining hands-on experience with equipment turn-ups and troubleshooting, including racking and cabling, fiber patching, and work in data centers and hub sites.
This portfolio is deployed the same way as the apps above: a git push becomes a container image, a promotion, and a rollout on my own Kubernetes cluster, with one deliberate manual gate before production.
Every change starts as a PR, and every PR gets its own environment.
Merging promotes the same image through staging to production, with a person in the loop before prod.
v26.10.01-ab12cd34Read live from the running container. Push a change and this panel updates after the rollout.
I'm interested in network automation, platform engineering, DevOps, and infrastructure roles where deep networking experience meets software.
travissandmann@gmail.com LinkedIn GitHub Résumé (PDF) Cover letter (PDF)
Oklahoma City, OK