[DRAFT] Transitioning from Junior to Senior: 15 Intermediate Technical Writer Success Strategies

Now that I’ve worked in the Technical Writing field for a good number of years, I’ve established that there is more than just learning about technology (& associated concepts) and writing digital content that is part of this job.

There is also a project management side and product owner side of technical writing that took quite a while to get used to. While I was still starting out as a junior / entry-level / intern, most of my expectations was very straight. I remembered initially being assigned anywhere from the following straightforward tasks:

1. Rewording / changing a few sentences
2. Specifically content changes software developers asked
3. Reading content and making edits
4. Revising existing content

Fast forward to where I’m currently at in my career, there’s actually a lot of unspoken and unexpected challenges that really surprised me once I divided deeper into this job field. As mentioned earlier, there’s an implicit project management / product owner side of this job that entry-level Technical Writers may not be aware about. However, there’s also some additional hidden responsibilities to this role that makes this job more than just technical writing. Technical writing is secretly a multi-role position.

To help me deal and adapt to these different level of responsibilities, I’ve assembled a list of 15 success strategies as I journeyed from a junior / entry-level technical writer to an intermediate technical writer.

[BELOW IS A WORK IN PROCESS]

Strategy 1: Always Have a Project Management Level To Do List

When I was still an entry-level technical writer, I was usually assigned a maximum of 5 concurrent tasks. Most of the tasks were straightforward enough that it wasn’t really necessary to keep track of their progress. Then depending on the company needs/structure/culture, I actually personally experienced minimal barriers in being able to successfully completing my work in a timely manner.

However, as I was adapting to becoming an intermediate technical writer, this was no longer the case.

In one of my recent job positions, I once remember receiving as many as up to 20 concurrent tasks in a given work week. Although some of the assigned tasks were straightforward, the others were much more complicated than just “write X” or “edit Y”. The more difficult tasks required me to actually have a detailed to do list in keeping tracking of what I had to do. Some additional content I had to add for the to-do list includes some of the following details:

• Who / which SME I had to contact for a follow up or additional information.
• Which link/content I have to read to prepare myself for a task.
• When I have to finish a task by.
• Diagrams or information I have to research / prepare.
• Coding commands I had to review/test.

There were also so much more. However, the whole experience taught me that being a senior/intermediate technical writer wasn’t just about writing , it was also being a project manager for one’s own work.

Why specifically a project manager? Because I found that for much bigger writing projects, it was necessary for me to chair/organize meetings with several Subject Matter Experts. In these information-gathering meetings, I usually only get about a 70% draft done but the rest 30%, I had to wait for multiple SME to get back to me for the right information. It almost became a mini project that I was managing because although I could prepare a 70% draft, the rest the rest 30% depended on the SME’s own work and findings. Sometimes they knew the answer right away but other times, they had to actually add it to their list of tasks as well. I literally added a task for them to do!

Strategy 2: Like a Product Owner / Manager, Understand What Will Be Developed

When I was still an entry-level technical writer, what I actually enjoyed [and wasn’t too worried about] was that most of my work was spoon-fed to me. When I say spoon-fed, I meant that I received very specific and clear ideas of what type of work I will do and how I was expected to do it.

However, as I was evolving to an intermediate technical writer, it was less expected that I would be given any work. Instead, it was expected from me that I had to search for my work.

How?

My brief exposure to the Product Owner / Manager role makes me believe that this role is responsible for the development of a product, specifically future features and upgrades. For the Product Owner / Manager itself, there was some documentation writing that overlaps with technical writing. My job definition is that a product owner / manager documents what a product COULD be, technical writers will document what WILL be.

This COULD/WILL wording may be confusing so I’ll say it another way. Product Owner / Managers will plan and decide what is coming up in the next few days, weeks or even month. However, the Technical Writer will actually need to discover what the product decision in the next few days/weeks/months and prepare to document accordingly. In other ways, a source of incoming work for any Technical Writer is to keep track of what the product owners / manager have decided and prepare for incoming tasks.

Strategy 3: Like a Developer, Understand What is Being Developed and What Was Recently Developed

My early technical writing career focused more on editing existing articles rather than creating detailed new articles. When work did arrive, the developers made it clear what the changes were, so this made my workload minimal. Since I already come from a technical background, all I had to do was just read what the developer wrote and translate it to everyday language.

However it became much different once I’ve upgraded to an intermediate technical writer.

It was very clear to me early on that developers just want to develop. I understand their work load! I’ve been one myself during undergrad! They would prefer not to be bothered at all. Although in the past before, contacting a developer was met with little resistance when I was an intern or an entry-level worker, it became way different later on.

As an intermediate Technical Writer, I believe its important to respect everyone’s time, and the time that developers spent interacting with me should be time I use to do research. Specifically, rather than waiting for developers to tell me what I need to write, it’s better if I figure out what I should write on their behalf, without them telling me.

Developers typically log their workload somewhere. For some companies, these workload are usually GitHub merge requests that needs to be examined. In other companies, they provide detailed information on what they’re developing and have recently developed. In either situation, these workload records are actually implicit documentation requests that need to be addressed once developers are ready to release their product changes.

Once I’ve discovered this technique of keeping up with developers as they develop and release content, it became clear to me that as long as developers are doing something, there’s always an abundance of work any Technical Writer should monitor daily. This is to ensure the documentation is being written concurrently with the software development process.

Strategy 4: Test the Software like a Quality Assurance / Software Tester

Part of my regular documentation-writing process is that I always verify the software as I am writing anything. Not-so-surprisingly enough, I have lost count the number of times where I discovered a bug or a corner case that the QA/Development team did not account for. These bug/corner cases usually get translated into written bug reports that the software development team vastly benefit from.

Eventually, I actually upgraded my verification process by also incorporating complex test cases or use case situations to see if I can break the software. Why? Because if I can break the software intentionally, then an actual customer will do it unintentionally. You would be surprised that during my user testing experiences that I learned any specific person can interact and use a software in ways you cannot even fathom, imagine or consider!

If there’s even a chance that the software may not work in certain situations, then users should know and it should be documented accordingly.

Strategy 5: Benchmark and Edit Graphics Like A Quality UX/UI Designer

Early in my technical writing career, there wasn’t many opportunities for me to work on many diagrams. I vaguely remember during my first job, a 16 month internship that the only diagram work was editing a diagram for an UX/UI team that due to bureaucratic barriers, they couldn’t do it. Although it wasn’t officially part of my role, it did give me a brief hint that the rest of my career would be like this as well.

Fast forward to my current career, I’ve identified that being a technical writer is also being a backup UX/UI Designer. I wouldn’t say the job title of a technical writer is actually a technical writer, it should be more like a technical content creator. Why? Because, I would personally say that depending on the company, 5–20% of the role is all about generating detailed diagrams.

During my time with a fresh start-up, depending on the week, I would say that 50% of my work was actually generating diagrams than actual writing. Since I don’t have a UX/UI background, I had to actually figure out how to generate professional diagrams.

What I did remember during the early days of my undergrad, specifically first year was that benchmarking could be a tool for creating a decent product. I applied this same principle for generating diagrams.

For the start up company that I’ve worked for, any time that I was asked to create a diagram, I followed a specific structure.

1. Research my company’s competitor’s websites and collect their diagrams
2. After collecting the diagrams, isolate to the best 5–20 diagrams that were really the most engaging or informative.
3. Write down notes or extract the diagram sections that made the original diagram engaging/informative in the first place
4. Generate the diagram based on the engaging/informative sections from #3. During the generation process, try to create an unique version of the sections.
5. Present the drafted diagram(#4) to the supervisor. Make sure to also show them 2–3, they may find something way more engaging.
6. Supervisor provides feedback, and repeat 2–4 till supervisor is pleased with the final diagram.

Strategy 6: Identify and Join Your Company’s Relevant Communities

A recent book I’ve read called The 50th Law had Curtis Jackson[50 cent] discuss his strategy for financial success as a hustler in the dangerous neighborhoods he resided in. Curtis discussed frequent communication with the customers to ensure that his products was the most highest-quality.

In the earliest stages of my career, it was my belief that customer pain points were a hidden source of future documentation. The limitation or drawback to this was that there have to be existing customer support tickets to identify if there were any documentation needs. This was great when the customers contacted us, but what if there are pain points that customers themselves don’t know about? Or what if customers have pain points they don’t bother to contact us about?

There are further sources of implicit feedback for the documentation somewhere!

As I was advancing into my career, I’ve identified that every company is never alone. Even start ups are not alone. There are always online public communities that are relevant to any companies. These online community's [whether Slack, Discord, Reddit or sometimes in company/organization-sponsored message forums] actually provided a source of implicit feedback that I was able to proactively extract on a regular basis.

An example at the start of my career was where I joined the leading organization that governed the best practices of the company I was working for. Their weekly newsletter helped me find ways to my daily work such as upgrading the documentation and coming up with ideas to grow the company and collaborate with my coworkers.

Another example was during my time at a startup. I joined the community of my company’s competitors. By being within these communities, I was able to receive constant feedback of what didn’t work for our competitors, and use that to upgrade my company’s documentation accordingly.

So, now as part of any onboarding process for any company I work for or intent to work for, I immediately identify all online communities relevant to the company I’m at. This ensures I don’t just know about the company from the inside, I also know about the company from the outside.

Strategy 7: Don’t Just Write The Documentation, Create a Solution That Exceeds The Documentation Need

For the longest time at the start of my career, I was used to being asked on what to do and just do it. Most of my early work was mostly just editing a few sentences here and there, or merely changing stuff that needs to be updated. The entry-level work was mostly a) copy and paste, or b) translate and rewrite or c) review and update. However, as I was being assigned more complicated tasks, it soon became clear that merely doing what is asked is sometimes not enough.

As I was progressing deeper into my career, it became less and less about what I was asked to do, and it became more and more about what how I can best fulfill the originating documentation needs. The work that’s often being asked to be created is only the supervisor/customer’s idea of addressing the needs. However as I was progressing through my career, it became more apparent that the work being asked is sometimes not the actual work assigned to me! The actual work is somehow addressing the documentation needs in a way that exceeds the supervisor/customer’s expectations! To quote Henry Ford “If I had asked people what they wanted, they would have said faster horses.”

To do this, I had to regularly invent or innovate new ideas to address the underlying documentation needs. Of course, the supervisor/customer’s way of fulfilling the documentation could work in many cases. However it can be always encouraging to see if I can not only do what the supervisor/customer wants, but offer them something that exceeds their expectations?

How?

To reiterate what was mentioned before in Strategy 5 and Strategy 6:

• Benchmark competitor documentation to see if there’s something that I can also use or improve upon
• See if the community has any ideas.

Strategy 8: Idle Time Is Invention/Innovation/Inspection Time

In the early years of my career, I could complete my tasks with minimal issues. This created a lot of periods during work where I was merely waiting for my supervisor to give me more instructions while I figured out how to fill the time.

How?

By inspecting ways to bring more value to the company. For starters with any company, there’s always these small ways to improve the company that many C-level don’t have the attention or time to address. It’s not just limited to documentation, but every other aspect of the company. Likewise, small issues in the documentation are sometimes located all over the place that are just waiting to be identified and addressed. There are just the beginning of what can be done.

Over the years in my career, I’ve accumulated a list of optional tasks that I do during my idle to find ways to create value:

• Benchmark competitor documentation to see if there’s something we can also use
• Check the community for any new posts / chatlog that are of any interest / use.
• Inspect the entire documentation to see if there are any content need to be review.
• Review existing diagrams/documentation to see if they are up to date.
• Check customer support tickets to see if there are any customer pain points that could provide implicit feedback for the documentation.
• Identify what my direct supervisor is working on.

Strategy 9: Track Supervisor Preferences and Understand Their Work

What made the early years of my career easy was that there was a lot of smooth and clear communication that made what was expected from me very straightforward.

What made things difficult as I’ve progressed in my career was that my supervisors became more busy, they were less clear on what they wanted and it was more and more about I had to figure out best what they wanted. As mentioned in Strategy 7(identify the documentation need) and 7(invent/innovate/inspect), it was possible to outperform what the supervisor was looking for by doing additional relevant research that they may not have been aware about. However, the aforementioned strategy could only be accepted if there was some degree of freedom. There are other situations when the employer has a clear idea of what they exactly want, and they don’t want any deviations from what they want.

So what happens if the supervisor has an exact idea of what they want but is unavailable for comments?

The way I’ve addressed these issues before is to constantly keep a regular track of what the supervisor likes and doesn’t like. Specifically, what I did was continuously make a record of all the work I’ve done all that received some form of feedback to get an idea of what the supervisor’s vision for the work they’re receive should be like.

The positive feedback I’ve received creates a “model” of what they’re looking for while the negative feedback I’ve received indirectly tells me what to avoid or not do in the future. By using this process where I continuously identifying what the supervisor’s likes/dislikes, I overtime am able to predict what they’re asking before they even clearly announce it. This is very similar to recommendation algorithms that I’ve been exposed

While we are on the topic of recommendation algorithms, there are even some additional situations where the supervisor may not be available to provide feedback. They might be “OK” and then no positive/negative feedback provided. This happens when they’re busy and simply needs their subordinate [in this case, me!], to somehow figure things out without being told.

In this case, I’ve identify that the best indirect way of collecting the supervisor’s preferences is to actually examine the supervisor’s past/present/future work.

• Their past completed work shows a potential version of how they prefer work to be done. Likewise, any documentation they really enjoyed.
• Their present work shows what they can use assistance on. By finding ways to minimize/simplify their workload, they might be more available to provide more clearer feedback.
• Their future work is similar to the present work. Likewise, their future work also indicates the incoming work that is awaiting for me in the next few weeks/months.

Strategy 10: Always Take Meeting Minutes No Matter The Meeting Duration/Size

I’ve observed that early on in my career, it wasn’t really necessary to take meeting minutes most of the times. This was because the information delivered to me was simple enough that a respect reaction to them can be processed right away.

However, as I entered deeply into my career, meeting minutes became almost a necessity for any meetings. In fact, it became something that was needed daily. This included both physical in person meetings and virtual meetings. It even included non-official meetings where I was simply talking to a coworker or my supervisor? Yes, it even can include a 10–20 second quick conversation with a coworker about a small issue.

Why?

As mentioned sparingly in this blog post, technical writing is not just about technical writing. There is an implicit project/product management side to it that many entry-level technical writers are not initially aware. There’s constant comments that’s being sent my way that requires some attention to. These comments needs to be addressed in some form of relevant documentation work. When there’s only a few small tasks, they can manageable and forgotten about quickly.

However, when there’s a constant source of comments being sent my direction from multiple, they can no longer be simply placed in memory. It becomes necessary to write down all the constant source of comments. I even remember that I had so many comments once coming my way that I had up to 20 concurrent projects in a single week!

In terms of the attributes of the meeting minutes, when writing the meeting minutes I highly recommend adding the following:

• The day and time of the meeting. This is to refer to it in project management situations.
• The “author” of a person’s comments. This is if it becomes needed to ask the author for more comments.

After a meeting minute is composed, I recommend making immediate changes.

• If a comment is about a new task or change an existing task, make the changes accordingly in the master to do list[ As mentioned in Strategy 1]
• If a comment is about a supervisor’s preferences, add it to tracking supervisor preferences. [Review Strategy 9]

Strategy 11: Identify The Company’s Work Process Then Create Your Own Work Process

For any technology company, it’s expected that they’ll have a work process already set in the work culture. This work process will likely be their own modified version of the design-thinking process. Likewise, in the case of software companies, their own version of the agile methodology. For the companies I’ve worked for, the technical writer often is unspokenly expected to figure out this process and see where they fit in.

When I was at least starting out, I wasn’t really aware of how a technical writer would fit into the entire process. I was mostly just assigned the work and was mostly unaware of how I into the bigger picture of the entire company.

Now, that I’m more advanced, I find it necessary to quickly determine how the technical writer fits into the grand scheme of the company. For starters, as an experienced technical writer, I need to determine when the documentation is created. Here are five common scenarios of when the documentation creation process starts

• Before the software is even created
• When the beta version is created, before any testing
• When the beta version is created, after some testing
• When the final version is created and before released to the public
• When the final version is created and after released to the public

These five [and there are more] is just an example of finding out how a technical writer is suppose to fit a company.

The overall point I’m making is that product managers, client success team or a supervisor has an implicit vision on when the technical writer is suppose to get started on a project. There’s an overall process for each company where the technical writer would benefit from knowing how they fit into the company’s overall work process so they can adapt their work habits accordingly.

After figuring out more and more of the work process, it becomes easier and easier for the technical writer to prioritize tasks and organize their work schedule. The technical writer can then create how they can best utilize their skills/experiences based on the company’s work process.

Strategy 12: Ensure mutual understanding of work

Early on in my career, since most of my works

Every supervisor always have a vision of how the ideal work should be like from their subordinate. As an experienced technical writer, I find that assumptions can be deadly and clarification can be life-saving.

At least

1. Organize and Track Your work
2. Build a naming/organization system
3. Text versus Screenshots versus Video
4. Learn the tool developers are using.