Years ago, when I first moved into marketing for a DevOps company, I wasn't walking in completely cold. I'd been a marketer for a while already, just not for engineers. By the time I joined the company where I work now, the standard vocabulary of cloud, containers, and CI/CD pipelines was second nature. What still slipped past me was the long tail: a new AWS feature, a niche tool a colleague had picked up on a customer project, an acronym I hadn't seen yet. I'd quietly write each one down and look it up afterward. Over time, the list got shorter. The habit didn't.
I'm a marketer. I don't write code. I don't deploy anything. My job is to take what the engineers do and turn it into words and images that make sense to other humans. Some of those humans are technical buyers. Many are not. And on most days, I sit somewhere in between.
Early on, there was a temptation, the same one most non-technical people at tech companies hit at some point, to try to close the gap by reading everything. Bookmark the Kubernetes docs. Subscribe to newsletters with names like “Last Week in Cloud”. Stay up at 11 pm trying to understand what "observability" actually means. I tried a little of this myself before realizing it doesn't really work. The problem isn't that learning is bad; the problem is that learning enough to be “dangerous” is much easier than learning enough to be “useful”. You absorb just enough technical vocabulary to start dropping a word like “orchestration” into a draft, and never quite enough to use it correctly.
What I slowly came to understand is that my job isn't to “understand every detail” like an engineer. It's to be a translator, and translators don't work by trying to become native speakers of the source language. They work by understanding their reader so well that they can hear, in advance, where that reader is going to stumble.
What I Actually Do Now
Here is the working method I've stitched together over the years. None of it is groundbreaking. Most of it sounded too simple to be useful when I first read about it. It is, of course, all genuinely useful.
1. The 1-and-5 rule
For every technology our team works with, I aim for two depths of understanding. For everything (every AWS service we ever touch), I want to be able to say one or two sentences. “AWS Lambda lets you run code without managing servers; you only pay for the time your code is actually running.” That's enough to recognize the term in a meeting without feeling underwater.
For the five or six things that show up most often in our work (Lambda, EKS, RDS, WAF, Kubernetes), I want to write five or six sentences about each. Not docs-level depth. Just enough that when an engineer says, "We should probably mention that EKS handles the orchestration," I know what that adds to the value proposition and which buyer it speaks to. It is astonishing how far this gets you. Most people, including most technical buyers, don't have a deeper grasp than this either. I just sound like I do, because I'm calm about it.
I mostly work on AWS terms and technologies, because we are a partner with them, and cloud tech is so much fun.
2. The metaphor comes before the message
Before I write a single line of copy about a piece of infrastructure, I try to find the metaphor. Not because the metaphor will appear in the final copy (it often won't), but because finding the right one proves I actually understand the thing. If I can't say “WAF is basically a bouncer for your web app: it checks who's coming in and turns away anything sketchy before it reaches the door”, then I don't understand WAF well enough to write about it yet. The metaphor isn't the destination. It's the diagnostic.
3. Ask questions, not "tell me about it."
Engineers are usually generous with their time, but it's expensive. When I sit down with someone on the team, I never lead with "Can you explain X to me?" That sentence is a black hole. They will pour two hours into it, and I will leave with a notebook full of acronyms.
Instead, I bring some specific questions. “Why would a customer pick us for this over doing it themselves? What's the most common mistake we see clients make here? If you had to describe this to your sister at a dinner table, what would you say?” Three questions, fifteen minutes, almost always enough. I also use AI and ask it to describe it like I’m five.
4. Listen for what the customer won't understand
In any technical meeting I'm in, I keep a side document open and write down every word I, the non-technical person in the room, don't immediately understand. I don't ask about them in the meeting. I just collect them.
Later, those words are gold. If I didn't get them on first contact, there's a good chance our buyer won't either. Sometimes the right move is to remove the word from our copy entirely. Sometimes it's to define it gently. Either way, my own confusion has become a calibration tool instead of a source of shame.
5. I am the first reader
When I review my own copy, I think about the audience. For example, sometimes I try to read it the way a CFO at a mid-size retailer would: someone who knows what cloud means but couldn't tell you the difference between EC2 and Lambda. Because of that, it is much more often the person who eventually has to sign the contract. If I, the in-house non-technical person, don't quite get what we're selling halfway through the page, I rewrite. My confusion is no longer a bug in the reader. It's a bug in the page.
For our events, we always make t-shirts. One showed a cat curled over a laptop with the line "SRE: Sit, Relax, Enjoy". Another had a cat at a small CI/CD pipeline with "Build · Test · Purr · Deploy" arched around it. The jokes only fully land if you already know what SRE is, or what a deployment pipeline does. But they also work if you don't, because they're cats on t-shirts, and cats are also a symbol of Turkiye. That balance is most of what I'm trying to do: write something an engineer will smile at, without losing the buyer standing next to them who is just trying to figure out what we actually sell. The lines on the shirts and stickers were mine. For all designs, huge thank you to our design team!
What I've quietly retired
A short list of things I've, mercifully, stopped doing.
I've stopped sprinkling “innovative”, “cutting-edge”, and “transformative” across pages where I couldn't think of anything more specific. Those words are not adjectives. They are upholstered. But yes, there are still some examples.I've stopped pretending.
I attend some technical show-and-tell sessions at the company, and 90% of the time I end up staying. I say “I don’t understand” sometimes; I'm just being honest. I don’t get shy about my questions. The ones that sound the most basic (wait, why would a customer want this?) are often the ones on which the entire content hinges.
If I could go back and find the version of me who was quietly Googling acronyms after meetings, I would tell her this: being non-technical in marketing at a deeply technical company is not as difficult as you think.
Your job is not to disappear into the engineering side. It is to stand between the work and the world and translate honestly, in both directions. You will never know what your engineers know. But you can learn to ask better questions than almost anyone else in the room, and you can write the sentence that finally explains, to the customer waiting on the other side, what it is they're buying.
Which, when you think about it, is a strange and lovely kind of job to have.
For the next blog, we will talk about:
Practical steps: How do I prioritize which technologies or terms to learn first in a new role?
Confidence: How do I handle situations where I feel out of my depth in technical meetings?
Collaboration: What are some tips for building trust and rapport with engineering teams as a non-technical marketer?
** Please follow our LinkedIn so I can get a raise. Thank you.