DevOps Technical Evangelist

A DevOps Technical Evangelist is a working engineer who spends their time making other engineers successful with a platform, toolchain, or methodology — and doing it in public. The job combines software development, technical communication, and community building into a role that doesn't fit neatly into any single org chart box.

On a given week, that might look like: pushing a new Terraform module to a public GitHub repo that demonstrates a GitOps deployment pattern, recording a 12-minute walkthrough video of that module for YouTube, fielding questions about it in the company Discord, presenting a version of the demo as a KubeCon breakout session proposal, and writing up a blog post that explains the underlying architectural tradeoff in enough depth to rank for the search terms engineers actually use when they hit the problem.

The technical bar is non-negotiable. Developers smell inauthentic demos from a distance — if you can't answer the follow-up question in a workshop without checking documentation, your credibility evaporates. The best evangelists bring the kind of scar tissue that only comes from operating systems under pressure: they know which Kubernetes network policies bite you at scale, which CI/CD patterns look elegant in demos but fall apart in monorepos, and which IaC abstractions add complexity without proportional value.

The community half of the role is less glamorous than the conference stage makes it appear. It involves sustained, patient engagement — responding to GitHub issues on sample repos, showing up in Discord at odd hours, remembering which attendee at which conference asked about a specific use case and following up six months later. That consistency is what builds the trust that makes an evangelist's product recommendations land differently than a marketing email.

Most DevOps Technical Evangelists operate within a developer relations (DevRel) team and report to a Head of Developer Relations or VP of Marketing with a technical charter. Collaboration with product management is constant — the evangelist is often the most direct line between what developers say they want in the field and what ends up on the roadmap.

Engineering foundation:

• 4–7 years of software engineering, platform engineering, site reliability engineering, or infrastructure engineering
• Demonstrated production experience with container orchestration (Kubernetes), CI/CD pipelines (GitHub Actions, GitLab CI, Jenkins, Tekton), and infrastructure-as-code (Terraform, Pulumi, CDK)
• Fluency in at least one scripting language (Python, Go, Bash) and one application development language (Go, Python, TypeScript)
• Cloud platform depth in at least one of AWS, GCP, or Azure — certifications (Solutions Architect, Professional Data Engineer, etc.) are supporting evidence, not substitutes for hands-on experience

Communication and content skills:

• Public conference speaking with a verifiable talk history (CFP acceptances at KubeCon, HashiConf, DevOps Days, re:Invent, or equivalent)
• Technical writing portfolio — blog posts, tutorials, or documentation with measurable readership
• Video content creation experience: screencasting, editing, and publishing to YouTube or similar platforms
• GitHub presence with public repos that demonstrate coding standards and documentation quality

Community and product sense:

• Experience engaging developer communities on GitHub, Discord, or Slack at scale
• Familiarity with developer experience principles: API design, SDK ergonomics, CLI usability, documentation quality
• Understanding of product analytics tools used in DevRel: Orbit, Common Room, Amplitude, or equivalent

Certifications that carry weight:

• CNCF Certified Kubernetes Administrator (CKA) or Certified Kubernetes Application Developer (CKAD)
• HashiCorp Certified Terraform Associate
• AWS Solutions Architect Professional or GCP Professional Cloud Architect
• GitLab Certified CI/CD Specialist

What doesn't substitute for the above:

• Marketing or sales backgrounds without engineering depth
• Academic credentials without public technical output
• Management experience without individual contributor engineering history

DevOps Technical Evangelist is a role that didn't meaningfully exist 15 years ago and now has a defined career track, a compensation range competitive with senior software engineering, and a clear demand signal from every major cloud and DevOps tooling vendor.

The structural driver is product-led growth. When developer tools spread bottoms-up through organizations — a team adopts a CI/CD platform, it works, the platform expands to the rest of engineering, then gets signed as an enterprise contract — the technical evangelist function is what accelerates the initial adoption and trust-building. That motion has become the dominant go-to-market strategy for DevOps software companies, which makes evangelists load-bearing in the revenue model even when they're not on a quota.

AI's impact on the field cuts in two directions. On one side, AI tools have compressed the time to produce tutorial content, lowered the threshold for spinning up demo environments, and made it easier for smaller teams to ship more. On the other side, the sheer volume of AI-generated documentation and tutorials has made authenticity and live credibility more valuable — an evangelist who can debug a Kubernetes cluster failure on stage in front of 800 engineers earns trust that no amount of written content replicates.

Demand is concentrated at cloud-native tooling companies, cloud provider partner ecosystems, observability vendors (Datadog, Grafana, Honeycomb), and security platforms with developer-facing products. Startups in the platform engineering and internal developer portal (IDP) space — Backstage ecosystem companies, Port, Cortex — have been particularly active recruiters as that market segment grows.

The supply side is constrained. Finding someone who can write a production-quality Helm chart, explain it clearly to a mixed-experience audience in a 40-minute session, and then ship a blog post about it by the end of the week is genuinely hard. Companies report that strong candidates have multiple offers in play, and compensation reflects that competition.

For people currently in SRE, platform engineering, or backend development roles who are interested in this path, the investment is primarily in public presence: speaking at local DevOps Days events, building a GitHub portfolio of quality sample projects, and starting to write publicly about problems you've actually solved. The technical foundation for most experienced engineers is already there — the gap is usually the public track record.

Dear Hiring Manager,

I'm applying for the DevOps Technical Evangelist role at [Company]. For the last five years I've been a senior platform engineer at [Company], where I built and maintained the internal developer platform our 200-engineer organization used to ship to production. I've been the person developers come to when their pipeline breaks in a way the documentation doesn't cover, and I've spent a lot of time converting those conversations into documentation and tooling that prevent the next version of the question.

Over the past two years I've started doing that publicly. I've given four conference talks — two at regional DevOps Days events, one at KubeCon NA on our GitOps migration, and one at HashiConf on a Terraform module pattern we developed internally. My KubeCon session drew about 600 attendees and the recording has 8,000 views. I maintain a GitHub organization with five public repos totaling around 340 stars, and I write roughly twice a month on my blog about Kubernetes and CI/CD topics — the most-read post has about 12,000 organic monthly visitors.

The reason I want to move into DevRel full-time is straightforward: the hours I spend creating public content and engaging the community have been more energizing than the hours I spend in internal ticket queues, and I want to do that work at a scale a single platform team can't support. [Company]'s approach to developer experience — specifically the investment in open-source SDK quality and the public roadmap process — is the reason I'm applying here over other options I'm evaluating.

I'd appreciate the chance to walk through my talk history and writing portfolio with your team.

[Your Name]