Scaling technical writing it into a business might be difficult because as a software engineer doing technical writing as a side gig, you will naturally gravitate towards creating tutorials and how-tos.
Which is understandable because these are contents that you had at one point or another relied on to train yourself and hone your coding skills.
These are content that were provided to you freely for consumption by developer communities.
It is usually a pleasure then to contribute back to these developer communities that have helped build you.
Getting paid creating these technical content makes it even more attractive an endeavour to embark upon. Sort of like killing two birds with one stone.
But there is a catch: you might also seek to earn more income from creating these technical content. And I must say, this is becoming more of a common occurrence for software engineers doing technical writing.
This could be spurred by a common reason: wanting to grow your technical writing side hustle into a full income source.
The most obvious approach might be to create more of the technical content you are already used to consuming and creating: the tutorials and the how-tos, usually around programming framework and developer tools.
This, of course, will only be possible if you keep applying to more paid technical content publication blogs (usually companies with developer communities) to become a contributing technical writer.
You can’t scaling technical writing career by taking this one channel because it’s un-scalable (in terms of income) for a good reason: you need wide and deep expertise across several technologies to keep up.
Let me break that down.
How not to Scale Technical Writing Career
While most software engineers would mostly have a wide knowledge of the different technologies that do exist (which is of necessity to enable them see how things work together on a higher level).
It is very rare to find software engineers with deep expertise in more than a few technologies.
Software engineers are not superhumans capable of mastering technologies within a few days or few months.
Most technologies require hours and hours of practice to develop real expertise in them.
This level of commitment makes it almost impossible for any software engineer to be able to handle more than a few technologies in their tech stack at any point in their career life.
As a software engineer, what this means is that you are limited in the amount of technical content (around developer tools, programming language and their frameworks) you can create.
Let me explain why.
Most paid technical content programs are usually a result of developer community writer programs hosted by companies for developers, which is often done by these companies to attract a community of developers to their product.
There are only a few instances of developer community writer programs that are not owned as part of a company. A good example of such is Smashing Magazine.
Most technical content publishing hubs for developers are mostly unpaid. Think of FreeCodeCamp.
The main returns for a contributing writer are the utility of having your content promoted to and read by a large number of followers (developers) attracted by these large publications, and the satisfaction you also get from giving back to the developer community.
This might not be enough returns if you also seek monetary rewards. In other words, you are left to turn to these companies and those “few instances” as your chances of getting paid for your technical content.
Most companies with developer community writer programs only publish technical content plugged around their own product. For instance, Alan AI Technical Writing Program:
However, there are also others who are open to technical content not necessarily about their product, but they are not very common. A good example of this is DigitalOcean.
The point here is to create technical content for these companies you must learn to use one or two of their products. This adds to your limitations.
Now, depending on your circumstance, that could be a challenge (we will talk about this challenge when we talk about “less popular techs” below).
Popular Technology Products and Less Popular Technology Products
Looking from a different perspective, we might also want to talk about creating technical content for popular techs like MongoDB and DigitalOcean versus creating content for less popular techs like 100ms and UploadCare. Regardless of which, there could also be some potential roadblocks.
Let’s peruse an illustration.
If you are an in-house software engineer working an 8-hours day job, your tech stack would most likely be defined by the tech stack in operation within the company you work.
It is what you live and breathe every single day. Your proficiency and expertise would be strongest using those techs than a tech you learned a year ago but never got a chance to use.
Given this expertise limitation defined by the company you are working with, you will thus be capable of creating technical content around these techs. Let’s call them company-defined tech.
Usually, it might be easy finding technical writing outlets for these company-defined techs since most companies tend towards having popular techs as part of their tech stack.
Which is true because companies are better off with techs that have won wide acclaim and have attracted a huge body of developers continually working to make these techs better and stronger.
This is also the reason there are more technical publication outlets for these popular techs.
But you will also agree with me that there is a lot of technical content on the web today around say, MongoDB, Docker, or AWS.
These popular tech products have so much written about them already that there is almost nothing to write about.
What this means is creating quality content is even harder for these popular techs. More expertise and experience are required to create truly authentic content that is worth paying for.
So depending on your level of experience with a popular tech, the amount of technical content you can create is grossly limited.
But on the flip side, less popular tech products might be a good ground, right?
There should be more chances of creating technical content. But really, are there more chances?
Like I said earlier, most companies gravitate towards popular tech products, and hence, might not use the less popular tech products for their operations.
So in a case where you pick up interest in a less popular tech product your company isn’t using, creating technical content for that tech might come with its own challenges.
Mostly, it would be a challenge relating to a lack of practical knowledge and how you want to accumulate it—to be frank, technical content creation is based largely on real practical knowledge.
Let’s illustrate with an example going forward: you want to create content for 100ms, a video conferencing software provider.
One way you might want to go about overcoming this barrier is you might be willing to devote the time to learn or use the tech product, in this case, the 100ms technical writing program.
But this might pose some difficulty too:
- Do you have the time to learn 100ms from scratch?
- Would learning it be worth it?
- Does it fall in line with your experience and expertise?
- Does it have a potential use case within the company you currently work with?
- How long before you master it, then before you are able to put a pen to paper to create technical content for it?
- Do you run any personal projects that it could prove useful for?
Answers to these questions would also lean on how long since the founding of the tech company. It is generally more difficult to find technical content gaps to fill for long-standing tech companies than it is to find for newly founded tech companies.
100ms was founded in 2020. So there might still be a lot of product use cases to exploit and write about.
So it might have wider technical content gaps that need filling. Perhaps, you might not need so much expertise and experience with 100ms to create an authentic technical content.
But you also have to think about whether learning a cloud-based white-label video conferencing software provider would be worth it.
Maybe you won’t learn about 100ms products after all if your area of expertise and experience is far away from dabbling into any video conferencing software or if it has no potential use case within your company or heck, you don’t have any personal project you might need it for.
So right there you have it.
With popular tech products, you might have to deal with having to command a high level of expertise and experience in order to create a few or several authentic content.
With less popular tech products like 100ms, you might have to consider if it fits with your past experience and expertise, if you have a potential use case for it, or if you have the time and effort to put into learning it—if it is not already part of your tech stack.
So here is the bottom line: this channel—writing technical content for companies’ blogs and technical publications—is largely un-scalable as an income option because it so tightly depends on your expertise and experience and other reasons I identified above.
Does this imply there are better options for scaling technical writing to grow your income level as a software engineer doing technical writing?
Well, it depends. But, you would have a better chance of growing your income if you open up to other technical writing niches. Exploring these niches will push your income limits further. However, it won’t totally eliminate them.
Exploiting Other Technical Writing Niches To Scale Your Technical Writing Gig
Here are some of the other technical writing niches you should consider exploring:
- API reference guides
- SDK documentation
- User guides
- White Papers
- Release Notes
You can check out the following articles as these technical writing forms have been covered by both to help you get a head start on which might interest you.
So there you go. Scaling technical writing career depends on a lot of factors and options but you can start by opening up to other technical writing niches
Depending on your circumstances and environment, certain technical writing forms might be more proximate to you than others, API reference guides being the most obvious for software engineers.
That’s a potential you can easily tap into to push your income limit even further as a software engineer doing technical writing.
So that’s it for this article. Hope you found it inspiring. Drop comments and your thoughts below.