I found this question in Stack Overflow's 2020 survey of developers.
Nearly half of respondents selected 'Hello, old friend,' which suggests that it can be common for specific tasks.
But is it really true, or is it just people that want to center a <div>?
Referencing resources represent one of the most underrated costs of building a software business. So, why do technical writing and technical documentation are not given more consideration, given that most people probably spend hours researching good information about the technologies they use?
Even if you admit it or not, technical documentation is present in the workplace. The difference is in the culture of how you document the knowledge. This is where technical writing skills are helpful.
Most of the time, the tech writings sit in private Slack channels, lost emails, and docs spread around various tools or bookmarks.
Committing time to product documentation and business processes widely available is essential for software companies because poor documentation can cost the company money...
...or, for some unfortunate souls, it can cost them two years of their life:
Although a company's cost structure depends on its product, marketing, and operations, several hidden expenses can be addressed by strengthening technical writing skills:
- Employee high churn. For developers, unrealistic expectations, a lack of documentation, and unspecific requirements rank highest in the category of Challenges at Work, according to the same survey from 2016.
- Dissatisfied customers or sales that are lost. Unhappy customers or potential customers are choosing a competitor with better documentation.
- A waste of employee time. The time employees spend attempting to find information is time they could be spending on more profitable tasks. An inefficient search can be made more difficult by poorly written or organized documentation.
- A high cost of customer service. It may be cheaper to provide a docs site than to have people answer similar questions in chats or tickets.
Why technical writers are important#
Depending on the product and the audience, technical writers have various writing styles. In a product-based company, technical writers handle most aspects of the docs website.
Just remember that tech writers are not the only ones producing technical documents, even though they are at the forefront.
Technical documents are a part of almost everyone's professional life. But don’t assume that anyone can write. Often, writing and editing are left to a tech person without any formal writing training or even basic skills.
Any software company that wants to become good at technical writing should have a technical writer on staff devoted 100% to documentation.
By doing this, developers can concentrate on building cool features while the tech writer handles the documentation.
TURN STATIC DOCS INTO INSTANT ANSWERS
Build beautiful knowledge portals that are easy to navigate, search and share
It doesn't mean that developers don't have to produce documentation. It is clear that developers have the most in-depth knowledge of the process specifics and are best suited to write a specific integration guide.
Rather than producing internal documentation, the technical writer should focus on creating user-oriented documentation. The goal of technical writers should be to simplify technical content without sacrificing technical accuracy.
That’s why tech writers do more than just write docs. Converting information that hardcore techies regularly use to information that people with zero technical knowledge can understand involves communicating with key stakeholders, managing expectations, and sometimes working with information that doesn't exist, or running from a meeting to another to keep things aligned.
Sure, not every business is going to work with a technical writer. And that's fine, not every company needs one, but for sure, everybody needs to get better at communicating.
You can always get better at communicating.
Getting better at communicating is a matter of practice. The first time you need to write a piece of content might be challenging, but there is no way around it.
There are technical writing courses from Google and this shows why technical writers are essential and how knowledge churn can cost software businesses more than developers' salaries.
We are documenting everything because it's required.
Now, don't document everything just because you read online that technical writers and documentation are essential to a software business.
Do your due diligence. Analyze if this is something that is costing you money or if it can improve your organization's efficiency and productivity.
It's important not to get into a situation where tech writers, developers or marketers write about the same things, especially when launching a new feature or product.
Frequently Asked Questions
Yes. Clear, searchable docs turn tribal knowledge into a reliable system—and that shows up as faster delivery, happier customers, and lower costs.
What strong documentation prevents
- Hours lost hunting for answers across Slack, email, or scattered files
- Rework from ambiguous requirements and unclear handoffs
- Deal risk when prospects can’t validate integrations, security, or setup
- Support backlogs caused by the same repeat "how do I" questions
What you gain
- Faster onboarding for customers and new hires (and lower churn)
- Fewer tickets and fewer meetings through self‑serve success
- Smoother sales cycles with credible, up‑to‑date references
- Higher adoption and activation from task‑based guides
- A single source of truth teams can trust
Quick math: Deflecting 20 tickets/week at 10 minutes each saves ~173 hours/year—before you count faster onboarding, fewer escalations, or reduced sales friction.
They make complex products understandable and usable. In practice, a technical writer designs, writes, and maintains user‑focused content without sacrificing accuracy.
Typical responsibilities
- Own the docs experience: information architecture, navigation, taxonomies, style guide, and tooling
- Plan and produce content: how‑tos, concepts, API/SDK references, integration guides, release notes, FAQs, onboarding flows, and troubleshooting
- Run a docs‑as‑code workflow: versioning, reviews, CI checks, localization readiness, and publishing
- Partner with engineering, product, support, and marketing to keep information aligned and current
- Convert tribal knowledge into repeatable processes and clear instructions
- Govern quality: terminology, voice and tone, and consistency across teams
- Measure impact using search analytics, ticket deflection, content health, and gap analysis
Bottom line: they ensure customers and teammates can find answers fast and get work done with confidence.
Hire when documentation debt starts slowing growth.
Clear signals
- Engineers keep answering the same questions in tickets or Slack
- Features ship faster than docs, and onboarding drags
- Sales cycles stall on technical clarity, security, or integration details
- Support volume and costs rise from repeatable issues
- Teams disagree on the source of truth or spend time reconciling conflicting docs
What you gain
- Focus: developers ship features while a writer owns documentation quality and consistency
- Speed: faster onboarding for customers and new hires, fewer handoff delays
- Quality: accurate, task‑based content that reduces confusion and rework
- Savings: fewer repetitive tickets and meetings, better self‑serve adoption, and lower churn
- Reliability: an editor‑in‑chief who keeps information organized, current, and credible
Quick ROI lens: Deflecting 40 tickets/month at 15 minutes each frees ~120 hours/year—often enough to cover a large chunk of the role’s cost, before factoring in shorter sales cycles and reduced churn.
Treat it as both a skill and a system. Start small, practice regularly, and bake it into your delivery process.
Practical steps
- Choose a single source of truth for docs and retire scattered files
- Define audiences and outcomes before you write; focus on tasks and jobs‑to‑be‑done
- Use templates for common doc types: how‑to, concept, reference, troubleshooting
- Create a lightweight style guide and shared terminology list
- Add peer and SME reviews; include docs in your definition of done
- Run periodic doc sprints to close gaps surfaced by support and sales
- Measure impact with search analytics, ticket tags, and page engagement
- Invest in training, such as Google’s technical writing courses
Rule of thumb: every feature ships with a task‑based guide, a concept overview, and updated references.
No. Document the high‑leverage 20% that prevents 80% of friction, then expand.
Prioritize with this quick filter
- Impact: Will it reduce common tickets, unblock onboarding, or drive adoption?
- Risk: Is it tied to safety, compliance, privacy, or data integrity?
- Audience and frequency: How many people need it, and how often?
- Effort and maintenance: Can we keep it accurate without heavy overhead?
Start with the top support questions and the first‑hour experience for new users.
To avoid redundancy
- Assign clear ownership and a review cadence for each content area
- Keep a content map and consolidate overlapping materials across teams
- Version and label docs so readers know what applies to them
- Archive or prune stale content regularly
- Treat documentation like a product with a backlog, roadmap, and update schedule