Wednesday 4 December 2013

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?

Tuesday 16 July 2013

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.

Sunday 14 April 2013

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.

Tuesday 9 April 2013

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.

Thursday 21 February 2013

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

Tuesday 12 February 2013

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?

Tuesday 5 February 2013

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.

Thursday 31 January 2013

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.