Technical Content Engineer, Cloud Native

Recruitment Fraud Alert

We’ve learned that scammers are impersonating Commvault team members—including HR and leadership—via email or text. These bad actors may conduct fake interviews and ask for personal information, such as your social security number.  

What to know:

• Commvault does not conduct interviews by email or text.
• We will never ask you to submit sensitive documents (including banking information, SSN, etc) before your first day.

If you suspect a recruiting scam, please contact us at wwrecruitingteam@commvault.com 

 

About Commvault 

Commvault (NASDAQ: CVLT) is the gold standard in cyber resilience. The company empowers customers to uncover, take action, and rapidly recover from cyberattacks – keeping data safe and businesses resilient. The company’s unique AI-powered platform combines best-in-class data protection, exceptional data security, advanced data intelligence, and lightning-fast recovery across any workload or cloud at the lowest TCO. For over 25 years, more than 100,000 organizations and a vast partner ecosystem have relied on Commvault to reduce risks, improve governance, and do more with data. 

Clumio is bought by builders. The people who evaluate us are Staff engineers, SREs, platform leads, and directors of engineering—people who will decide whether to trust us with 50 petabytes of S3 before they ever talk to a salesperson. They arrive from a search result, an AI assistant, or a colleague’s recommendation. They open the docs. They start a trial. And within about twenty minutes, they either get their first backup running or they close the tab. 

This role owns that twenty minutes—and everything that leads up to it. 

You are not a documentation writer who sits downstream of engineering and turns release notes into paragraphs. You are a content engineer: you run the code, you build the example, you break the workflow, and then you write the thing that makes it obvious. Every guide you publish ships with something that actually works—a Terraform module, a CloudFormation template, a CLI walkthrough, a tested API call. If a builder can’t copy it, paste it, and have it succeed on the first try, it isn’t finished. 

You will sit with the Cloud Native product organization and work shoulder-to-shoulder with engineering, product, and growth. Your work is the top of the funnel, the onboarding path, and the reason a trial converts. 

Why This Role Matters 

Clumio is one of the top products in AWS Marketplace and carries an NPS of 88, and we got there because builders tried it and it worked. But the ceiling on a product-led motion is set by how many people can succeed without us in the room—and right now, that ceiling is our content. 

If you are the engineer who kept ending up writing the guide everyone linked to, or the writer who got tired of describing software you were never allowed to run—this is the seat where those are the same job. 

 

What You’ll Do:

Own the Content That Sells the Product 

• Write and maintain the Clumio docs—getting-started paths, service-by-service protection guides, API and SDK references, restore and recovery runbooks—treating them as a product surface, not an archive 

• Build the fastest possible path to first value: a builder should get their first S3 bucket, DynamoDB table, or RDS instance protected without opening a support ticket or booking a call 

• Author deep technical guides on the workloads that define us—S3 at scale, Apache Iceberg and S3 Tables, DynamoDB, EC2/EBS, RDS/Aurora—including the hard parts: cost, scale, recovery time, and what happens when something goes wrong 

• Own the technical narrative in AWS Marketplace listings, trial flows, and in-product onboarding copy 

Build It Before You Write About It 

• Ship and maintain working example repositories: Terraform modules, CloudFormation and CDK templates, scripts, and sample integrations that builders can fork 

• Test every workflow you document in a real AWS environment—validate the code, validate the permissions, validate the failure modes 

• Build the hands-on lab and GameDay content used at AWS events, where builders break something and recover it themselves 

• Produce short technical demos and walkthroughs—written, visual, or recorded—that show the product doing the thing rather than describing it 

Write for How Builders Actually Find Things 

• Create content that ranks in search and—increasingly—gets retrieved and cited by AI assistants: specific mechanisms, worked examples, real numbers, and concrete scenarios rather than hedged feature claims 

• Identify the questions builders are already asking about cloud data protection and answer them better than anyone else has 

• Turn customer-scale reality into public proof: petabytes, object counts, recovery times, cost deltas 

Close the Loop with Product and Growth 

• Instrument and watch what your content does: activation rate, time to first backup, trial-to-paid conversion, docs-sourced signups, support deflection 

• Bring friction back to engineering and product—when the docs have to apologize for the product, the product is the bug 

• Partner with growth on onboarding experiments, and with field and partner teams so what you build for self-serve also arms sellers 

What Success Looks Like 

• Builders reach first value in a trial without human help, and the activation curve shows it 

• Docs and guides are a measurable source of qualified signups, not a cost center 

• Every AWS service Clumio protects has a current, tested, copy-pasteable guide—and the example repos actually run 

• When an engineer asks an AI assistant how to protect S3 at scale, our content is what it draws from 

• Support tickets that used to be “how do I…” questions stop arriving, because the answer is already published 

Your First 90 Days 

• Week 1: You run the trial yourself as a new user would, and write down every place you got stuck 

• Day 30: You have shipped a rebuilt getting-started path and at least one tested example repo 

• Day 90: You own the content roadmap, you have measurable movement on activation, and engineering comes to you before a feature ships—not after 

What You Bring 

• 4+ years in a developer-facing technical role—technical writing, developer relations, solutions engineering, support engineering, or software engineering with a strong writing track record 

• You write code and you write prose, and you refuse to publish the second without validating the first 

• Working fluency in AWS: S3, IAM, DynamoDB, RDS, EC2, and the mental model of how a cloud team actually operates 

• Hands-on with infrastructure as code (Terraform, CloudFormation, or CDK), APIs, SDKs, and the command line 

• Docs-as-code fluency: Git, Markdown/MDX, PR-based review, and content that lives next to the product 

• The instinct of a teacher—you know where a reader will get confused before they do, and you write to that 

• Demonstrated technical content that shipped and moved something: writing samples and example repos required 

Nice to Have 

• Background in data protection, storage, data engineering, or lakehouse architectures (Iceberg, Parquet, S3 Tables) 

• Experience at a product-led company where docs were a growth channel with real targets attached 

• AWS certification, or a personal AWS account with a billing history that tells a story 

• Experience with docs analytics, search behavior, or optimizing content for AI retrieval 

 

You'll love working here because:
•    High income earning opportunities based on self-performance
•    Employee stock purchase plan (ESPP)
•    Continuous professional development, product training, and career pathing
•    Generous global benefits

 

#LI-AM1

#LI-Remote