As a writer who needs to pay the bills, it’s easy to think of a dayjob as a necessary burden. But all those ours toiling away, in my case slogging through IT implementations, needn’t go to waste. I’ve found more than a few similarities between implementing an IT project and publishing a book that have come in handy as I try to transition from writing as an interest to writing as a part-time job.
Working in iteration
In my dayjob, products are usually released in multiple versions, each one, in theory, an improvement on the last. This process happens in writing too. My first draft gets a self-edit, then I run it by my alpha reader (aka my significant other), then the next version goes to my beta readers, then after that, another version goes to my editor. It’s a good way not to get bogged down trying to make things absolutely perfect the first time around.
Dependencies on other people
IT implementations involve teams. Even if you’re a one-person shop, you put on multiple hats: project manager, programmer, tester, business analyst, etc. Likewise, to publish a book, you have an editor, artist, test readers, bloggers who will help to promote your work, etc. Though writing can be very solitary, the act of putting your work in front of a wider audience makes the ability to work will in teams handy.
Vendor selection
On good IT projects, if there needs to be an outside vendor, there should be an organized process to evaluate the different options and try to iron out biases so the best solution is chosen. Easier said than done! I’ve found having a systematic approach, even simply listing out pros and cons, helps when trying to pick between editors or artists that sound equally good.
Working toward a launch date
In both IT and publishing, you’re working toward a release date. “Go Live” is like a book launch. Pilot releases are like sending out ARC’s. The problem with this analogy is that after you publish a book, you can’t really release patches to fix it, at least as far as I know!
Being organized and planning ahead saves pain
I can’t believe countless times in my dayjob where multiple phases of rework was required because things were rushed through the planning phase. A little pain at the beginning saves a lot of pain at the end. I can’t speak for everyone, but my writing style is heavily outline dependent. If I didn’t do a good job of seeing where things were headed or focusing on my through-line, I would end up writing in circles. The same goes for the publishing process. Time needs to be thought out and planned for in order for word to get out, ARC’s sent, artwork to be released and social media promos to take effect. You also need to build in time to edit, rewrite and format the work for publishing.
Finally, I shouldn’t omit the biggest similarity between my IT job and writing: long hours in front of the computer. Whatever techniques I use to stave off RSI applies to both!
Anyone else see useful overlaps between their dayjob and writing?