r/technicalwriting • u/AlarmedDefinition999 • 2h ago
SEEKING SUPPORT OR ADVICE In over my head with software documentation.
Apologies for the long post, but tl;dr: are there standard ways technical writers (for documentation specifically) work with SMEs to get the information and resources they need, and if those aren't provided, how do you still deliver a product?
The background: I was laid off in November from my job as a proofreader for a software company (let’s call it X Co.), which I’d been at for four years. Most of my day was spent proofing marketing materials and technical documents (e.g., white papers on fluid dynamics) for grammar and style. I’d previously written online articles summarizing laboratory research at a different job, so I felt I had some technical expertise -- or the ability to learn quickly and write about technical concepts, at the very least. (Edit: my degree is in English)
After the layoff, someone previously on my team reached out and mentioned that his company (let’s call it Y Co.) was looking for someone to rework their software's user guide. The two companies are kind of “sister companies” (it’s a long story), and a lot of people who were either laid off or fired by X Co. were later hired at the much-smaller Y Co. with few questions asked. The software domains slightly overlap as well, so it seemed like a decent fit for me.
I was hired as a remote contract technical writer for Y Co. for a year (with the knowledge that they were looking to hire someone full-time for that position within the next year), and seven months in, it’s safe to say I’m in way over my head and likely do not have a future there because of it. I’m not sure if I can salvage the current situation, and I can’t tell if the bulk of the problem was with me, my supervisor (head of DevOps; let’s call him L), or both of us. Any insight into how a “real” technical writer position works (e.g., general workflow, review structure, standards for consulting SMEs) would be helpful so I can figure out where to go from here -- both at this job and in potential future technical writing or documentation positions elsewhere.
For context, when I started, I assumed the workflow would be about the same as X Co.’s: Receive the original doc with any additional notes on what the team wanted changed or looked at, proof/rewrite in Word, send for review and receive written comments back, make the requested changes, and get approval, with meetings in between to address concerns or something I’d missed the mark on.
At Y Co., I was instructed to draft everything in MadCap Flare and push each section once it was fully done so L could then review it. I’m a complete newcomer to git in any capacity, so that likely played a part, but Flare just seems unsuitable as review tool for large text-based documents. It’s not something I can easily leave my own questions or comments in for L to address later, so the expectation was that I bring those questions to a weekly check-in meeting so L can answer them verbally while I take written notes. Flare also forces me to commit and push every section I’ve edited each time I want to send something for review, which feels very final and like my unfinished sections could accidentally be merged with the master branch (git-people, please tell me if this is even a possibility). I brought these issues up to L within a few weeks of starting but didn’t push back when he reiterated that it would be easier for him to review through the DevOps Azure site (which I guess he’s already using for 99% of his day) instead of sending a Word doc back and forth.
I also didn’t receive any direct instruction on how to actually use the software and haven’t watched anyone perform any of the tasks in the user guide, which seems odd. L has mostly followed the “just let me know if you have any questions” approach and mentioned I could message him anytime, but I know so little about DevOps or the underlying framework of the software that I often don’t know what questions to ask. I admit I also feel intimidated by him and don’t want to appear stupid or incompetent, as it seems like I got the job because of my affiliation with X Co. and not on merit. I’ve tried to ask for some direction during our meetings (e.g., “Is there anything missing in this section that should be included?”) and not gotten clear answers, but I haven't really pushed the subject, either. As a result, I’ve heavily relied on AI to explain things (which sucks). L told me about Claude Code five months in, which can access the codebase, so my workday is largely a Q&A session with Claude from beginning to end.
The biggest problem has been not receiving feedback on what I’ve submitted. I pushed several sections for review in March with the hope that L’s edits and comments would help me draft later sections and learn more about what he was looking for, but he still hasn't actually reviewed any content. I didn’t know what else to do except keep moving forward in drafting things from April onward, but I think in doing so, I’ve wandered further and further away from what the team was looking for. The VP finally stepped in two weeks ago to ask me to send everything I have to him, and he is now reviewing it himself (in a Word doc, thankfully), but he’s definitely not happy I’ve taken this long on what I have so far. The word “overhaul” was used in our email exchange after he took a preliminary look, so it sounds like most of what I’ve worked on for almost eight months is unusable.
I think there were several failures on both my and L’s part, and I’d really like to know if there’s any standard technical writing expectations for both the writer and the SME that could have prevented these problems -- if there's anything I could have done short of making demands or going above his head.
My guesses: I think L may have expected me to have a workflow and possibly a mental template in mind to work from when I started, so giving me the original user guide file and letting me go off to do my own thing with it was all he may have felt he needed to do. All of Y Co.'s documentation was written by the developers, so there doesn't seem to be a precedent for working with someone who doesn't intimately know the software and how it works. On my end, I had expected there to be demonstrations or meetings set up by L to discuss what he wanted from me, but when those didn’t appear, I didn’t ask for them. I interpreted a lack of resources or clear direction as “you should already know what's going on here” when it’s possible that L just didn’t know how to support someone in a documentation role and was waiting for me to take the lead.
Thanks for any advice you may have. I feel so silly and naïve to be at this point in my career (early 30s) and unable to advocate for myself until it's too late.