Beyond the Comfort Zone

This article first appeared in the Spring 2013 edition of the ISTC Communicator Journal.

Falling into Technical Writing is something a lot of us can probably relate to. Technical writing certainly wasn't a career choice I had in mind when I left university. Mind you, is it any wonder with a degree in accountancy and computer science that I ended up working for a company making software for accountants?

I've worked for Sage ever since I left university. Firstly as a developer, then as a project manager, and now as a technical writer. But none of this was part of a career plan. At times it felt like I wasn't making any decisions about my career and was merely getting dragged along for the ride. But after finally edging into a technical writing job, I found I was good at it, and have been doing this for six years. I've spent that time writing Getting Started Guides, and Installation Guides, and F1 help, and Release Notes and all the rest of it.

But, times are changing and recently I've come to realise that this job is changing. All fired up on this epiphany, I decided to take matters into my own hands and make sure I stayed relevant.

But, before I could do that, Project Dave happened.

Project Dave

We've developed a new software module for customers that's going to have a big impact on our customers and support teams.

But, why so difficult?

• This was going to affect a lot of existing customers.
• The software worked very differently to what our customers were used to.
• It introduced new concepts that were difficult to understand. The primary one being the iXBRL reporting standard adopted by HMRC.
• Strong competitors would be looking for any weakness in our offering.

In short, the product had to work, it had to be supportable, and it had to be easy to learn.

A project kicked-off with the aims of rolling out this module; minimising impact on our support team; and ensuring the best experience for our customers.

Initially, I was flattered that a manager recommended me for this project, only later asking myself whether that meant I was considered less fundamental to the development effort. Whatever it meant, this was a lucky thing for the Project Dave team, because I discovered I did actually have some useful skills.

How have I stepped outside my comfort zone?

Comfort zones are great aren't they? I've spent the last six years cocooned in a world of help files and style guides and PDFs. But, maybe comfort zones can become little jail cells as well. I'd got very comfortable in my technical writing role and rarely lifted my head above the parapets to see what else was happening in the company.

I was nervous stepping into that first Project Dave meeting. There were about a dozen people from across the business. I knew some of them, but I hadn't worked with them before, and I didn't know what was expected of me. Also, being honest, I was nervous about being landed with a load of work.

I still had my day job after all: writing the help file for this new module.

So, with a team made up from all across the business, we agreed to meet weekly to start this roll-out project.

The right words

What did I have to offer this team? I didn't know much about any part of the business outside R&D (Research and Development). But, in our very first meeting, someone announced that the aim of the project was to migrate our existing customers to a new product. The word migrate struck me as having negative connotations in the software business. Customers generally don't like being migrated from one product to another, so I proposed we use the word 'adoption' instead. And thinking more on it, the word 'migration' wasn't that accurate as we weren't proposing our customers stop using their existing software.

Maybe some in that meeting thought I was being pernickety, but if they did, they didn't voice it. What happened was from then on we used the word 'adoption' in all our communications with customers. Precision in language is one of our skills as technical writers, and we should encourage others to see its importance. A small victory then, but it gave me masses of confidence.

Coming up with a plan

On the face of it, we had loads of time to get our customers using the new module. But, after the initial comfort of believing we had twenty-one months until the HMRC deadline, the reality was, that with a tight development schedule, we only had about nine months to get our customers ready.

A comprehensive plan was a crucial part of the project. Over the years, I've learnt to become a great planner. If I didn't plan and tie in with the different projects I work on, I'd be overloaded. stuffed. I doubt I'm the only technical author who feels that constant pull in the directions of different projects and demands on their time. Technical authors are great planners. If we weren't, we'd be stuck as soon as the next project came along. So, contributing to a business-wide plan wasn't that difficult.

Hand-in-hand with planning is our ability to estimate effectively. Developers certainly have it tough when they have to estimate off the back of fuzzy requirements. But we've got to anticipate how much help their unfinished software is going to need, and try to guess how hard it's going to be for us to get our heads around the solution so we can write about it.

Planning and estimating are so vital to technical authors because we're often fitting in our work close to release deadlines, when the software is stable enough for us to play with.

Getting ready for the new module

Customers needed to understand a lot about the new module so they could start using it in their businesses. For example, although we were trying to make it simple by plugging a new module into their existing software, there was a good chance that when they got the installation disk, they'd just assume it was a regular update, and pay it no attention.

By the second week of Project Dave, I was seconded into a sub-team called the 'Need to know' team.

It was our challenge to shape these initial messages. We needed to get customers engaged with us and with our plans. As a team we agreed that I'd produce a guide for this new module.

This document needed to do several things:

• It needed to explain that this update was different. 
• It needed to explain about XBRL.
• It needed to encourage them to start educating their staff about the release.

It wasn't anything like the typical guides I'd write: it was more a hybrid marketing and technical piece.

This guide saw the start of some decent collaboration with product managers, marketing, support, training, R&D, all contributing to this guide. Once everyone had contributed, I used my language skills to shape this into something simple enough for the customer to understand.

The Learning Centre

One of my biggest contributions to the project was the Learning Centre.

Our help is delivered in CHM files that are installed on each workstation locally. This of course means that if we want to update our help, we have to wait for the next release of the software. I wanted us to get more into the online space to free us from release cycles and react faster to customer needs.

But creating a new help centre was not feasible for this project, so with no development time available, I suggested a simpler website where we could at least host videos and PDFs. I didn't even know how to get that off the ground but after working with our marketing team, the idea developed and we soon ended up with the Learning Centre website. It didn't cost us much, and was designed in such a way that I could produce material and with the marketing team's help, get new content to customers.

Besides its primary use for customers, it was a great resource to point our staff at to get them briefed on the new module.

Roadshow planning

We knew it was going to be difficult to get all our customers using the new software in the timescales we'd like. Roadshow events had worked well in getting customers engaged previously, so we thought they could help with this project. But what did I know about roadshow planning? Unsurprisingly little. But, all I needed to do was use my problem solving skills and I was able to contribute.

One problem we needed to tackle was an environmental one. We didn't want to waste printed material at these events, so I suggested we put recycle bins at the exits like cinemas do for 3D glasses. Might not be a great idea, but at least I was able to contribute. All I needed was to use my common sense and draw parallels to other problems that already had solutions. The lesson I learnt here was that it is so important to get past that fear of making suggestions in areas that don't relate to your specific role.

Usability testing

As technical writers, we're so close to our products that we should be great user proxies. I know when I'm writing a topic if I'm struggling because I'm having an off day or the process is clunky. But one thing was limiting my ability to speak with authority for our users; I hadn't spoken to a single customer in six years.

An opportunity came about to get involved with usability testing on the new project and I took it. The first session was done remotely, and the second in the user's place of work. On both occasions, I got to watch a user perform real tasks with the software I was trying to document. This was pretty eye-opening. Some things I'd assumed would be simple for a customer ended up being frustrating. This taught me that I need to get more involved in the development process from an earlier stage.

One of these usability sessions highlighted another skill we take for granted. The customer had noticed a spelling mistake in one of the software's reports. This totally dented his confidence in the program and he told us he was now wondering what else was wrong with the software. Technical Authors are great at spotting spelling mistakes, and this largely taken for granted skill, on this occasion, had a demonstrable impact on the customer.

Shaping external communications

I worked closely with the team on external communications to customers, and I learnt loads from doing this. Working closely with our marketing team on a communication was enjoyable. They have a great grasp of language, take time to make sure it's right, and they're receptive to feedback. I thought we were very alike.

I was also involved with the script our managing director would use in a webcast to our customer base. I reviewed it and made suggestions. It was crucial to get the tone of this right and make it seem as natural as possible. When I'd finished taking out unnecessary jargon, we had a script that was a great example of plain English.

Reviewing

Of course, it wasn't just me that would be writing user assistance for the new module. People from support, professional services, and the learning and development team would all be writing material.

I've seen work from these areas before, but sometimes when I review their work, I find stuff that other people miss. In short, technical authors are great at reviewing.

For one particular course, I reviewed the training manual that would go to print for our roadshows. Overall, it was a solid piece of work and did a good job in exploring the main areas of the new module to customers. But, there were issues with it. I was the fourth person to review, and changes had already been made based on the initial reviewers' feedback. But, when I came to review, I found missing words, typos, text alignment issues etc. Reviewers should be catching these things, but they didn't.

Is this because of a lack of reviewing technique? Are reviewers too polite? Do they not give these things enough time? Possibly. I know the reviewers cared, but I don't think that reviewing was their strongest skill. However, technical authors are great at this, and we can help teach others how important reviewing is.

Has this experience changed me?

I wouldn't have been able to contribute to any of these pieces of work without stepping out of my comfort zone. I used to think I was of most use to the business in settling down and doing what was asked of me - writing help files - doing them well, and on time. But, I took a risk and agreed to join a project away from R&D.

And I've learnt and achieved a lot.

What am I going to do next?

So, with all this going on what am I going to focus on next? Well, Project Dave is going to be continuing throughout the year and next, so I'll be working with that team for the foreseeable future.

As well as that, there are some other things that are happening that will continue to take me away from writing help files.

There are roadshows where I can talk to customers and demonstrate the software I've been working on.

I'm getting together with other user assistance writers in the business to start collaborating. We've started meeting now, and looking at how we can share best practice. I've been sitting with some of our support team, and reviewing articles they've written for our knowledge base system. This coaching has been really well received. We're going to be focusing on video production next, aiming to agree some standards on style.

My line manager, Chris, is a usability specialist in R&D, and a couple of years ago he suggested we teach our R&D staff about the Sage tone of voice and how that applies to our user interface in the software. Chris came up with a great workshop format and we present these together. He asked me to be involved as language is a vital component in the Sage tone of voice. So, we talk about how the messaging in the software is so important to users and how we can make it better. We held four sessions last year and expect to hold more this year. Our aim is to get everyone in our R&D department through the workshop. I've done one of these on my own, and it was a lot of fun. The attendees listened, and seemed to get a lot from the session.

Our learning and development team are focused on helping our people develop their skills and knowledge. They've recently put together a great website with a growing list of resources for our staff to learn from. But, they've been asking for volunteers to help produce some of this content. I've said yes as it's a good use of my skills. And beyond even that, I'm now the learning and development champion for our R&D team in Manchester.

What do you want?

I believe that we owe it to ourselves to shout about our skills. We're too quick to label ourselves and get trapped in our roles. Just because I'm a technical writer it doesn't mean that I can only write help files, or release notes. Project Dave was a lucky opportunity for me, coming at a time when I knew I needed to start stretching myself. Without it, I'd possibly still be keeping my head down and doing what was asked of me. But, we can't afford to hide behind the labels we give ourselves. We have skills, and if we need to learn more, we can do that too. Now is the time to look at yourself and your skills and get your employers to recognise that you can offer them so much more than a technical manual.

Checking in video files

arrgghh.

I'm due to get a laptop replacement this week and I'm only now realising how lax I've become in adding my video files to source control. It's a time-consuming error prone process when using VPN connections to the company network, but it's got to be done.

Why you should present at a conference

I wrote recently about stepping out of your comfort zone, an article that was derived from a presentation I gave at TCUK, the Institute of Scientific and Technical Communicators annual conference.

You can read it here.

I didn't want to present at a conference. That was the last thing on my mind when I had one of my regular meetings with my line manager in 2013. But, I came to realise that although I'm by no means an expert in technical communications, I haven't done this job for almost ten years without learning something. And that something may not be profound, or entirely original, but it is unique. That something is my experience, seen through my eyes, felt through my being. And that makes it special.

You might be thinking along similar lines. You might think that the only way to benefit from a conference is to go along and listen to speakers and take notes and go back to your office and share those notes with others. But you're wrong; that is the least interesting way to attend a conference.

Just think of what you might learn by setting yourself up as a speaker. You'll have the chance to really focus on a subject or your experience and share that with other human beings who want nothing more than for you to succeed. We are all interested in each other. We want to learn from each other. But the only way to do that is to open ourselves up to the occasional risk; to step out of our comfort zone and open ourselves up to the possibility that we will be truly marvelous.

If you want to consider presenting at this years TCUK, be quick! Deadline for submissions is 10 April 2015.

Beyond the Comfort Zone

Falling into Technical Writing is something a lot of us can probably relate to. Technical writing certainly wasn't a career choice I had in mind when I left university. Mind you, is it any wonder with a degree in accountancy and computer science that I ended up working for a company making software for accountants?

I've worked for Sage ever since I left university. Firstly as a developer, then as a project manager, and now as a technical writer. But none of this was part of a career plan. At times it felt like I wasn't making any decisions about my career and was merely getting dragged along for the ride. But after finally edging into a technical writing job, I found I was good at it, and have been doing this for six years. I've spent that time writing Getting Started Guides, and Installation Guides, and F1 help, and Release Notes and all the rest of it.

But, times are changing and recently I've come to realise that this job is changing. All fired up on this epiphany, I decided to take matters into my own hands and make sure I stayed relevant.

But, before I could do that, Project Dave happened.

Project Dave

We've developed a new software module for customers that's going to have a big impact on our customers, support teams, and really, for everyone in the business.

But, why so difficult?

• This was going to affect a lot of existing customers.
• The software worked very differently to what our customers were used to.
• It introduced new concepts that were difficult to understand. The primary one being the XBRL reporting standard adopted by HMRC.
• Strong competitors would be looking for any weakness in our offering.

In short, the product had to work, it had to be supportable, and it had to be easy to learn.

A project kicked-off with the aims of rolling out this module; minimising impact on our support team; and ensuring the best experience for our customers.

Initially, I was flattered that a manager recommended me for this project, only later asking myself whether that meant I was considered less important to the development effort. Whatever it meant, this was a lucky thing for the Project Dave team, because I discovered I did actually have some useful skills.

How have I stepped outside my comfort zone?

Comfort zones are great aren't they? I've spent the last six years cocooned in a world of help files and style guides and PDFs. But, maybe comfort zones can become little jail cells as well. I'd got very comfortable in my technical writing role and rarely lifted my head above the parapets to see what else was happening in the company.

I was nervous stepping into that first Project Dave meeting. There were about a dozen people from across the business. I knew some of them, but I hadn't worked with them before, and I didn't know what was expected of me. Also, being honest, I was nervous about being landed with a load of work. I still had my day job after all –– writing the help file for this new module.

So, with a team made up from all across the business, we agreed to meet weekly to start this roll-out project.

The right words

What did I have to offer this team? I didn't know much about any part of the business outside R&D.

But, in our very first meeting, someone announced that the aim of the project was to migrate our existing customers to a new product. The word migrate struck me as having negative connotations in the software business. Customers generally don't like being migrated from one product to another, so I proposed we use the word 'adoption' instead. And thinking more on it, the word 'migration' wasn't that accurate as we weren't proposing our customers stop using their existing software.

Maybe some in that meeting thought I was being pernickety, but if they did, they didn't voice it. What happened was from then on, we used the word 'adoption' in all our communications with customers.

Precision in language is one of our skills as technical writers, and we should encourage others to see its importance. A small victory then, but it gave me masses of confidence.

Coming up with a plan

On the face of it, we had loads of time to get our customers using the new module. But, after the initial comfort of believing we had twenty-one months until the HMRC deadline, the reality was, that with a tight development schedule, we only had about nine months to get our customers ready.

A comprehensive plan was a crucial part of the project. Over the years, I've learnt to become a great planner. If I didn't plan and tie in with the different projects I work on, I'd be stuffed. I doubt I'm the only technical author who feels that constant pull in the directions of different projects and demands on their time. Technical authors are great planners. If we weren't, we'd be stuck as soon as the next project came along. So, contributing to a business-wide plan wasn't that difficult.

Hand-in-hand with planning is our ability to estimate effectively. Developers certainly have it tough when they have to estimate off the back of fuzzy requirements. But we've got to anticipate how much help their unfinished software is going to need, and try to guess how hard it's going to be for us to get our heads around the solution so we can write about it.

Planning and estimating are so vital to technical authors because we're often fitting in our work close to release deadlines, when the software is stable enough for us to play with.

Getting ready for the new module

Customers needed to understand a lot about the new module so they could start using it in their businesses. For example, although we were trying to make it simple by plugging a new module into their existing software, there was a good chance that when they got the installation disk, they'd just assume it was a regular update, and pay it no mind.

By the second week of Project Dave, I was seconded into a sub-team called the 'Need to know' team. It was our challenge to shape these initial messages. We needed to get customers engaged with us and with our plans. As a team we agreed that I'd produce a guide for this new module.

This document needed to do several things:

• It needed to explain that this update was different. 
• It needed to explain about XBRL.
• It needed to encourage them to start educating their staff about the release.

It wasn't anything like the typical guides I'd write: it was more a hybrid marketing and technical piece.

This guide saw the start of some decent collaboration with product managers, marketing, support, training, R&D, all contributing to this guide. Once everyone had contributed, I used my language skills to shape this into something simple enough for the customer to understand.

The Learning Centre

One of the biggest contributions I've had to the project was the Learning Centre.

Our help is delivered in CHM files that are installed on each workstation locally. This of course means that if we want to update our help, we have to wait for the next release of the software. I wanted us to get more into the online space to free us from release cycles and react faster to customer needs.

But creating a new help centre was not feasible for this project, so with no development time available, I suggested a simpler website where we could at least host videos and PDFs. I didn't even know how to get that off the ground but after working with our marketing team, the idea caught steam and we soon ended up with the Learning Centre website. It didn't cost us much, and was designed in such a way that I could produce material and with the marketing team's help, get new content to customers.

Besides its primary use for customers, it was a great resource to point our staff at to get them briefed on the new module.

Roadshow planning

We knew it was going to be difficult to get all our customers using the new software in the timescales we'd like. Roadshow events had worked well in getting customers engaged previously, so we thought they could help with this project. But what did I know about roadshow planning? Unsurprisingly little. But, all I needed to do was use my problem solving skills and I was able to contribute.

One problem we needed to tackle was an environmental one. We didn't want to waste printed material at these events, so I suggested we put recycle bins at the exits like cinemas do for 3D glasses. Might not be a great idea, but at least I was able to contribute. All I needed was to use my common sense and draw parallels to other problems that already had solutions. The lesson I learnt here was that it is so important to get past that fear of making suggestions in areas that don't relate to your specific role.

Usability testing

As technical writers, we're so close to our products that we should be great user proxies. I know when I'm writing a topic if I'm struggling because I'm having an off day or the process is clunky. But one thing was limiting my ability to speak with authority for our users; I hadn't spoken to a single customer in six years.

An opportunity came about to get involved with usability testing on the new project and I took it. The first session was done remotely, and the second in the user's place of work. On both occasions, I got to watch a user perform real tasks with the software I was trying to document. This was pretty eye-opening. Some things I'd assumed would be simple for a customer ended up being frustrating. This taught me that I need to get more involved in the development process from an earlier stage.

One of these usability sessions highlighted another skill we take for granted. The customer had noticed a spelling mistake in one of the software's reports. This totally dented his confidence in the program and he told us he was now wondering what else was wrong with the software. Technical Authors are great at spotting spelling mistakes, and this largely taken for granted skill, on this occasion, had a demonstrable impact on the customer.

Shaping external communications

I've worked a lot with the team on external communications to customers, and I've learnt loads from doing this. Working with our marketing team closely on a communication was enjoyable. They have a great grasp of language, take time to make sure it's right, and they're receptive to feedback. I thought we were very alike.

I also got involved with a script that our managing director would use in a webcast to our customer base. I got to review and make suggestions. It was crucial to get the tone of this right and make it seem as natural as possible. When I'd finished taking out unnecessary jargon, we had a script that was a great example of plain English.

Reviewing

Of course, it wasn't just me that would be writing user assistance for the new module. People from support, professional services, and the learning and development team would all be writing material. I've seen work from these areas before, but sometimes when I review their work, I find stuff that other people miss. In short, technical authors are great at reviewing.

For one particular course, I got to review the training manual that would go to print for our roadshows. Overall, it was a solid piece of work and did a good job in exploring the main areas of the new module to customers. But, there were issues with it. I was the fourth person to review, and changes had already been made based on the initial reviewers' feedback. But, when I came to review, I found missing words, typos, text alignment issues etc. Reviewers should be catching these things, but they didn't.

Is this because of a lack of reviewing technique? Are reviewers too polite? Do they not give these things enough time? Possibly. I know the reviewers cared, but I don't think that reviewing was their strongest skill. However, technical authors are great at this, and we can help teach others how important reviewing is.

Has this experience changed me?

I wouldn't have been able to contribute to any of these pieces of work without stepping out of my comfort zone. I used to think I was of most use to the business in settling down and doing what was asked of me - writing help files - doing them well, and on time. But, I took a risk and agreed to join a project away from R&D.

And I've learnt and achieved a lot.

What am I going to do next?

So, with all this going on what am I going to focus on next? Well, Project Dave is going to be continuing throughout the year and next, so I'll be working with that team for the foreseeable future. As well as that, they're some other things that are happening that will continue to take me away from writing help files.

• There are roadshows where I can talk to customers and demonstrate the software I've been working on.
• I'm getting together with other user assistance writers in the business to start collaborating. We've started meeting now, and looking at how we can share best practice. I've been sitting with some of our support team, and reviewing articles they've written for our knowledge base system. This coaching has been really well received. We're going to be focusing on video production next, aiming to agree some standards on style.
• My line manager is a usability specialist in R&D, and a couple of years ago, he suggested we teach our R&D staff about the Sage tone of voice and how that applies to our user interface in the software. Chris came up with a great workshop format and we present these together. He asked me to be involved as language is a vital component in the Sage tone of voice. So, we talk about how the messaging in the software is so important to users and how we can make it better. We held four sessions last year and expect to hold more this year. Our aim is to get everyone in our R&D department through the workshop. I've done one of these on my own, and it was a lot of fun. The attendees listened, and seemed to get a lot from the session.
• Our learning and development team are focused on helping our people develop their skills and knowledge. They've recently put together a great website with a growing list of resources for our staff to learn from. But, they've been asking for volunteers to help produce some of this content. I've said yes as it's a good use of my skills. And beyond even that, I'm now the learning and development champion for our R&D team in Manchester.

What do you want?

I believe that we owe it to ourselves to shout about our skills. We're too quick to label ourselves and get trapped in our roles. Just because I'm a technical writer, it doesn't mean that I can only write help files, or release notes. Project Dave was a lucky opportunity for me, coming at a time when I knew I needed to start stretching myself. Without it, I'd possibly still be keeping my head down and doing what was asked of me. But, we can't afford to hide behind the labels we give ourselves. We have skills, and if we need to learn more, we can do that too. Now is the time to look at yourself and your skills and get your employers to recognise that you can offer them so much more than a technical manual.

This article first appeared in the ISTC Communicator Journal Spring 2013

Getting my own column

I’ve been neglecting this blog of late, but I haven’t been neglecting my writing. Check out my author blog to see what I mean.

But, things have changed a little. Ignoring the well heard advice of never volunteering for anything, I offered to take on a column for the ISTC journal: Communicator and am now in charge of the Online Groups column. This has got me thinking about my career—always a dangerous thing—and writing blog posts is always something I enjoy, and should add more value to the column itself. (Maybe one day, I’ll be able to just copy and paste a selection of blog entries into an article for Communicator and save myself a job).

For now though, stay tuned…

How I Learnt to Telecommute and How You Can Too

#85462182 / gettyimages.com

I recently read a great post from Scott Hanselman on his challenges being a remote worker.

Working from home can be great-when the circumstances are right. But it's not always great and sometimes it sucks. But the pay-off for me has been and continues to be massive. In short, I would fight tooth and nail to keep working from home.

In my career in Tech Comms working for Sage, I get to work from home two days a week; this isn't the norm. We have some full time remote workers and a fair bit of occasional remote working in our Technology department, but on the whole, people are working from the main office.

What common problems do I face working from home?

Technology

• We use Skype for instant messaging, but group chats can be pretty irritating. When I'm concentrating, I hide my Skype notifications as there is quite a stream of back and forth chat amongst the team. Yeah, it's good to see the agile team communicate on progress, but to be honest, as a Tech Writer, most of that chat is plain distracting. But, if I drop out of the group, I don't get dialled into the daily stand-up meetings.
• Meetings used to be pretty dire for remote workers: the organiser by default using the telephones for conference calls. Over the years, with supportive managers, and forward thinking, things are getting much better. Our main problem is organisers not giving themselves enough time to set up any equipment (speakers and external mic) that will help improve the experience for remote workers. Outside of the Technology department things are different. Teleconferencing over the phone network is still commonplace, and that always puts the remote worker at a disadvantage when contributing. If you're going to dial me in on a speaker phone, you might as well be shouting from a well.
• Forgetting remote workers. Still happens, and I never really understand why. If you're organising a meeting, and I'm invited, I'll let you know that I'm working at home that day and will either need dialling in or skyping in. Despite assurances that this will happen, there are still times when it doesn't. Physical bodies in the room trump the needs of remote workers every time.

Guilt

Do I feel guilty working from home? Yes, sometimes. But I've been doing it so long, and I've grown pretty thick-skinned so I don't care too much what others might think. Do I tell people that whilst I'm waiting for the kettle to boil, I'm also emptying the dishwasher? No. Do I mention that I don't start work until an hour later when I'm working at home so I can walk my daughter to school? No (or that I work an hour later to compensate). Do I mention that when my daughter comes home from school I come downstairs and see how her day was? No.

Do I feel guilty whenever I'm away from my desk? Yeah, pretty much all the time.

But the flip-side; I've come to recognise is that as someone not physically in the office, I'm not having long chats with colleagues in the kitchen, or disturbing them across the partitions, or all the other social activities that interrupt our days.

And let's not forget meeting guilt. Whenever the technology doesn't go smoothly to connect me to a meeting, a little part of me dies inside. It should be easy. It really should. I've done it myself. I know it's easy. And yet when it's not, and it goes wrong, and you can sense the daggers being thrown from the other meeting participants, I just want to apologise, tell the organiser 'it's fine' and that 'I'll catch up from someone else' and generally apologise for being alive.

Visibility

Being a Tech Writer in the office can be a fairly invisible role. A lot of the time we're working quite happily with the information we've got and I could easily go a whole day without needing to speak to anyone. At least being in the office means I can nod hellos to colleagues walking past my desk. Now that I'm working in Agile teams I get to go to the daily stand-ups and review meetings. This helps tremendously. Colleagues can see the work I'm doing (although I'm sure most of the time the nature of that work is lost on them), and I'm happy with that. Being out of the office on a regular basis contributes to the visibility problem.

But, it's not just my being visible that can be a problem. Working from home I can't just look up from my desk to see if such and such is at their desk to go and speak to. We have Skype but not everyone uses the 'away from desk' feature, and because people do the same as me in hiding Skype in their notifications tray, they won't always see messages. So, if I want to speak to someone, I have to ring, or email and that makes me think twice before getting in touch. Perhaps this is a good thing, I don't know.

The problems listed above are never enough to make me not want to be a part-time remote worker. In fact, if the opportunity came along to progress my career, with the proviso that full time office working was required I'd say no-right now. Here are some of the reasons I value my remote working so much.

• I save 5-6 hours a week commuting. This is time I get to spend with my family instead. Easy trade.
• I save £20 in petrol each day I work at home. That's approx £40 a week, £160 a month, £1920 a year...This is a big deal when supporting a family with two young children.
• I like the peace and quiet. When I'm in the middle of a piece of work, I love to just concentrate and get it done. It's so much harder when the impromptu desk meetings go on close to you at work, or the general drone of the office gets too loud.
• I get to see my daughter off to school twice a week, and generally see the kids when they're not knackered at the end of the day.

How can it be made better?

I've seen over the last few years that more and more people are doing the odd day here and there at home. Now I'm not saying that I'm in any way responsible for that, but all of us who do get the opportunity to work from home, need to demonstrate that we are good performers when we do work from home. We have to demonstrate this in our attitude to work, to our colleagues, and yes, show some appreciation to the boss. Our managers in the Technology group do make the effort to make sure remote workers are involved. I'm grateful for that.

We should become experts in remote working technologies to make it as easy as possible for people to work with us remotely. This includes knowing how to set up video calls, record screens in meetings, and use screen sharing technology such as join.me.

We should choose our battles. Know when it's worth fighting for more consideration and when it's not. In our large R&D meetings, our manager when asked a question will more often than not, repeat it for the benefit of remote workers who might not have heard. If he doesn't, or if the conversation goes back and forth, I keep my mouth shut. No one in the meeting room wants every sentence repeating for the benefit of remote workers.

Make yourself available.

• My desk phone is always set to divert to my mobile when I'm at home. I religiously do this before leaving the office.
• Skype is our department's preferred instant messenger. I keep in the group conversations for the various projects I'm working on, and always have my headset to hand in case someone wants to voice chat. My laptop has a webcam so can hold a video conversation if people prefer.
• Email. I'm not a massive fan of email and try to limit my exposure to Outlook to a few times a day, but I do check it regularly.

I'm sure that despite little slip-ups like Marrisa Mayer's edict for all remote staff to return to the Yahoo offices, that remote working is still going to continue to be more important for more people.

If you want to remote work, be warned that it's a considerable change in your day job. Perhaps a part time remote working arrangement would suit you better like it does me. But if you do get to have the opportunity to remote work, seize the chance to try it. And if you find it works for you, do what you can to make it work for others.

In short, become a role model and a brilliant remote worker.

Coaching our new Technical Author

Our technical writing team has grown from two to three in the last few weeks. Yes, our recruitment was successful and we now have a new bod to get used to our way of working, our projects, and our tools.

The new member is fresh from a support role and so despite having experience in writing knowledge base articles, hasn't written in a technical author environment before. There is a lot to learn, and we need him to be productive in a short space of time.

But, I was prepared.

The department had to go through an exercise last year, listing all the skills and experiences we each needed in our roles. This is essentially a checklist that can be worked through when assessing your own knowledge gaps.

I've taken a copy of this and used it as the basis for a learning plan.
Rather than throwing this in the direction of our newbie and expecting him to deal with it on his own, I've scheduled coaching sessions with him and we work through the spreadsheet. I'll demo something, and ask him to repeat the task or we'll talk about how he might use that in our real life projects.

I've never done formal coaching before, so I've no previous experiences to compare it with. But, we talk about how things are going, and our newbie seems happy that this process is working.

How to get the most out of coaching:

• Know what the point of the coaching is. Without this, you can't know when you've reached your goal.
• Discuss the coaching plan with the coachee. Does this suit their preferred way of learning?
• What other materials can support the coaching once the session is over?
• Involve the coachee in the session. I never let it go a couple of minutes without asking the newbie to try to replicate what I've just done.
• Ask for feedback. Remember you're doing this for their benefit, not yours.
• Don't be afraid to change your approach. Not everyone learns in the same way. Be adaptable.

Recruiting for a technical author

We're at the stage where we can reasonably request another technical author to join the team. Since this happens so infrequently, we're all a bit unprepared for what needs to happen. Development teams acquire programmers and testers so frequently that recruitment is a well-oiled machine, or at least a working machine. Not the case for technical authors. It's like someone's taken a mallet to our machine and springs and cogs have fallen far and wide.

We've had to consider:

• What's more important to us? An experienced technical author, or someone with the necessary domain skills in our business who can be trained up?
• What projects they might be working on.
• How we're going to get them up to speed. I've been working on a learning plan and it's eye-opening to see the things we're going to need to cover with a new starter, that I take for granted.
• How we're going to evaluate a candidate's ability to do the job.

This last point has been interesting. I've had a conversation with people on Linked in. I say a conversation, but it's become a little argumentative. There's clearly a lot of disagreement about whether it's appropriate to test technical writers at all.

The arguments against seem to fall into these themes:

• Some people aren't good at being tested and will steer clear from posts that require the candidate to take a test.
• It's not right that a manager should make a candidate take a test. The candidate gets no right to test the manager if they're capable of setting an appropriate test.
• Concern that a tech writer may be getting tested and other roles don't get tested.
• Does the test discriminate against anybody.

The arguments for a test:

• You can gain an understanding of how a candidate might approach a problem - would need discussion with the candidate after the test.
• You can set expectations with the candidate about the kind of work you'll be asking them to do.
• You can assess whether the candidate can work with standards.
• You can use tests to explain to managers why you might like to hire person x instead of person y. 
• You can verify their basic skills like ability to proof read and find typos.

Despite the disagreement in my LinkedIn conversation, we are going to have some kind of exercise for a candidate. As someone who's going to work with the newcomer, I want to see how easily we're going to fit together. If they struggle to do even some basic editing, or explain to me how they'd approach writing a topic from scratch, that's going to set some warning lights off—not literally, although that would be fun.

What kinds of issues have you had in finding a good candidate for a technical writing position?

Metawriting

I've been reading so many really good blogs recently about writing and it makes me a little sad that my blog feels so disjointed.

Trawling back through the archives I've got stuff here about my personal life, then more recently stuff about my job as a technical writer. But very rarely do I write much about writing.

Writing about the art of writing is a strange one. Painters don't draw pictures about what it feels like to have their hands covered in paint. Crafters don't string bracelets together to express their frustration at not having sold more than they have. Are writers the only "meta" artists?

So I'm wondering whether what I want to do is spend more time on the blog talking about writing, wondering whether in doing so I'll become a better writer. Or will it merely give me some false illusion of purpose? Metawriting isn't going to get my next novel written. In the time it takes me to write a decent blog post I could have added a few hundred words to my word count.

But will I gain anything as a writer in exploring these thoughts?

Undecided.

It's too easy to turn non-work into work if you let it

There's a certain irony in that I've volunteered to run a workshop on productivity at work, when this weekend, I've taken a look at my task list and deemed it unacceptable.

The theme of my workshop definitely won't be on how to get more done with your time as I'm more and more convinced that that way lies madness. Productivity for its own sake is a destructive exercise that ultimately serves no one apart from productivity gurus touting their wares. The focus has to be on making efficient use of the time you choose to spend on work, whilst remembering that you have a life outside of work that needs nurturing too.

We talk a fair bit about work-life balance and I think on the face of it, I've got this balance thing okay. But, then all I do is push myself to get more and more done with my non-work time, in effect taking all the play out of it, and turning it into more work.

This weekend, I came across Kim and Jason's Escape Adulthood blog and started to read their free ebook 'There's an adult in my soup'. This material really resonated with me today and certainly set some thoughts whirling away.

I'm not sure how that's going to affect my week yet, but I feel that it's going to have some impact.

How successful are online courses?

I read a good article about massive online open courses (MOOC) and thought I'd share my recent experience.

I signed up for MIT's Learning Creative Learning in February. This was the first I'd heard of MOOC's and I was pretty excited. I'd also just been appointed my department's learning champion so I figured a course that explored the theory and practice of learning would be great.

There are several learning champions in our division so I shared the sign up page with them first. I got one taker out of about ten people. Then I shared with the wider learning department, and got another six takers. Then finally, I shared with the rest of my department who I thought would be less likely to want to take part. However, as it happens, I did get another taker. So, that's eight and me makes nine.

MIT rather cleverly wanted to see how they could make this work to a large audience (somewhat in the area of 10,000 people signed up) and they choose to use Google+ as their delivery platform. This allowed them to start a community, and use hangouts for the weekly live discussions. They also split up the online students into rough geographical areas and suggested they set up their own communities for smaller group discussion.

I'd received a join code when I signed up and had shared this with the people in my business so when they signed up, we could be grouped together. When I sent out my first email to the group, I didn't get a single reply. Hmm.

After a couple of days and a couple more emails, I figured that no one in my company had actually gone through with the sign up despite being initially enthusiastic, so I joined another online group for discussing the material.

I found the first sessions really involving and although a little put off by the list of suggested reading (which they provided) I was pleased for taking part and felt I was learning something. I wrote a blog post after the second session and shared it with my new online group and had some good feedback. Time, as always, is tight and I was fitting this in after putting the kids to bed. Practically that meant I would start watching the recording of the live session at about 8:30pm. Each session is an hour. When the session is engaging watching the video is no problem at all and I would take notes to further encourage my brain to stay focused, but when the sessions were less meaty I was definitely struggling to stay interested.

Each week the level of reading varied as well. After the first week with a massive reading list that took a couple of hours to get through, there would be a week with no reading but projects involving Scratch (a tool to learn basic programming). This isn't the kind of thing you can pick up at 8:30pm so I pushed the activity back until the weekend. But weekend's, despite seeming a vast expanse of free time, very quickly get eaten with family and other activities. MIT tried to reassure online students that we should try to do what we could, but definitely not beat ourselves up if we missed the odd live session or activity. But still, I didn't feel like I was succeeding at what I'd set out to do.

I guess the point of this blog post was really to say that taking part in an online course is difficult. More difficult than I'd envisaged. Yes, I suppose for many, once the initial enthusiasm about starting something new wanes, it's always going to be difficult to stay motivated. And even though I can see real relevance to my work, it still feels like an activity I should do after I've got other things done.

I'm not disheartened about this experience. I've learnt things (about the subject and myself) and my eyes have been opened to a subject I had little appreciation of before. I know that I suffer a lack of focus and this has highlighted that to me again. The endless multitude of things to do and things to learn constantly distract me and pulls me in different directions.

We're now on week 8 which is coincidently called 'Motivation and persistence'. I'm going to watch the video and look through the reading list to see what catches my eye. After that, well I'm going to play it by ear.

Gears of my childhood

This post is part of an activity from the online course run by MIT: Learning Creative Learning.

Gears of my Childhood

I guess a lot of people might well have said that Lego was the object that influenced them the most in their childhood. I'm happy to be part of that crowd. Lego was a hugely influential part of my growing up and whenever I pick up pieces of Lego, my hands can't stop snapping the little pieces of bumpy plastic together to create.

How has it influenced me though? Slightly trickier. When I was young, it was all about the instructions, and making the toy that the picture on the box told me I should be building. That gave a couple of days play before the toy was broken down and never reconstituted again. I took more delight in making models from the shows I used to watch at the time. I remember building Airwolf several times, as well as the Thundertank, and plenty of TARDISes. In fact, I built a couple of TARDIS interiors only last month with my children watching in disbelief at their intense daddy hunched over their Lego box, taking all the best bits.

But back to that question about how it has influenced me. I like to consider myself a creative person. Could hours spent constructing images from my mind and memory be in some way responsible for that? I've never been afraid to take something apart to attempt to get it working again. Whether that be a broken PC, or fixing the chicken shed. Maybe that's part of the legacy it's left me.

The Doctor's TARDIS

The Master's TARDIS

Studies show that breaks are important shocker

Why Relaxation Is the Key to Productivity

So, should an effective scrum master encourage their team to take regular breaks, even when the pressure is on?

Working on multiple project teams

I've been asked by a colleague what my approach to attending meetings when working on multiple project teams and sprints.

This came up again at an end of project review where other team members are working on multiple projects at the same time. So, clearly in this age of scrum, this is a common problem for people.

One of the biggest problems with working across multiple sprint teams is that you spend more time in meetings. The more time you spend in meetings, the less time you obviously have to work in that sprint.

I've found this challenging. My default position was to attend all of the sprint related meetings for the two projects I worked on. This cost me 2 days out of 10. Effectively 20% of my working time was then spent in meetings.

As one of the projects neared its end phase, I dropped out of one project completely as I knew I just didn't have the capacity to do the work for both projects. Attending meetings for a project I wasn't working on, didn't make any sense.

Now, as one project has ended, and I've moved back to the other, those missed meetings have cost me a lot of understanding as to where the project is at. In essence, it feels very much like I'm back at square one with my work. The project's requirements have changed, and I'm finding that the work I've already done is out of date.

So, let's forget about that little blip. Let's assume I'm working on 2 projects again with similar deadlines. How am I going to approach my time?

What meetings do I consider important?

Very important

• Daily stand ups - Keeping in the loop is vital for sprint work. An efficiently run daily stand-up shouldn't make anyone would feel it was a waste of time.
• Sprint reviews - Get to see an overall picture of what the sprint achieved. 
• Detailed sprint planning - Get your tasks added to the backlog. If enough time is given between the high-level grooming and the detailed sprint planning, I don't see why tasks couldn't be emailed to the scrum master for them to include. This would get you out of this meeting as well. This depends on your role of course. If you're documenting like me, or testing, I don't see why you necessarily need to be present in the meeting itself - which often consists of developers hammering out the details of their approach.

Less important

• High level grooming - Again, depending on what role you have. User assistance is likely to be a secondary piece of work off the back of someone else's work, and is unlikely to be a user story in its own right. This changed for me towards the end of the project where I emailed the scum master to get 'finalising' activities added to the backlog, e.g. 'Finalise Installation Guide', 'Finalise Help system'.
• Retrospectives - Our teams distributed the results of the retrospective after the event, so I could catch up in my own time as to any actions. If I had a problem, I could email the scrum master outside of the retrospective.

I guess, it's always going to depend on what your role is, but I suggest that if people are feeling like they're spending too much time in sprint sessions then you should take a close look at the reasons why and try to address.

End of first project working within sprints

So, today I finished the user assistance on the first project where I worked within the sprint team. I need some more time to reflect on what I've learnt over this period and how I feel about going forward working in sprint teams. But, since I have to encourage others on the team to talk about what they've learnt over the last few weeks in our project review tomorrow, I thought I should at least make a cursory inspection of my initial thoughts.

Working in a sprint team has some benefits

• Someone else was doing the admin of managing my backlog tasks. This saved me some time.
• The team were more aware (not totally aware) of the work I was doing.
• I had more knowledge of what the developers were working on, and was more comfortable approaching them and asking for information.
• I got review tasks added to the backlog. This meant that people had time allocated them in the sprints to review my work.
• My motivation was quite high to get work done when I said I was going to get it done, because others were waiting to review it. Previously, it was relatively easy to delay tasks I didn't enjoy because no one had any visibility on my work.
• It was easier to track whether I was on progress.

But there are some downsides

• I never got all my tasks added into the backlog. I do a lot of tasks that don't make a lot of sense to the rest of the team, and are hard to package into neat sounding tasks to go in the backlog. As such, I worked in a sprint for longer than my official allocated work would suggest.
• Review days take a lot of time and its sometimes hard to feel them useful. Review meetings are fantastic chances to find where the project's at, but the planning meetings can feel long. I think this might be because my tasks still sit on the periphery of the main work, so I don't get involved with detailed task discussions.
• I think it gives a false sense of confidence. An example being this week when I was explaining about finalising documents needed for the release. Despite the right people being in the daily stand-up, it just didn't register with them. In the end, it caused the CD to be delayed a couple of hours. No big deal on this occasion, and things may improve in future. I now have some ideas for how to stop this happening again. It does make me wonder though, whether anyone understands what it is I actually do.

Should a technical communicator take part in estimating user stories?

For the convenience of writing in this blog, I need names for the two projects I'm working on. Let's call them Project Scissors and Project Stone.

It was time for a planning session on Project Scissors. I think this was an unusual case as the project was dealing with some new stuff that our team didn't fully understand. So, as part of this planning session the team wanted to estimate a series of user stories from the product backlog. To do this, they were going to use the planning poker technique. And they asked me to take part.

My question is:
Should a technical communicator be taking part in planning poker sessions?

A planning poker session would normally be used to estimate the product backlog and would happen before the sprints had started. In a planning poker session, everyone on the team listens to a description of the user story that needs to be estimated, and they all vote by using a pack of cards showing a number from the Fibonacci sequence.

Participants with high numbers or low numbers get the opportunity to discuss their reasoning with the team, and then another round is played. This carries on until a consensus is reached.

Developers get the chance to estimate testing tasks, and testers get the chance to estimate development tasks.

And then there was me. No one was estimating my user stories as I didn't have anything on the backlog - at that time.

So, was it OK for me to take part in the planning session?

My tactic (yes, I did have a tactic) was to never estimate lower than a 3 or higher than a 10. That left me with 3, 5, 8, and 10. My reasoning for this was I didn't want to have to justify my estimate to the team, and it made me 'fit in' with the team. Bit sad, but it worked.

But I clearly didn't contribute anything as I only understood about half of what was said in the room during the planning session, so in answer to my question - No, I shouldn't have taken part. I certainly didn't help the team reach an understanding of how large any user story was.

However, my inclusion did have a few benefits:

• I got the opportunity to listen to the user stories being explained. Yes, I might have had trouble understanding them, but then so did a lot of the team.
• I learnt more about the agile process.
• I got the opportunity to spend time with the team working towards a single goal. Some of the team are new to the business and up until that meeting, I really didn't feel like I knew them at all.

So, what do you think? Should technical authors take part in these estimating sessions?

End of first sprint

Last Wednesday marked the end of my first two week sprint on project A. What have I learnt?

• This isn't easy.
• I realised towards the end of the sprint, that I needed to get my work written as quickly as I was able so I could hand it over to the reviewer. It wasn't going to be acceptable to leave it until the last day.
• I have a good idea of what the team is working towards, and I haven't had to do any chasing to find this out; it's happened naturally by me being present in the daily stand-ups and planning meetings.
• I think the rest of the team have a greater understanding of the work that I do. For too long, there's been an expectation that user assistance will always be ready in time for the release. Now, the team can see my build this up over the course of the project.
• Not all project teams work in exactly the same way. Although the principles of Scrum are the same, how it's actually implemented is slightly different. There are different tools being used to track team progress, and even when the same tools are being used, they're using them in different ways.

TCUK - Beyond the comfort zone - Today you will not be writing a help file

In October, I was lucky enough to present at TCUK, the annual conference for technical communicators.

Here's the talk I gave about the need to step outside your comfort zone to help add value to your organisation.

Get the right people reviewing your work

Choose your reviewers carefully.

At the first sprint planning meeting, I was chuffed I had some User Assistance tasks added into the sprint backlog. It was a sign that we were integrating into the ways of the scrum. However, when it came to the reviewing task I'd asked to be added, I didn't pay enough attention to the purpose of the task, and therefore might have got it assigned to the wrong person.

The point of the reviewing task at this stage of content development, where the user assistance is very bitty, is to ensure its technical accuracy. I'm going to be looking after style and grammar, so what I need is for someone to tell me that the program works as I've described.

My instinct was to assign this piece of work to a business analyst, as I immediately consider them to be the subject matter experts. And that's true, when we're dealing with software written from specs, or full topics. But, when all I've got is five sentences outlining a rudimentary procedure, all I need is for the developer to tell me that I've got it right.

So, I might have got this wrong, for this task. But, the beauty of planning in these two week sprints is I can learn from this mistake and pay more attention next time.

Joining a second sprint team

I started with a second agile team today. This is a really exciting project and there's a lot to get my head around. So, joining the sprints has meant that although I've now got a lot more meetings in my calendar, I have also got daily access to the team putting this product together. That makes for a much easier experience when it comes to finding out what I need to enable me to write some user assistance.

And yes, my calendar is looking busier. With two sprint teams running concurrently (albeit a few days lag), there are now two days every ten working days that have the potential to get wiped out with meetings. And although there were gaps today, it was hard to get stuck into any of the high attentive tasks that I needed to get moving with. By default, the gaps got filled with easy stuff like answering emails, and filling in expense forms.

I don't envisage this remaining a problem, and even if it does, I'd sooner find myself with a bit less time, and with more information, than less information and oodles of time.

The tasks I got added were the three I added to the first sprint team's list.

• Write UA content
• Review UA content
• Update UA content

Although I only added them to one of the user stories.

There is definitely the potential for me to add a lot more to this project. There's still a lot I need to understand, and research on. I could have asked for a research task to be added, but I didn't see much need in it. If I'm doing a research task where I'm going to need input from the other sprint members then there's benefit in doing that, but otherwise, it felt like I was just clogging up the sprint backlog.

One thing I do need to sort out is my allocation spreadsheet. When you're working on one sprint team, it's easy to work out your capacity and plan accordingly. When working across teams, with different start and end dates for sprints, it's much harder.