About Brian Teller
The voice behind Ship It Weekly.
- 73Episodes published
- 25+Years in production
- 3Industry community programs
The story behind Ship It Weekly
The short version, at a glance — the career, the toolkit, and the mission behind the show. The full story is just below.
Why Ship It Weekly exists
Brian started Ship It Weekly because most tech news does a decent job saying what happened, but not always why it matters to the people who actually have to run the systems afterward. A new cloud feature, a GitHub outage, a security advisory, an AI tooling release, a supply chain incident, a Kubernetes change, or a weird platform failure can all sound interesting in a headline. For the people on-call, managing infra, supporting developers, watching costs, and trying not to break production on a Friday, the real question is usually simpler: What does this mean for my team? That is the lens Brian brings to every episode.
Brian has spent years working in real production environments across cloud, infrastructure, automation, and reliability. Day-to-day work has covered Terraform and Terragrunt, AWS, Kubernetes, EKS, Kafka, CI/CD, GitHub, incident response, infrastructure guardrails, cost management, platform patterns, and the messy operational details that rarely show up in clean conference demos. Brian has worked as both a hands-on engineer and a technical mentor, helping teams make better decisions around infrastructure design, reliability, security, and delivery.
Ship It Weekly is built for the engineers, SREs, platform teams, DevOps folks, cloud engineers, technical leaders, and curious practitioners who want more than a headline recap. The show filters the noise down to the stories that matter for infrastructure, reliability, security, cost, engineering workflows, and production operations. Some weeks that means a major outage. Some weeks it means digging into GitHub Actions, AI agents, Terraform, Kubernetes, AWS, supply chain risk, or why a "small" tooling change can become a very big production problem.
Brian's style is practical, opinionated, and grounded in the reality of doing the work—not trying to sound like an analyst reading market notes. The focus is tradeoffs, failure modes, operational risk, team impact, and the "okay, what should we actually do with this?" part that often gets skipped.
That usually means asking questions like: Does this change how we build pipelines? Does this affect our blast radius? Should we be tightening permissions? Is this a real platform shift, or just vendor noise? What would I want my team to know before this becomes our incident?
Outside Ship It Weekly, Brian also hosts Kube Signals, a KubeFM series that picks up where conference keynotes leave off — turning platform trends into direct conversations with the speakers shaping them. He creates DevOps and cloud engineering content through Teller's Tech, with a focus on practical education instead of lab-only demos. The goal is to help engineers connect concepts to the kind of decisions they actually face in production: how to structure Terraform, how to think about reliability, how to avoid fragile automation, how to use AI without outsourcing judgment, and how to build systems that teams can safely operate over time.
At its core, Brian's work is about making infrastructure and operations conversations more useful. Less hype. Less vague "best practices." More context, more judgment, and more respect for the people carrying the pager.
Track record: production systems, leadership, and communication
Production infrastructure
Brian has co-led large-scale AWS → GCP migrations and owned Kafka platform engineering through vendor transitions (Confluent Cloud → MSK → Confluent Cloud with private networking), including Schema Registry and MirrorMaker2 / Replicator during cutover windows. He has supported public-company readiness from an infrastructure and platform angle, run SOC2 evidence programs across multiple audit cycles, and helped prepare teams for SOX expectations. Earlier in his career he operated AWS at depth and contributed heavily to PCI and SOC2 programs in HIPAA-certified environments, and he has led disaster recovery work with explicit RTO/RPO targets. As CTO of a digital-signage company, he led a zero-downtime migration to the cloud.
Leadership under pressure
Brian has operated as CTO and engineering manager, leading technical programs where clarity and accountability matter as much as architecture. Earlier leadership experience included running high-volume restaurant operations with teams up to ~60. Different domain, same lessons in shift orchestration, standards under stress, and customer-visible incidents when something breaks in front of the customer.
Early technical roots
Brian's first paid work in tech came during high school at fred.net (later xecu.net), a Frederick-area dial-up ISP doing front-line support, Unix administration, colo, and customer website hosting. In high school he also managed Unix mail servers and was president of the Network Computer Club. He has been doing production-minded tech work since before DevOps was a job title.
Broadcast and communication
Brian's first station was his own. In 1998, still in high school, he started WBAT Internet Radio (wbat.net, later wbatradio.com) and ran it until about 2005: an early internet-only station with its own roster of DJs, a RealAudio stream, and from January 1999 a channel on SHOUTcast, which was brand new. It gave unsigned bands free airplay. The 1999 site is still in the Internet Archive.
From there Brian came up through radio: a college show on XTSR at Towson University with a dormmate; intern to associate morning show producer at a major Washington, DC station (then Z104 / WWVZ–WWZZ); hosted evening (7–11pm) and Sunday mornings on Key 103.1 in Frederick, Maryland; and spent years as a mobile DJ for schools, weddings, and events. Live timing, reading a room, and staying composed when things break on air. Photos and audio from that era are below in On air & behind the mic.
Advising and teaching
Brian serves as an Industry Advisor at Cornell Tech, mentoring a multidisciplinary team of master's students through Studio as they research, design, test, and build solutions to real-world problems. The guidance is the same judgment this show is about: technical feasibility, engineering tradeoffs, product strategy, reliability, scalability, and what it actually takes to get an idea into production.
Community recognition
In October 2026 Grafana Labs named Brian a Grafana Champion, its program for community experts who share what they know through talks, writing, podcasts, and code. He is also a DevOps Institute Ambassador and an ITIL Ambassador.
Outside work
Brian coaches youth football. Married, four kids. Fundamentals, repetition, and calm communication carry the same whether you are on a sideline, in a war room, or at the dinner table.
On air & behind the mic
Before infrastructure leadership and podcast hosting, Brian came up through the internet radio station he started in high school, college radio, major-market production in Washington, DC, and Frederick’s Key 103.1 — plus years as a mobile DJ. The first photos are from recording on site in 2026: Ship It Weekly at DC State of the Stack, and an interview with Corey Quinn at AWS DMV Community Day. The rest, and the audio clips, are archive samples from that earlier era, the 1990s and 2000s. For how he sounds today on DevOps and platform topics, listen to Ship It Weekly.
In the field, 2026
Archive
Audio samples
-
XTSR promo
Junior year at Towson University — college show on XTSR with a dormmate.
-
Quiznos commercial
Key 103.1, Frederick, Maryland — on-air commercial voice work.
-
Carroll Manor Fire Company commercial
Key 103.1, Frederick, Maryland — on-air commercial voice work.
-
Pentagon area report (September 13, 2001)
Z104 (Washington, DC) — news intern coverage after 9/11, including a bomb-threat situation on 9/13/2001.
What I cover on Ship It Weekly
- DevOps
- Site Reliability Engineering
- Platform Engineering
- AI in Operations
- Cloud Engineering
- CI/CD
- Observability
- Incident Response
- Kubernetes
- Infrastructure as Code
- Production Engineering
Also hosts
Kube Signals on KubeFM — conversations that start where the keynote ends, following up with the speakers behind the trends platform teams have to operationalize next. First episode: Why Kubernetes Needs to Learn GPUs, with Saiyam Pathak.
Available for talks & engagements
Brian also speaks at conferences, internal engineering all-hands, leadership offsites, and on podcasts — same operator-focused lens, in person.
Currently writing
Confidently Wrong — a practical book for DevOps, SRE, platform, and infrastructure engineers on using AI safely across Terraform, Kubernetes, CI/CD, agentic workflows, and operational decisions. Same operator lens you hear on the show, in long form.
Building in the labs
Teller's Tech Labs is where I build practical tools and training systems for DevOps, SRE, platform engineering, and AI-era operational judgment. Flagship: Code Duck, an AI-driven incident simulator that helps engineers practice production judgment without breaking production. Currently in early access.
Also runs
lmgt.com — the long-running “let me google that” page that sends a steady trickle of search traffic back to Ship It Weekly and this bio. Built once, maintained occasionally, useful indefinitely.
lmgt.org — The LMGT Awards (“Let Me Give Thanks”): free, vendor-neutral awards for knowledge given away in production engineering. Produced here; governed with a published conflict policy.
Recent episodes
Ship It Conversations: Rob Koch of Slalom on Accessible Cloud Native, Sign Language Recognition with Kubeflow, Overhyped AI, Conference Accessibility, and Why Teams Should Hire Deaf Engineers
In this episode, Rob Koch discusses accessible cloud native practices, the challenges of sign language recognition in AI, and the importance of hiring deaf engineers.
GitHub Actions Lockfiles, GitLab CVSS 10 CI Flaw, Google Cloud Storage Outage & Torvalds Builds Kernel Patches With Claude Code
This episode of Ship It Weekly covers GitHub Actions' new workflow lockfiles, which help pin actions to specific commits, enhancing security.
Ship It Conversations: Erik Osterman of Cloud Posse on Terraform Modules, IaC Frameworks, Atmos, Internal Developer Platforms, AI Agents, and Why Conventions Matter More Than Ever
In this episode, Erik Osterman of Cloud Posse discusses Terraform modules, infrastructure as code frameworks, and the importance of conventions in the age of AI.
Listen wherever you get podcasts
Rep the show — Shop SIW merch.
Never miss an episode
New episodes weekly. Real conversations and news for engineers running production systems.
Find Ship It Weekly on your platform →Work with me
Be a Guest
Want to share your DevOps journey on Ship It Weekly? We're looking for passionate engineers to interview!
Apply to be a Guest →Become a Sponsor
Reach thousands of DevOps, Platform, and Cloud Engineering professionals. Partner with Ship It Weekly!
Talk Sponsorship →Connect with Teller's Tech
Follow the show on the platforms where the conversation actually happens.
Practitioner conversations
Where Brian shows up in practitioner threads: recent Reddit replies from /u/tellerstech across the engineering subreddits. Comments only — episode posts and self-promotion threads are filtered out.
-
Re: Is the cloud support associate job market cooked??
I wouldnt say its cooked, but entry level cloud is definitely rough right now.
View thread on Reddit →
I also wouldnt only search for “Cloud Support Associate.” A lot of companies call basically the same work Cloud Support Engineer, Technical Support, Sysadmin, NOC, junior DevOps, etc.
And certs alone probably wont carry you. Get really good at Linux, networking, DNS, IAM, logs, and troubleshooting. Build stuff and be able to explain how you’d debug it when it breaks.
So no, I dont think you’re... -
Re: n8n or plain Python on Cloud Run or sth else? Solo dev dilemma
I’d go Python + Cloud Run.
View thread on Reddit →
n8n is great for getting something working fast, but I wouldnt want a bunch of important business workflows living in a visual editor a year from now. Versioning, testing, code review, and debugging all get way easier when its just code.
I also wouldnt overbuild it. Cloud Run + Cloud Tasks + Postgres gets you most of what you need. Give every workflow a run ID, make each step idempotent, save state/output/errors in Postgres, and let Cloud Tasks hand... -
Re: Looking for advice on how to get started with my career with no degree and some unpaid project experience
Honestly, you’re probably closer than you think, but I wouldn’t limit yourself to jobs with “DevOps” in the title.
View thread on Reddit →
That first job is usually the hardest one to get, and a lot of DevOps/platform roles aren’t really entry-level even when companies advertise them that way. I’d also look at Linux admin, cloud support, junior sysadmin, infrastructure, NOC, support engineering, and similar roles. Once you have actual production experience, moving toward DevOps/platform g... -
Re: 🚨 Looking for a DevOps Opportunity / Referral
Your project list is already pretty solid, so I probably wouldn’t spend a ton of time just adding more tools.
View thread on Reddit →
I’d take one of the projects you already have and push it further. Break it on purpose. Figure out what happens when a deploy fails, how you’d roll back, where secrets live, what you’d monitor, how you’d troubleshoot an issue, what happens if a node dies, stuff like that.
Then put that work somewhere public. GitHub, a blog post, a short video, whatever.
A lot o... -
Re: USA-based people: Is the job market crap, or am I a bad engineer?
Honestly, I think it’s probably a combination of a rough market and something in your application/resume strategy.
View thread on Reddit →
The market definitely isn’t great, but I’m still seeing experienced engineers in my network get interviews and get hired. Junior engineers and people trying to break into the industry seem to have it the worst, but senior people absolutely aren’t immune either.
The thing that jumps out to me is that if you’ve been applying since January and are almost nev... -
Re: If AI makes everyone a 10x developer… who gets promoted?
The bar moves.
View thread on Reddit →
If we’re all suddenly 10x developers and we’re solving problems that create real value people will pay for, I don’t think that necessarily means the same amount of software gets built with 1/10th the engineers. We may just build 10x more software.
What changes is what makes someone stand out. Writing code becomes less of the differentiator. Knowing which problems are worth solving, making good architectural decisions, catching when the AI is confidently wro... -
Re: Can I get my first DevOps job without a bachelor’s degree?
Outside of the internship or junior-role path someone else mentioned, there are a bunch of ways to build experience.
View thread on Reddit →
Contribute to open source or volunteer somewhere.
Build something real, not just follow a tutorial. Document what you built, why you made certain decisions, what broke, and how you fixed it.
Go to meetups, get involved in communities, and find people to collaborate with.
You can also come in through adjacent roles like sysadmin, cloud support, infrastructure, or op... -
Re: How to apply gated approval for TF apply in Github actions
Yeah pretty much, although I wouldnt re-run the plan in the apply workflow.
View thread on Reddit →
I’d generate/save the plan with read-only creds, review it, then the gated apply uses that exact saved plan with the prod/write creds.
Otherwise you could end up approving one plan and applying another.
