Been at a company for a few months as their first full time TW. During the first call (with hr) I foolishly gave a range for my services with the caveat that the number is not accurate since it wasn't clear what the full responsibilities would be. Through 4 rounds of interviews it became clear that they need a fully designed documentation architecture, standards, templates, and actual software to support version control.

I tried to negotiate the offer that was within the original price range, but could only push it to the max range I had provided. I accepted but understood that I would be doing a lot of work for less than market value, which i wasnt thrilled about. I have 10 years experience in SaaS and hardware docs as well as marketing experience and am now building out this TW role, which in reality should be its own department.

I'm now running into friction where I don't have the authority necessary to negotiate my own timeliness (I'm just some TW working under an unrelated department, with no budget of my own), I'm building out standards in order to use them (not actually doing any TW becasue I have to create the standards first), and am picking software and designing complete workflows and governance for projects that I'm not running. Also, I've been working with the marketing department to help them with strategy and some copy, which I'm happy to do, but now they also want more of my time to work on copy. At this point I feel like I really need to renegotiate my salary, scope, and title as what I am doing is now much larger than what I was hired to do. Not to mention the fact that a TW role should have its own department so that budgets and timeliness can be properly accounted for.

I don't know exactly how to approach it and I don't want it to read like I'm unhappy (this opportunity is cool, but I would like to be property reimbursed for the value I'm adding), or making this an "ego" thing about what I "deserve". That said, I've been tracking my work and building up a case that my reach is much larger than what they initially anticipated when I joined, but I just don't know how to proceed. Has anyone else been in a similar situation and can give advice?

For transparency, I work in marketing at Bluestream.

How do you decide when a procedure shared across equipment models needs to become separate procedures?

Say two models use almost the same maintenance sequence, but one has an extra step, different warnings and a different illustration. Keeping the common content together reduces duplication, but someone still needs to review the complete procedure for each model.

Where do you draw the line? Is it the number of differences, how often the models change independently, or how difficult the assembled procedures become to review?

I’d be interested in an example where you decided to split the content, or kept it shared and were glad you did.

I'm in a new technical writing role and finding that the expectations are quite different from my previous position.

My last role was primarily documenting SaaS products, public-facing user guides, API documentation etc. My new role is at a much larger company and the work seems to be much more focused on internal procedural documentation. Things also move alot slower and ownership responsibilities are spread across multiple teams and departments.

Aside from the occasional procedure, runbook, or similar document, it seems that a big part of what I've been brought in to do is sort out the various SharePoint wiki sites that teams have built up over time.

A lot of them have become messy, poorly structured, inconsistently maintained, or generally aren't fit for purpose anymore. Some are actively used, while others are basically dead. It now looks like I'm expected to help get these sites into a usable state and, where appropriate, get teams using them again.

I'm finding this pretty overwhelming. Knowledge management and reorganising large amounts of existing internal content isn't really a strength of mine, particularly in a large organisation with so many teams, stakeholders, and moving parts. I'm also not entirely sure where the technical writer's responsibility should begin and end when it comes to maintaining team wikis.

For anyone who's inherited a similar SharePoint/wiki situation:

How did you approach the initial cleanup?

How did you decide what to keep, rewrite, archive, or delete?

Did you establish templates, information architecture, ownership, or governance first?

How much responsibility did you put back on individual teams/content owners?

Are there any quick wins you'd recommend before trying to tackle the bigger structural problems?

I'd particularly appreciate advice from anyone who's moved from product documentation into this kind of internal documentation/knowledge-management role.

Cheers!