2020: Remote Work + Writing
It has been a while since I have written a series on here or Medium, so as this unique year comes to an end, I’ll try to highlight lessons from 2020 that were already known but have been magnified with the ongoing health crisis.
Writing is the key to remote teams
Regardless of your background, some of you may have dreaded having to complete a term paper or essay. The anxiety from having to complete 10 pages or 5,000 words made some of us scramble in the past. Writing has always been an important skill, but in a year where most white-collar jobs have transitioned online, it makes the difference between progress and chaos.
Now you may be asking yourself, why are you talking about writing? You are a Product Manager! As it turns out, a big part of being a product manager is capturing ideas, improvements, and plans on plain old UTF-8.
Here are my stats (powered by Grammarly) for the week of October 4 to October 11:
- 77,632 Words checked
- 362 Grammarly alerts (improvements)
- 3,450 unique words used
- Tones: Neutral, friendly, joyful, informative
- Since I started using the tool in August, I have written/reviewed 150,000+ Words
The above is not meant to be a race or a contest; it illustrates the scale of writing for a technology professional. This extends across roles, including even software engineers responsible for in-code documentation, general documentation, and their actual code. Yes, I’m also surprised how modern-day keyboards survive the usage.
A day in the life of a product manager as you now know requires A LOT of writing. But why is that the case? Why is writing this critical and why is it important for remote teams?
My Motto as a Remote Product Manager: Overcommunicate and Overdocument
- Strategy: The most critical thing to document at the very beginning of any project or effort is strategy. Why is this thing being done? What are the business benefits? How does it help customers? The strategy is an underrated piece of documentation but makes a world of difference when: prioritizing and engineering teams are making long-term decisions. Strategy documents evolve over time but they are the foundation for a focused effort.
- Dependencies: Distributed and especially remote teams need to constantly highlight dependencies. This goes well beyond daily-standups. Depending on the product, dependency mapping should be done before, during, and after sprints are planned. A picture is worth a thousand words so make sure you use diagraming tools to clearly identify component dependencies and task dependencies.
- Assumptions: You know what they say about assumptions already but if you assume things make sure you clearly specify why things are being assumed and whether those assumptions build into your dependencies.
- Decisions: Everything in a remote team should be driven by transparency but decisions should definitely not live in a one-off email exchange that gets lost when people move teams. Emails were not meant to be a decision registry. If you don’t capture and centralize how your decisions are made you should start now.
- Meetings: Meeting notes are a standard practice but if these are available via e-mail you already lost the battle. There are countless tools that allow for proper collaboration, recordkeeping of discussions and email is not one of them.
This leads me to the central point of this post:
Information Management is the difference between making sense of everything you write or losing it all to your storage device of choice.
Storing all of the above types of writing in isolated information siloes won’t do your team any good. You need to think very hard about how do you standardize your information repositories and need to agree on a system of record for them. In the past, I have used, and continue to use Confluence + Jira as that central repository. Over the years they have created features that allow you to capture all of the above points in a central place. I should say that communication platforms like Slack have their place but even if an exchange occurs there, it should be memorialized in your central repository even if via a link to the thread.
Remote work is not going anywhere and neither is extensive writing as a knowledge worker!
