Paradigm shift: Technical Writing as a domain
Tech organizations have different views on Technical Writing models. In typical DISQO-style, we’re focused on continuous improvement through a test-and-learn approach that allows us to understand what works best for our organization. In an ever-changing environment, Technical Writers must be adaptable and take an agile approach when it comes to the Technical Writing model used at an organization.
In early 2022, we changed our model to reframe Technical Writing from a support or enablement function for existing teams, where Technical Writers were considered supporting members of stream-aligned teams, to a domain that owns Technical Writing products and tools and has a dedicated leader.
Previously, we had two Technical Writing teams, one for our enterprise products and one for our consumer products. Each had their own manager and different priorities and each writer was embedded into a number of different engineering teams. This model enabled us to achieve the immediate documentation goals of each team, but being in different teams meant we had to work hard at maintaining alignment across product portfolios.
After carefully analyzing the pros and cons, we concluded that this structure inherently led to ongoing material differences in the ways the teams worked, getting in the way of our long-term documentation goals. These differences were inevitable given the focus on different portfolios and each team’s responsibilities to different stakeholders with varying needs.
The benefits of one domain
The Technical Writing team now owns the technical documentation domain which includes:
- Product documentation
- Technical documentation
- An internal documentation website
- An external documentation website
- The information architecture of our documentation intranet and websites
With one Technical Writing team, we’re better equipped to innovate our documentation for maximum impact and business value, to govern consistency, and to increase transparency. Importantly, it also enables us to balance workloads.
For example, we are bringing informational product and technical documentation together into one location, creating a source of truth for our organization. The documentation translates complex concepts into easy-to-understand guides that are accessible to both product and engineering audiences. It drives value, as it provides information that is crucial for quickly onboarding new hires. It also provides a starting point for team members who want to learn more about our different products.
Innovate our documentation
Working together as one team allows us to exchange ideas and discuss best practices, thereby improving our innovation and the utility and accessibility of our documentation. Through regular touchpoints, we promote discussion about needed improvements and new ideas. We challenge each other to level up, to teach each other new things, and to apply what we’ve learned.
Ensure Technical Writing consistency
Together, we ensure consistency in our approach and create impact by continually improving how we work as one team. We’re now balancing the needs of different product and engineering teams with our overall documentation priorities. Also, we have one set of frameworks that we develop and follow as a team.
Increase transparency
Before becoming one team, our two teams had similarities, but also a different set of priorities and short-term goals for effective support where it was most immediately needed. This meant that we could not achieve our own goals for Technical Writing. Now, teams collaborate with us around a standardized process and transparent communications channels.
Feedback from the teams and domains that collaborate with us informs our continuous improvement. This is the best way to guarantee that we deliver clear, well-written documentation and document templates. For example, providing documentation templates for product managers and software engineers to use, helps our product and engineering teams during the software development life cycle and during onboarding. In addition, we’ve introduced a change to our Jira task creation flow: now, a ticket template automatically appears in a ticket upon ticket creation. This template provides guidance about the kinds of information Technical Writers need to complete the tasks. This reduces the amount of time Technical Writers must spend to collect information to complete the task.
Keep workloads balanced
As one team, we now distribute tasks equitably and writers support one another. Over time and product development life cycles, teams have differing needs for Technical Writing support. If the Consumer portfolio has more documentation needs during a specific time, we can allocate the work among the team members to deliver high-quality documentation more quickly while keeping workloads balanced. The same applies when needs of the Enterprise team arise.
Conclusion
Any changes we implement are crucial to achieving organizational goals. Being on one team and owning documentation as a domain helps us to focus on our product–a source of truth about DISQO’s products. We iterate upon our product, taking an agile approach and focusing on continuous improvement. It’s easier in an environment like DISQO’s where we are never satisfied with the status quo and always strive to make good better… and better best.
DISQO’s teams are very excited about the future and the role that improved documentation will play in supporting our people, our clients, and our business growth. It’s our commitment that Technical Writing at DISQO becomes a powerful and differentiating advantage to our business.