With the recent media attention on Yahoo’s announcement that it is banning its staff from “remote” working, we thought it might be useful to look at the case for and against Technical Authors working from home.
The case for allowing remote working
They can do their jobs more productively without interruption from others. When Technical Authors are writing (which is approximately 50% of their time), it can often help their concentration if they can work in a distraction-free environment.
There’s less need for office space and related costs (telephones, desktop computers etc).
“Some of the best decisions and insights come from hallway and cafeteria discussions, meeting new people, and impromptu team meetings.”
Being a Technical Author is one of those roles where remote working can work well. However, it’s best to be able to have both options available – to have people who can come into the office within a short space of time, should there be an emergency. There’s a great deal of value in meeting people face-to-face, and to be part of a company culture (especially within startups), but it can help enormously if you can write in a distraction-free environment.
If you do work from home, you need to have a productive working environment, and be able to be self-disciplined.
You provide wonderful newsletters full of useful information. Thank you.
I’m a Senior Technical Writer in a small company, and I have one contractor working for me. We have come up against a challenge. <snip>… My team currently uses RoboHelp, which is not a collaborative, team tool for writing. The company likes to think the product addresses this issue, but they really do not.
I have searched for a writer-friendly product that allows collaborative, team writing on a project. Unfortunately, I haven’t found anything. What product do you recommend for teams working on projects together? Right now we have to share files, meaning only one of us can work on the project at any given time. This is a serious issue for us since we are in an Agile development environment where we support twelve developers. More will be added soon, but we there are no plans to bring on more writers.
In July 2010, Mark Prisk, UK Minister of State for Business and Enterprise said:
As the events of the past two years have made painfully clear, we must leave behind the over reliance on financial services and support a renewal in modern manufacturing, so we are able to grasp the huge opportunities of the low carbon age. The ideas, skills and innovations of manufacturers will be just as important to our economic future, as the mills and mines were in our past.
Ten years ago, you’d find many consultants raising the issue that an organisation’s ‘knowledge assets’ walk out the door every evening.
Today, that’s still pretty much the case.
Organisations found it was difficult to capture the knowledge locked in employees’ brains. Many invested in expensive systems that offered poor authoring environments and complex ontologies. Retrieving the recorded knowledge could be a dreadful user experience as well.
With the economic future of countries such as the UK being based partly on creating wealth from the ‘knowledge economy’ and Intellectual Property, and with the recent, exciting, developments in technology (such as the semantic web, screencasts, wikis and open source software) now is the ideal time to revisit the issue of how to capture, collaborate and disseminate knowledge within and without the organisation. For a business working in a difficult climate, it can be the equivalent of finding loose change down the back of the sofa.
This video on simplifying business, using the metaphor of organising a children’s party, made me smile and consider how successful documentation projects are managed.
The presenter is suggesting managers need to, in complex systems, give up rigid control from above. Instead, they should watch for organisational patterns, encouraging the good and discouraging the bad.
The key to managing a documentation project is often more about negotiation than control. Many technical authors have found a simple but effective “attractor”: bring biscuits/cookies along to meetings with Subject Matter Experts. Rather than focusing purely a rigid project plan, perhaps more attention should be given to identifying the additional “attractors” you can create (more “jelly and ice cream”) and the “boundaries” you can establish. These may be more effective actions toward running a documentation project successfully.
“The next Cambridge ISTC group meeting will be a discussion about how technical authoring teams work:
* how are teams structured (and do all the technical authors in the business work as a team)? * how is work divided between authors? * how do authors work with other people in the business? * what is successful about that way of working and what are the limitations?
We’ll hear about the experiences of 5 or 6 people who work (or have worked) in a variety of different contexts (as a contractor joining other authors in a company; as part of a permanent team of authors; as someone for whom authoring is only part of their job).
This will be organised as a relatively informal round-table discussion with lots of time for for Q&A and discussion.
Here are the details:
Date: Tuesday 5th August Time: 7pm Venue: Red Gate offices (Jeffreys Building, St Johns Innovation centre, CB4 0WS More detailed instructions are on www.red-gate.com”
The event is free and open to anyone to attend, but numbers are limited so please let them know in advance if you’d like to come.