Your team is strong – you guys eat software development for breakfast. You get things done for the client, and the client loves you. Hell, your software is so good, it doesn't even need documentation! Right? Despite your confidence, I'd argue you need a writer anyway (or at least a point person on documentation). That said, I think some of your belief that you don't need a writer stems from your misunderstanding of what a tech writer does and how they function within the team. Here are four ways a technical writer can make a strong team even stronger.
User-level feedback on design and functionality
As a tech writer, it's my job to figure out who’s using your software, what they want from it, where they might stumble, and to provide them resources to help them through both regular process and stumbles. Because I approach the software from a position of empathy – putting myself in to the user’s shoes – I can frequently find areas of the software that are needlessly complicated or which could be improved from a user perspective.
Additionally, as I document the system, I'm forced to explain what it does, how it works, and how it fits with other systems or processes the user encounters. If I can't explain it, there's something wrong. Think of it like the 5-year-old test in science: if you can't explain it to a 5-year-old, you don't know the material well enough. Although this specific test would be a crude measure to apply to software – just like it is to science – it's instructive that if the tech writer can't explain it to the user, then either they don't know the functionality well enough to explain it yet, or the functionality inherently doesn't make sense.
This isn’t a dig on designers or engineers; they have their eyes on a somewhat different prize than the writer. But with a writer on your team, you'll encounter these issues more quickly and be able to address them before they become costly and time-consuming.
Find more bugs in the code
I'm casting no aspersions on the QA team. But the more QA your team performs, the more likely your team will catch and fix bugs in a timely fashion.
The first step in my own QA process is to go into the system and work through each process I describe. This is part of how I put myself into the shoes of the user – doing the work, encountering the questions and the problems, and figuring out the correct ways to solve the issues and answer those questions. But as I work through the various permutations of the process so I can help my user to the best of my ability, I often stumble upon scenarios that even QA didn't plan for, let alone the designer or developer.
It’s said that no system can be idiot-proof because idiots are so ingenious, so you can think of me as the idiot stand-in being ingenious on behalf of the team. Once I find these issues that only users with a serious misunderstanding of the system would find, the team can take that feedback and improve the system overall.
Collect the team's knowledge in coherent source of truth
Your team possesses a lot of knowledge about how the system works, how it’s designed to work, and how users should interact with it. Unfortunately, quite a lot of this fragmented knowledge has trouble circulating from brain to brain. This can be because it's not written down, because it's not well explained, or because people don’t realize their unique knowledge is unique, putting that knowledge at risk of being lost forever should the person who possesses is stop working with your organization.
Having a central curator of knowledge is huge to solving these problems. This doesn’t even need to be a writer; anyone can be the person whose job it is to run the knowledge to the ground, capture it, and keep it where it can be accessed by the team. The advantage of using a tech writer for this purpose is that we understand information architecture, the logical flow of ideas and topics from one to another, and we're able to use our writing skills to clarify and improve on previously feral knowledge to tame it and make it broadly useful.
Creating user documentation (of course)
Compared to the other advantages a technical writer can provide a team, the creation of user docs seems small. But I assure you that when your organization has high-quality user documentation, the entire organization benefits from it.
Comprehensive user documentation helps reduce support costs by giving the user a touchstone on system functionality before they have to start jumping through support hoops. This documentation doesn't have to be in the form of a long-winded user manual (and indeed, that's the least ideal documentation solution). Building on the point above that technical writers can provide significant help to the design process, the writer can provide insight on UI text that helps reduce questions, as well as the placement of tooltips and the creation of user tutorials that smooth the user's overall experience. All these fall under the purview of documentation (with a little overlap into instructional design), and help provide overall greater benefit to the user.