Ask HN: How can technical writers be proficient working remotely
3 comments
Our team has recently been using team.video. They let you edit a doc in real-time alongside the video chat. Might be worth a shot especially during training and pairing.
I have significant experience building and managing remote teams, including across time zones. In my experience, much of the online discourse (HN comments, Twitter, and other ephemeral platforms with popularity-based upvoting) about remote work is a mixed bag. It's almost taboo to point out the significant problems, inefficiencies, and overhead of remote teams because everyone wants to believe that "remote work is the future of work". To that end, don't be afraid to make hard decisions where necessary to make your department work properly, even if that means moving away from remote work.
Remote work takes a special set of skills that not everyone has, and not everyone can develop effectively. Ideally you'd hire people with a demonstrated track record of successful remote work, but that's hard to find. Next best option is to hire people with experience at distributed companies with many offices around the country or the world. Those distributed, multi-office companies are halfway to remote work. If you can't find either type of employee, your third best option is to hire diligent employees and train them for successful remote work. Remote work attracts a wide range of employees from high performers who want more flexibility to low performers who want a job where they can blend into the background and do the bare minimum. Be prepared for some turnover as you identify the low performers.
Remote work requires more deliberate communication than in-office, in both directions. If you don't feel like you're overcommunicating or repeating yourself to the team, you're probably not communicating enough. Likewise, set expectations for more frequent updates and more detailed communication from your direct reports. Share a simple spreadsheet or document with all shared targets, status, assignments, and priorities so everyone can clearly understand the targets.
Encourage transparency. It's tempting for remote workers to descend into private messages, single-person phone calls, and privately shared documents where no one can see what they're doing. In my experience, it's better to set the expectations for where shared discussions and documents are handled. Create channels, document templates, and processes that encourage openness and information sharing. Unless you have specific secrecy requirements, everyone should be able to see examples of great documentation, feedback, process, and final products in a shared location. Practice mentoring the team in parallel in public rather than privately in 1-on-1s.
Develop processes that work best with one-off calls with engineering teams instead of letting the documentation teams ping engineers as questions come up. People tend to have better manners in face to face offices where interrupting someone to ask a question is visibly disruptive. Remote workers have a tendency to fire off Slack messages randomly throughout the day, generating massive interruptions and annoyance everywhere. Drive the teams to collect their questions into batches that can be answered asynchronously. E-mail over Slack whenever possible. Other teams will appreciate the effort and will be more likely to help out.
Minimize the number of scheduled weekly meetings. When you have a recurring meeting on the calendar, people tend to wait until that meeting to bring up important topics that should be addressed more quickly. Daily async check-ins can help, but set the expectation that everyone manages their own time and communication without waiting for scheduled meetings.
Performance management: Be strictly clear about what's expected, what good vs. bad documentation looks like, and don't be afraid to performance manage the under-performers. Keep an eye out for the sandbaggers who are taking weeks to accomplish what another person can accomplish in 1-2 days. Remote work is a magnet for people working multiple jobs, working on a side hustle, freelancing, watching children, or otherwise minimizing their working input. You don't need to force everyone to work 40 hour weeks, but you do need to clamp down on any temptation to sandbag.
Make life as easy as possible for the teams you work with. If you're coming in late and nagging the teams with interruptions and questions all day for weeks on end, people will loathe working with you. Instead, engage with teams early and often. Share a publicly-available process document that sets expectations for how other teams can work best with you. Emphasize the benefits of working with your team early to save time later. Put in extra effort to make it easy for the other teams. Avoid anything that pushes the real work on to other teams. Make it easy and enjoyable to work with your team.
Remote work takes a special set of skills that not everyone has, and not everyone can develop effectively. Ideally you'd hire people with a demonstrated track record of successful remote work, but that's hard to find. Next best option is to hire people with experience at distributed companies with many offices around the country or the world. Those distributed, multi-office companies are halfway to remote work. If you can't find either type of employee, your third best option is to hire diligent employees and train them for successful remote work. Remote work attracts a wide range of employees from high performers who want more flexibility to low performers who want a job where they can blend into the background and do the bare minimum. Be prepared for some turnover as you identify the low performers.
Remote work requires more deliberate communication than in-office, in both directions. If you don't feel like you're overcommunicating or repeating yourself to the team, you're probably not communicating enough. Likewise, set expectations for more frequent updates and more detailed communication from your direct reports. Share a simple spreadsheet or document with all shared targets, status, assignments, and priorities so everyone can clearly understand the targets.
Encourage transparency. It's tempting for remote workers to descend into private messages, single-person phone calls, and privately shared documents where no one can see what they're doing. In my experience, it's better to set the expectations for where shared discussions and documents are handled. Create channels, document templates, and processes that encourage openness and information sharing. Unless you have specific secrecy requirements, everyone should be able to see examples of great documentation, feedback, process, and final products in a shared location. Practice mentoring the team in parallel in public rather than privately in 1-on-1s.
Develop processes that work best with one-off calls with engineering teams instead of letting the documentation teams ping engineers as questions come up. People tend to have better manners in face to face offices where interrupting someone to ask a question is visibly disruptive. Remote workers have a tendency to fire off Slack messages randomly throughout the day, generating massive interruptions and annoyance everywhere. Drive the teams to collect their questions into batches that can be answered asynchronously. E-mail over Slack whenever possible. Other teams will appreciate the effort and will be more likely to help out.
Minimize the number of scheduled weekly meetings. When you have a recurring meeting on the calendar, people tend to wait until that meeting to bring up important topics that should be addressed more quickly. Daily async check-ins can help, but set the expectation that everyone manages their own time and communication without waiting for scheduled meetings.
Performance management: Be strictly clear about what's expected, what good vs. bad documentation looks like, and don't be afraid to performance manage the under-performers. Keep an eye out for the sandbaggers who are taking weeks to accomplish what another person can accomplish in 1-2 days. Remote work is a magnet for people working multiple jobs, working on a side hustle, freelancing, watching children, or otherwise minimizing their working input. You don't need to force everyone to work 40 hour weeks, but you do need to clamp down on any temptation to sandbag.
Make life as easy as possible for the teams you work with. If you're coming in late and nagging the teams with interruptions and questions all day for weeks on end, people will loathe working with you. Instead, engage with teams early and often. Share a publicly-available process document that sets expectations for how other teams can work best with you. Emphasize the benefits of working with your team early to save time later. Put in extra effort to make it easy for the other teams. Avoid anything that pushes the real work on to other teams. Make it easy and enjoyable to work with your team.
Thank you for the incredibly insightful reply! There are a few things in particular that stood out. I have worked mostly remotely during a period of my career, and I know just how important it is to maintain discipline and clear, constant communication.
I feel we'd be quick to identify low-performers, because it can get demanding quickly here. I'm a pretty hands-on manager for the time being, though always trying to foster autonomy as much as possible, but I know what the team is doing at all times -- we keep track of it with the help of allocation maps, and regular syncs with the dev teams that would leave little space for someone to... space out. The team keeps itself accountable, too: they wouldn't let anyone underperform for long, without trying to address it -- and mostly, in a very positive way.
The one-off calls with Engineering you mentioned, that's something I'd really like to highlight: it's been a mixed bag for us. As practice, I usually reinforced the need to collect all information needed in one batch and only then addressing the teams to get the answers needed. Sometimes, it just works, but there's always something missing. Following-up isn't always easy, and not everyone takes it lightly. That's when it's just easier to go and get 'em, in a 5 minute catch-up for clarification. Technical writers, per nature, are shy people, as are devs. Face-to-face interaction doesn't come naturally, but it's been known to work.
The problem is when other teams just choose not to reply. That's usually when I'm CC'ed, but there's good will established, those issues have been mostly overcomed.
As for the working hours: I am, and the company as a whole, is very flexible. I don't care what time they get in and what time they get out; I don't care if they're at home, as long as they're approachable when needed. I only care about them getting the job done. If they wanna go the same way that fella who outsourced all his work to China or something and then just validated their work? I'd promote them.
In its entirety, your answer was great. Thank you! I'll be keeping this all in mind, even share with the team right now. (Maybe not the part about shady promotions and all)
I feel we'd be quick to identify low-performers, because it can get demanding quickly here. I'm a pretty hands-on manager for the time being, though always trying to foster autonomy as much as possible, but I know what the team is doing at all times -- we keep track of it with the help of allocation maps, and regular syncs with the dev teams that would leave little space for someone to... space out. The team keeps itself accountable, too: they wouldn't let anyone underperform for long, without trying to address it -- and mostly, in a very positive way.
The one-off calls with Engineering you mentioned, that's something I'd really like to highlight: it's been a mixed bag for us. As practice, I usually reinforced the need to collect all information needed in one batch and only then addressing the teams to get the answers needed. Sometimes, it just works, but there's always something missing. Following-up isn't always easy, and not everyone takes it lightly. That's when it's just easier to go and get 'em, in a 5 minute catch-up for clarification. Technical writers, per nature, are shy people, as are devs. Face-to-face interaction doesn't come naturally, but it's been known to work.
The problem is when other teams just choose not to reply. That's usually when I'm CC'ed, but there's good will established, those issues have been mostly overcomed.
As for the working hours: I am, and the company as a whole, is very flexible. I don't care what time they get in and what time they get out; I don't care if they're at home, as long as they're approachable when needed. I only care about them getting the job done. If they wanna go the same way that fella who outsourced all his work to China or something and then just validated their work? I'd promote them.
In its entirety, your answer was great. Thank you! I'll be keeping this all in mind, even share with the team right now. (Maybe not the part about shady promotions and all)
On the technical writer part, though, we've had positions open for months on end, and have really struggled to hire people, particularly because we feel that to work in product documentation, they would really benefit from being close to our R&D department.
Things happen fast, and members of our group are being allocated dynamically to development teams, working alongside them when the time is right to actually produce the end-user documentation, all the while participating in the teams' ceremonies as much as possible.
We felt that, in order to acquire enough context to produce quality documentation, and to make sure nothing's lost in translation, they'd really benefit from being located here and being able to come to the office, be among the developer teams. Everyone's encouraged to work remotely whenever they feel the need to (comms through Slack and Zoom).
One additional aspect that we try to keep in mind is that the team's job is also to make sure that documentation is not an afterthought. Developer teams, as usual, are not very keen on creating documentation to start with, so it's our team's job to take care of the process more end-to-end.
We've tried being open to having remote technical writer team members, tried it unsuccesfully, particularly as we struggled with time zone differences, and a somewhat low quality of the documentation produced.
The problem in the near future, that will probably make allocation a nightmare for me, in particular: our R&D department is doubling its size this year... whatever they produce is clearly going to need docs and training.
What recommendations would you have, in your experience working with or managing technical writer teams, for being able to accomodate remote writers?