On Writing for Publications

I’ve been fortunate enough to write for a number of publications under some fantastic individuals and have taken away many lessons via observations and from making mistakes while doing so. I figured I’d collate some of them so that I and any similarly incapable fool can avoid future bungles.

This article is largely written with freelance technical content writing in mind, as writing of that nature is where I most often find myself working with editors; however, it should largely be applicable generally. Don’t take my words as gospel, as they are anecdotal, and I can’t speak to their general applicability.

Write a Pitch

Pitching an article is a usual and typical part of the process during which you’re not just trying to convince someone to let you write something but also informing the person or entity of what you’re writing, how you’re approaching it, and giving a general idea of what form the final output will take. Often as part of the pitching process, you’re expected to provide an outline.

If you’ve already got a rapport, you might not be required to pitch an article and simply be given the go-ahead. In this case, pitch it anyway. Always pitch articles.

As mentioned, pitching an article isn’t just convincing someone to let you write something but also defining expectations and ensuring you’re on the same page and both understanding of the contents, direction, and scope. In the same way one defines a scope document when working with a client on a development project, a pitch helps specify the deliverable, especially when paired with an outline.

In any case, by pitching, you’re still helping solidify the aforementioned details of the article for yourself in such a way that you’re well equipped to move forward while minimising miscommunication. You’re going to figure out the specifics of what you’re writing yourself anyway, so you may as well share it.

You most certainly don’t want to complete your writing and send it for a review, only to find there is a discrepancy between what you’ve written and what they expected.

Don’t Let The Outline Define You

When one writes an outline, it is usually part of their pitch or the next step after. This is incredibly early in the process and often before comprehensive research and full exploration of ideas. You will stray from this, so it is crucial that you don’t let this define your draft.

If you try to write exactly to the outline you’ve defined, your work will be worse for it. Writing to a rigid structure results in rigid work, and this flies in the face of smooth-flowing prose.

To be clear, you don’t want to stray completely, as the outline is what you’ve provided and is to an extent what is expected, but working within the boundaries to construct something proper is the best call. If you need to stray an amount that you think might be found objectionable, then you should communicate that.

Communicate With The Editor

The editor is your friend, or at the very least someone you must collaborate with. Communication is key in all relationships, including professional ones.

If you send anything to an editor, make it clear what stage it is in. It is a waste of time and effort for both you and the editor if you’re writing a rough draft, and they think they’re handed a final. It not only makes you look like an unprofessional baboon who evidently can’t use words so good so well, but also it opens the door for premature proofreading.

Just as you shouldn’t prematurely optimise code, you shouldn’t prematurely optimise writing. You don’t want to unleash an editor crossing your t’s and dotting your i’s on a rough, early draft.

Take Feedback

When I was studying graphic design, there were entire units on articulating, presenting, and debating ideas. It was rightly drilled into my peers and me, as it is so important to understand that feedback is constructive, not hostile critique. Any editor worth their salt will be providing constructive feedback, not simply attacking you.

When you’ve poured time into something, it is natural to become protective and sensitive to what you might perceive as attacks. It is imperative that you don’t become defensive and understand that these are not attacks on you or your work but suggestions for improvement. You and your work are being built up, not being torn down.

All that said, one shouldn’t be afraid to push back against an editor either. If there is a turn of phrase or particular verbiage that you wish to include, fight for it. The person publishing obviously has the final say, but that isn’t to say you cannot challenge them on anything. Leave a polite comment explaining your reasoning. It might even be an opportunity to have your preferred version improved.

You’re collaborating, not combating. You share the same goal as the editor: to create the best output you can.

Use A Collaborative Writing Tool

As Terence Eden wrote, we’ve got to stop sending files to each other. Sending files back and forth is terrible and ends up with conflicting versions of files which must be resolved, usually by copying and pasting sections of text back and forth. It also makes it difficult to observe the changes made between versions.

Microsoft Word, Ellipsus, Collabora Writer, OnlyOffice Document Editor, Google Docs, Notion, whatever – use a tool that lets you write collaboratively. The bare minimum is the ability to edit text, comment on sections of text, and propose changes. Being able to have changes added as suggestions rather than direct edits is invaluable for permitting proper understanding and open discussion of changes. A nice to have, if possible, is the ability to see a changelog, so both parties can see when a modification has been made.

It is so much faster and allows asynchronous work. Catch something and need to make a few tweaks? You can do that without needing full back-and-forth communication. There is only one authoritative source and one less point of communicative failure.

Don’t Submit On The Same Day You Write

This advice obviously goes out the window faster than the contents of a spacecraft with a faulty airlock when deadlines and quick turnarounds are involved, but if you can avoid it, wait a little bit before sending off your draft.

Taking time away almost always reveals flaws or areas to improve upon. Your opinion on your own work is often defined by the delirium of temporal proximity. There is many a time I’ve written something and thought very lowly of it, or written something and thought very highly of it, and then returned to it even just a few hours later with an opposite evaluation.

There is also the case that you will be more willing to throw away writing when distanced from it. The sunk cost fallacy is diluted by time.

Provide a Dinkus and Bio

The editor or publisher is going to ask you for a dinkus or bio if the publication usually uses them. Don’t wait to be asked; just send one over with your draft. One less back and forth required. You might even consider hosting such resources somewhere so that you can drop a link with all that might be required.

If you’re writing your own bio, try not to hyperdate it. Unless imperative, avoid including things like your age or years of experience in definitive terms. If you need to, you can always write with slight non-determinate vagueness with text such as ’10+ years of experience’ to avoid being too rigid. If you do end up hyper-dating your bios, then you’ll be forced to reach out to update them frequently as an avoidable recurring effort and disruption, lest you leave them inaccurate.

Also make note of how other author bios across the publication are written, taking into account tense, length, and perspective. Don’t use the exact same author bio across publications. Different publications, even within the same sphere, have slightly different audiences and styles. Adjust your bio for each.