How to Become a Technical Writer Without an Engineering Degree

Short answer: You do not need an engineering degree. You need one skill: reading something technical, actually understanding it, and rewriting it so a confused person can follow along. Your first sample can be a free tool's documentation, rewritten properly. Costs nothing but an evening.

---

My first technical writing sample came out of an argument about a washing machine.

We'd just bought one and my mother asked what the delay start button did. I checked the manual. It said: "Delay Start function enables deferred cycle commencement as per user preference." Which is a sentence that technically contains information and practically contains none.

I told her it should have said: if you want the machine to start three hours from now instead of right now, press this.

That was the first time it occurred to me that this could be a job. That the world is absolutely full of instructions written by people who forgot what it feels like not to already know.

And it still took me another four months to accept I was allowed to do it.

---

The wall almost everyone stops at

The assumption is that technical writing requires a technical degree. You see the job title, you picture a computer science graduate, you close the tab.

I did exactly that. Commerce degree, no coding, no idea what an API was. I read three job descriptions on a Friday evening and decided the whole field was closed.

What I eventually understood is that the technical writer's job is not to be the engineer. It's to stand between the engineer and the person using the thing.

And standing there, knowing slightly less is an advantage. Someone who built the system cannot see where a new user will get stuck, because to them nothing is hidden and nothing is surprising. To you it is. That gap is the entire product.

An engineer told me once, genuinely puzzled: "You wrote a step saying to create the folder first. We never write that." He wasn't criticising. He'd just stopped being able to see it.

---

Four months I wasted

Let me be honest about the part I did badly.

My plan was to build technical knowledge first, then start writing. Sensible-sounding. So I bought a Python course on sale for Rs 1,299, watched an API fundamentals series, and studied roughly two hours most evenings.

Pages written in those four months: zero.

This is a very comfortable trap. Studying feels productive and carries no risk of rejection. Writing something and sending it to a stranger carries plenty. So the brain finds another course.

To be fair, it wasn't a total loss. The API basics did become useful about a year later. But if I'd written one bad sample in week one instead, I'd have started four months earlier, and the sample would have taught me more than the course did.

---

Building the first sample

When I finally did it, the method was unglamorous.

I downloaded a free open source note-taking app. Its official setup documentation was so thin that installing it took me around 40 minutes for what should have been a six-minute job. Every other line assumed something I didn't know yet.

So I documented the whole thing myself. Screenshots at every step. Notes on the two errors I hit and what they actually meant. And a section at the end that was purely about what to do when it doesn't work.

Five hours, start to finish. One document in Google Docs. That's the entire portfolio I started with.

Those five hours got read by my first three clients. One of them specifically mentioned the troubleshooting section, saying most writers only document the happy path.

I had no idea "happy path" was a term. I'd written that section because I was annoyed my install kept failing.

---

What you genuinely have to learn

Two things, and neither is big.

Markdown, which is a formatting syntax you can learn over one cup of tea. Hash marks make headings, asterisks make bold, and that covers most of it. A large share of technical documentation lives in Markdown.

Then very basic Git. The name is more intimidating than the thing. You do not need to understand branching strategies or rebasing. In three years I've needed five commands, total. It took me about a fortnight to get comfortable, and for the first week I was quietly convinced I would break something permanent. I committed to the wrong branch more than once. Nothing broke.

That's it. Any free screenshot tool for the images.

People over-prepare here too. I saw someone on a forum asking whether they should learn DITA XML before applying for their first role. Get one client first. The tooling question sorts itself out when someone is paying you.

---

The first paid job

Rs 2,400. A 1,500-word installation guide for a small SaaS company.

I found it by replying to a thread where someone was complaining about a product's docs. I wrote a comment explaining which specific section was confusing and how it could be restructured. The founder messaged me the next morning.

The whole thing took 11 days and two rounds of feedback. In the second round they told me my tone was too friendly, because I'd written things like "don't worry, this is normal." Apparently that reads as padding in documentation, and slows down someone who is mid-task and scanning.

I cut it. Payment arrived three days after approval.

The lesson from that one project was that technical writing wants less of you in it. In content writing and copywriting, your voice is part of the value. Here your voice is mostly in the way.

Which I found deflating at first. Now I think it's exactly why these clients stay. Nobody replaces a documentation writer because they fancied a fresh style.

---

Where the work actually comes from

Job boards have given me nothing. Not one project, across something like 40 applications in my first year.

What worked was picking a product, reading its documentation properly, finding one real problem, and sending it to them unprompted. No pitch about my rates. Just: your setup guide loses people at step four, here's why, here's a screenshot of where I got stuck.

Most people never reply. Roughly one in eight does. But the ones who reply usually have work, because you've already demonstrated the thing they'd otherwise have to interview you for.

This also ties into choosing a freelance writing niche, because the narrower the product category you target, the less rewriting your pitch needs. Small companies and early-stage startups are the best target by a distance. Their docs were written by a founder at midnight and they know it. Larger companies already have a documentation team and a process you'd have to get through.

---

The part I understood far too late

The real skill in this job isn't writing. It's noticing confusion.

When you use a new tool and get stuck, the normal human response is irritation followed by working around it. A technical writer stops there and asks: why did I get stuck? What did this assume I already knew?

I do this everywhere now. ATMs, government forms, the settings menu on a car. And it turned out to be the thing that closes clients, because when someone asks what I'd do differently, I have a specific answer rather than a claim about being detail-oriented.

Honestly it's also a bit of a curse. Badly written instructions are now impossible to ignore and my brain starts rewriting them without being asked. My mother no longer asks about the washing machine, mostly because I rewrote that manual section and stuck it on the fridge.

So if you've got no degree but you do have the habit of noticing where things confuse people, this work is available to you. And if you think you should study a bit more first, I'd only say that I thought that too, for four months, and had nothing to show for it.