
Ask HN: How can technical writers be proficient working remotely - Onyros
For context, I&#x27;m the program manager of a technical documentation + training unit that recently got consolidated into a single team -- whereas in the past they worked on and were part of different departments.<p>On the technical writer part, though, we&#x27;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&amp;D department.<p>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&#x27; ceremonies as much as possible.<p>We felt that, in order to acquire enough context to produce quality documentation, and to make sure nothing&#x27;s lost in translation, they&#x27;d really benefit from being located here and being able to come to the office, be among the developer teams. Everyone&#x27;s encouraged to work remotely whenever they feel the need to (comms through Slack and Zoom).<p>One additional aspect that we try to keep in mind is that the team&#x27;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&#x27;s our team&#x27;s job to take care of the process more end-to-end.<p>We&#x27;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.<p>The problem in the near future, that will probably make allocation a nightmare for me, in particular: our R&amp;D department is doubling its size this year... whatever they produce is clearly going to need docs and training.<p>What recommendations would you have, in your experience working with or managing technical writer teams, for being able to accomodate remote writers?
======
julieplec
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.

------
PragmaticPulp
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.

~~~
Onyros
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)

