Photo by Alexis Chloe on Unsplash
Within the software industry, writers don’t always project a high-profile role. If you’re a writer in software, you may find yourself on the outside of projects looking in, or even worse, forgotten about until that last-minute documentation request. I am here to tell you that you can avoid this fate, and in doing so you can greatly expand your organizational value.
You start this this journey when you manage to get someone to ask you “What are you doing here?” At that point, whether it is a team or project meeting, a discussion on a content creation system, or another area outside of your normal purview, then you are on the brink of joining the party and becoming more than just someone who creates documentation. When someone does ask the question, think of the moment as the catalyst to providing broader value to the projects that you are a part of as a writer. Let’s look at some important techniques to get yourself invited to the party, and then to make the most of the opportunity.
What Sort of Parties are we Talking About?
The first question to answer about this journey concerns the type of parties to get invited to where you can increase and broaden your impact. The simplest example is meetings. While pretty much everyone loathes meetings for one reason or another, all projects have meetings to reach key decision points for a project. To be part of these decisions, you must be included during those decision points.
The key here is to select the correct meetings. For example, if your company does Agile development, you likely want to steer clear of a product team’s daily standup meetings. Aside from when projects are just starting or having an important release on the horizon, daily standups can be too frequent for a writer to always have impact, and this can cause the team to forget about your concerns by default. The better party in this case would be a retrospective (visit the Agile Alliance website for more information on terms and history) or a less frequent status meeting. Here, you have a seat at the table where you can discuss documentation concerns with minimal intrusion into a product team’s finer-grained work.
Typically, software development companies hold parties for a lot of tasks related to developing and releasing products. Since you can’t, and shouldn’t, get invited to all of them, how do you decide which ones to go for? To choose among other parties to join, first ask yourself what solutions are you working towards, and what topics do you feel out of the loop on that would get you closer to those solutions? For example, you may want to update your documentation from PDF and Microsoft Word files to an HTML site. Your company may already have systems in place to create this style of content. Or perhaps you’re thinking about your need for a good content management system. Likely as not, various groups in your company already use one or more content management systems. But before you can jump into these parties, you need to know where to look.
Where is the Party?
In my various jobs I have always sought to learn where I can expand my influence and how I can best get my foot in the door. I didn’t wait for an invitation. I took the initiative and inserted myself into the larger processes and key decision-making moments for our products. Sometimes this has been as simple as ensuring I was included in the right meetings for key projects and groups that I am a part of, which allowed me to stay informed on features and even to provide feedback and insight into the development process. In other instances, I delved deep into technology resources that were meant for other roles.
You can think of meetings as the loudest parties on your street, they’re fairly obvious to find. Just talk to your friendly project managers, developers, and other writers about what meetings are scheduled for the projects you are working on. Plan on being persistent, or you’ll find yourself forever waiting behind the velvet rope.
For those secret, invitation-only gatherings, your search will be a bit tougher. For example, I wanted to update our API documentation from static PDFs to a dynamic HTML site. Working for a large organization I knew that I could not be the only one with this goal. I first dug around to find out what documentation was available, and then I was able to find a group that created this style of content. Reviewing their resources on their platform helped me get up to speed on the process before asking for that first invite.
Join the Party and Prove Your Organizational Value
So you’ve found a few parties on your block you want to hop around to, now you have to find out exactly how to get that invite. Are the owners of these meetings and systems really going to want a writer around?
This is an excellent question, and one you must prepare to answer whether you’re asking to be invited or trying to sneak in. Either way, at some point someone is going to ask you “What are you doing here?” You need to be able to articulate your value, beyond the value to your writing projects. You must also be able to explain the value that your fellow partygoers will gain from your input.
When a project manager asks you why you have shown up for their retrospective, you should have examples of upcoming features you are hoping to learn about, or even instances in the past where product updates were missed in your documentation due to lack of communication. You can also remind them that they have surely had more than one request for some type of documentation for their project, and your presence gives them a simple, habitual way to discuss these topics with you.
If you’re caught doing a keg stand in someone’s Git repository, well you’re going to have to be ready for that too. For those systems that help reach your goals but are perhaps outside of what most might assume is a writer’s purview, you have to still think of your value as a double-edged sword. Clearly you have a goal in mind to improve your content in one way or another. For them, having a writer in their system gives them a new perspective, and you should also look at ways you can give back to the system or community you have joined. You may find they have been eager to document some processes or tasks, and this is just what you need to open that door.
Rules of Engagement
So you have found a few parties, you’re making an impact, but there are still some important rules of engagement to follow after you have proved your value.
Be Knowledgeable
You must be as knowledgeable as possible about the subjects relevant to the project. For example, when I found that API publishing system, I learned as much about the system as I could. While I still had a million questions, I was able to focus them on the available material, showing that I was willing to pay my dues. You can also try to find another partygoer to help show you the ropes. Keep this rule at the top of mind, as you must continue to learn and study as an active and helpful member of the project.
Stay in the Fray
Nobody notices a wallflower at a party, so you must remain engaged in whatever party you have joined. If you never offer any updates or feedback, you can quickly be forgotten about or devalued as a passive participant. That means you pick a schedule where you can have the right balance of being in the loop at a cadence that is most valuable to all members of the meeting. For other systems, keep up with recent developments and provide input where you can, or volunteer your assistance when it can be of value. This can take the form of being an active member of a forum that supports the service, or even helping others like you learn and join in too.
Know When to Fold ‘em
Finally, you must also know when and how to leave a party. I recommend being a bit brazen with the parties you join, so you may well find yourself in a party that seemed like a great place to be, but you find out later that you do not belong. Perhaps that Git repository does not support the workflows you need, or maybe the documentation solution you found does not support localization in the way that meets your documentation requirements. When this happens, it is best to be truthful and honest about why you are leaving. When you bow out gracefully at the right time, those who are sticking around will appreciate your candor, and they’ll be more likely to welcome you back if the situation changes and your presence is relevant again.
Conclusion
As a writer in the software industry, you can provide the most value to your organization by being bold and joining in on the discussions and processes that impact the projects you work on. You can probably tell that I’m pretty passionate on the subject. The techniques provided above will help you find the right parties, prove your value, and become a key contributor to their efforts. More importantly, I hope this inspires you to take that first step to be more engaged throughout your organization in the places where a writer may not always be expected, but can indeed provide great organizational value.
You may also enjoy:
Respect: Users’ Advocates Define It, Earn It, Keep It
Agile and Tech Comm: Writer Challenges in Agile and Traditional Development Teams
