A Technical Writer's Freelance Journey from an IT Background

There was a folder on my old work laptop called runbooks. Forty or so plain text files, all written by me, most of them written at two in the morning during on-call shifts.

I worked in IT support. L2, Bangalore, a mid-size services company. Whenever an incident repeated, I would write down exactly what fixed it so I would not have to think it through again at 2am the next time. Nobody asked me to do this. I was tired and slightly lazy and did not want to re-debug the same thing twice.

It took me three years to find out that this exact activity is a job, and that people get paid reasonably well for it.

---

The moment it clicked

A new engineer joined the team. During his onboarding I sent him the runbooks folder, mostly so he would stop pinging me.

Two days later he said something I did not expect. "These are better written than the company wiki."

I laughed it off. But it stuck.

That weekend I searched "technical writer" on LinkedIn and read maybe thirty job descriptions in a row. API documentation. User guides. Release notes. Knowledge base articles. Every single item on those lists was something I had been doing for three years, unpaid, under a different name, in a folder nobody outside my team had ever opened.

Honestly, that stung for about a week.

---

What I got wrong first

My assumption was that being technical was the hard part, and that the writing job would therefore be easy to walk into.

So I applied. Fourteen applications in the first month. Zero responses. Twenty more the month after. Two rejection emails, silence for the rest.

The problem was obvious in hindsight. My resume said IT Support Engineer. My portfolio section said nothing, because there was no portfolio. A hiring manager looking at that sees someone trying to escape support, not someone who can write.

And my runbooks were useless as proof. They documented internal infrastructure at a company I had signed an NDA with. I could not show a single line of them to anyone.

I had the skill and none of the evidence. Those are not the same thing, and the second one is what gets paid.

---

Building samples, which was genuinely tedious

There is no interesting version of this section. I wish there were.

I started going through GitHub looking for small tools with bad documentation. This is easier than it sounds. Most developer tools ship with a README that is one paragraph long and assumes you already know what the tool does and why you would want it.

I built three samples over about five weekends.

The first was a getting started guide for a CLI tool, roughly 1,100 words. I installed the tool myself on a clean machine, wrote down every step, and crucially wrote down every error I ran into on the way. That last part turned out to matter more than everything else. Almost all documentation describes the happy path. Almost no real user is on the happy path.

The second was an API reference page for a small open source project. Endpoints, request bodies, response shapes, error codes, one worked example per endpoint. Deeply boring to write. Also the single most requested thing clients ask for.

The third was a troubleshooting article pulled from my own support experience, rewritten generically so it named no employer. Something along the lines of why your container exits the moment it starts. Generic on the surface, but built from problems I had actually sat with at 2am.

Total time was maybe 25 hours. I also abandoned the project twice. There was one stretch of eleven days where I did not open the files at all and told myself I was thinking about it.

When all three were done, I put them on a plain Notion page with three links and a two-line intro. No custom domain, no design. It did not matter.

---

How the first client actually arrived

I expected the next step to be more job applications. That is not what happened.

An indie developer posted on Twitter that his tool's documentation was so bad that users kept asking the same three questions in his Discord over and over. I did not reply publicly. I sent a DM with three sentences in it: I had read his getting-started page, there were four places where it assumed knowledge a new user would not have, and if he wanted I could send a rewrite of one section.

He said sure.

I rewrote one section and sent it across for free. The next morning he asked what I charge.

And here is where I will be straightforward about the part most people skip. I had no idea what to charge. I searched, got three wildly different answers, panicked slightly, and said a number. He agreed instantly, with no negotiation at all. Instant agreement from a client almost always means you asked for too little.

It was a real lesson and it cost me money to learn. But I had a client, and my Notion page now had an actual company name on it, which changed the next pitch entirely.

---

What the IT background actually gave me

Earlier I said the technical background was not enough. That is true. It is a different claim from saying it did not help, because it turned out to be my biggest single advantage.

No client ever had to explain what an environment variable is. When someone said the endpoint returns 429 under rate limiting, I understood the sentence and the implication. A writer without that background loses hours of the client's time on exactly this kind of thing, and clients notice.

Terminal comfort was the second piece. I install the product, run it, and deliberately break it before writing a word about it. That is why my drafts contain the errors real users hit. It is not a writing skill. It is a support skill that happens to produce better writing.

The third one is harder to name. After three years of reading support tickets, you develop a reasonably accurate sense of where people get stuck, and it is almost never where the engineering team thinks it is.

---

What did not transfer at all

My certifications. Not one client asked. Not once.

And my technical vocabulary was actively a liability at the start. I wrote in jargon because jargon felt precise. My first client left a comment on an early draft that said it read like a Stack Overflow answer. That was not intended as praise.

Being technical makes things feel obvious to you. You stop noticing which parts are only obvious because you already know them. Unlearning that took me most of a year, and to be fair I still slip into it when I am rushing a draft.

---

Where it stands now

Three clients at the moment. Two developer tools and one fintech company's internal knowledge base. I left the full-time job around nine months in, after two consecutive months where the freelance income landed near what the salary was.

It is not steady. Some weeks are empty. Last month a client paused a project without telling me and I spent almost three weeks sending polite follow-up emails into a void, which is its own particular kind of annoying.

But I have no interest in going back to a ticket queue. I still remember exactly what 2am felt like on that shift.

If you are in IT and you can write, the path is there. A technical writing career is possible without an engineering degree at all, so having the background puts you well ahead. You just have to make it visible to someone, and building a portfolio from nothing is the only route I have seen work.

I still write runbooks. They just get invoiced now.