ITauthor

A lot of people still think that you need an iPod to listen to podcasts. Podcasting was lucky to piggyback on the phenomenal success of the iPod and the result was a lot of people listening to podcasts who wouldn't have been if the iPod had never been invented, or if podcasts hadn't been called podcasts. However, the name podcast has also had the downside that lots of people assume podcasts require an iPod. So there are lots of people out there with MP3 players, PDAs and media-playing mobile phones don't realise they could be part of the podcast-listening community. I've been listening to podcasts since mid-2005 but have never owned an iPod. I started listening by just downloading MP3 files and playing them on my PC on Windows Media Player, then got a PDA and started using that, transferring files over from PC to PDA via ActiveSync (a painfully slow process). I then discovered podcast clients that handled the downloading for you, and settled on Juice as the best of them. Then, after the PDA packed up, I was using a little stick-like MP3 player, again manually transferring files across from the Juice download directory onto the MP3 player. Finally, last year, I got a company Blackberry Curve, which includes pretty decent music playing software, and I started using that. I used the Sync feature in Windows Media Player to copy files onto the Blackberry. But it was still a little bit of a manual process to have to open Media Player and click Sync > Blackberry. What I wanted was the seamless experience of the iPod and iTunes, where syncing happens without any manually effort other than plugging in your iPod.

The following instructions tell you how to achieve this. It's a bit geeky I admit, but once you've set it up you don't need to do anything but plug in your MP3 player, phone or PDA and it gets loaded up with the latest podcasts you want to listen to. Additionally, it deletes old podcasts for you, so you don't have to do that manually to free up space for new stuff.

The method requires the following (more detail in the instructions below):

• A Windows PC
• An MP3 player of some description that shows up as an external storage device in Windows Explorer (in my case my Blackberry Curve
• Perl installed on the PC
• A couple of Perl scripts written by me (see below)
• A podcast receiver such as Juice
• Microsoft SyncToy

Of the above, you only need to pay for the hardware - all the other items are free downloads. So here are the setup steps. Read the rest of this entry »

Finding the right person for a job is a little bit like finding the right house. Any time I've been looking for a new house it's been because I've moved somewhere new and I need to find a house within a defined timeframe. I've taken on a six month rent initially just to give me a chance to settle in and get to know the area, and I don't want to find somewhere right away because I've just committed to six months rent. So I give it a few months, settle into my new job and then start looking for a house. That means, in reality, I've maybe got three months to find a house and move in so that I don't have to pay another six months' rent.

The point is that you only get to choose from what happens to be available within that little time slot. Despite the fact that this is the place where you're going to live for the next few years, maybe many years, you have to choose from the few properties that happen to come up for sale right when you've looking.

Filling a position within a company is a bit like that. As the recruiter, you've got to choose from what's available. And if you've got a good recruitment agency working for you, and you're lucky, you might just get some great candidates applying. Now what you've got to watch out for is that you don't blow your chance of getting a great candidate take the job.

A great place to live will be lived in for years and years. The people who live there will be in no rush to leave. So that house maybe only comes up for sale once every twenty or thirty years. And when it does, it'll be sold in a week at the price the seller wants to get. If you take a week off from your house searching, you might miss it. If you see it and love it, but you hum and haw about the price and then decide maybe you'll be able to bid low and steal it, then you'll miss out and live to regret it. I'm speaking from experience here. I still remember a fantastic house in Portobello I wish we'd bid more for.

Similarly with great candidates for that role you need to fill. The really good tech authors or developers or testers - if they're looked after by an employer and nurtured in their careers - maybe only only come on the market once in ten years.

As the recruiter you've got to make sure that you remember that the great candidate is not desperate to have this job you're trying to fill. The interview should not be like an interview down your local nick: "We ask the questions sonny!" This is a two-way trading of skills, experience and labour in return for a great working environment, interesting work to stimulate and stretch the candidate, and a great package of benefits (not just cash, but a decent spec laptop, up-to-date software, no skimping on the budget for software and books, a work-from-home policy, food if you have to work through lunch or in the evening - all the kind of stuff that avoids people feeling like they're just working for the man).

I've been recruiting for a new tech author recently and I always try to remind myself, before I go into an interview, of the one that got away. The candidate who shone out as an obvious big asset for the company, who I failed to sell the job to, and when I offered him the job he turned it down. Hiring and firing are two of the most important things to the health of a company - especially for a fairly small company. For a company of ten thousand, one bad hiring doesn't have a huge impact unless it's at director level. For a company of a hundred, one bad hire at any level will hurt, and one great hire will make a positive difference that will ripple throughout the company. For that reason, letting a great hire slip from your grasp is a serious offence but an offence for which the offender is never punished.

As a recruiter your job has two imperatives:

1) Make sure you choose the best person for the job. There may not always be a great candidate, you may have to just choose the best of the good ones. But you've got to make sure this person is right for the job and right for the company. There are many thousands of pounds at stake here. Chances are the hiring decision is the biggest single purchase you'll ever make on the company's behalf. Spend it like it was your own money.

2) Make sure you don't miss out. In any job interview, the candidate is selling himself and you're testing and judging him. But remember he is testing and judging you too. He knows a bit about the company - knows enough to think that maybe it might be a cool place to spend most of his waking hours for the next few years, but he doesn't need to come and work here and it's up to you to sell him the job and the company. Why is this a great place to work? Why is it such an interesting job? If you can't answer those questions convincingly to yourself you shouldn't be conducting the interview.

Job interviews are for both sides of the table, but all too often - especially when it's several of you versus one candidate - the interviewers forget that there needs to be give as well as take.

Personally I try to avoid overuse of set questions. I prefer conversations to stock questions and stilted answers. And if the conversation is heading in an interesting direction and you're getting to know the candidate, then keep it going with ad hoc questions. Interviewers who rigidly confine themselves to a set of prepared questions on the grounds that everybody must be treated identically, are merely depriving themselves of getting to know the candidates and therefore getting the kind of information that will help them identify the best person for the job.

Two things to avoid as an interviewer are:

1) Setting a time limit to the interview. Sometimes you'll know someone is right within the first ten minutes. If you know this beyond doubt, the interview shouldn't take long. Sometimes you'll know someone is wrong within the first ten minutes. If you know this beyond doubt, you should start wrapping things up immediately. I don't like being rude to people, but continuing an interview when you know you're not going to offer them the job is dishonest. However, sometimes an interview just needs more time than you'd expected and, in that situation, if you need more time, take more time.

2) Saving candidate questions to the end. If you've spent two hours firing questions at a candidate and then you allow them to ask a couple of questions, you haven't really bought into the idea that this interviewing business is a two-way thing. If it's a great job and she is a great candidate then you should be as keen to hire her as she is to get the job, and the questions/answers should be pretty evenly numbered from either side (except the candidate is on your turf so, inevitably, and rightly, the interview is going to be led by you).

Never allow the situation to arise where you go away having found out all you need to know about the candidate and happy that you can offer the job to someone who you are confident will be great in the job, while the candidate has gone away unsure what the job really is, not convinced there's enough to keep her interested and fulfilled, and doubtful that the working conditions will be any better than those she has now. If all you do to a great candidate is convince her that she's much better off where she is now than she'd previously thought, then you've failed big time.

Take it from me, I've made that mistake once. Never again. I hope.

Podcast: Play in new window | Download

I've recently been encouraging people at work to record any demos they do. The need for this was highlighted for me by the fact that - due to recent laptop problems that ended up with me having to reinstall Vista and losing all my Outlook data - I missed an important demo. Fortunately, however, I'd been very close to the development of the functionality being demonstrated, so I wasn't missing anything I didn't know about, but if I hadn't  already known about it, missing the demo might have meant I wouldn't have found out about the new features for some considerable time.

But if someone had plugged in a mic and switched on Camtasia or Jing, captured the demo and published it somewhere, I could have just played it back at my leisure. And for anyone at the meeting who, a couple of weeks down the line, couldn't remember how something worked - they could just replay the relevant part of the recording.

In general, I think recording stuff like that is a good idea and there's also a strong case for recording product design meetings, release authorisation meetings, or any company meeting where important information is communicated or important decisions made. However, sometimes you've got to move one step at a time. The first step is to get demos recorded: both internal product demos, Webinars with customers and feature demos that can be put on the Web site for general consumption.

This afternoon I've spent some time brushing up on SharePoint. As I've mentioned here before, I've been advocating adoption of SharePoint at work for about a year and a half now and recent signs are that this is, finally, going to happen (at least, I've heard a purchase request is sitting in an inbox waiting for a signature). So, as the resident SharePoint evangelist, I felt I should refamiliarise myself with it, and I came across a very effective, informal demo by Darren Strange, UK product manager for Microsoft Office.

http://officerocker.officeisp.net/files/Shared%20Documents/ProjectColloboration.wmv
Note: This is in Windows Media format. I recommend clicking the "View Full Screen" button, bottom left of Windows Media Player.

Personally this is the kind of demo I really like. I like to hear a real person talking me through a product demo - someone who knows what he's talking about - complete with a few ums and ahs and pauses. I have no time for slick demos where some "voice talent" has been paid to read a script - because you just know the guy doesn't know what he's talking about and if you asked him a question the whole demo would fall to pieces. Equally, I sort of resent demos where there's no spoken word just lots of bubble pop-ups that you have to read. I find it annoying that someone's gone to all the bother of writing the pop-up text and setting up when they appear and disappear, when they could have just recorded an audio track and saved me the trouble of having to do all that reading. Especially annoying about those type of demos is when the only sound on the audio track is over-loud mouse clicks. It's bizarre! If you've got an audio track, use it!

Okay, I know it's often all about localisation and producing the demo in twelve different languages, but sometimes it's just down to a misguided belief that if a demo isn't "slick" it's not effective. Quite the reverse. For me, those slick demos - particularly the voiceless ones - are eminently forgettable, whereas the informal ones, like this SharePoint demo, really get the information across well and stick in your mind.  

More demos by Darren Strange at:

http://blogs.msdn.com/officerocker/archive/tags/Blogcast/default.aspx

Incidentally, Darren mentions a little trick of Windows Media Player that's worth knowing. Press Ctrl+G to speed up the demo. You get through the demo a bit quicker without the commentary Mickey-Mousing. To get back to normal speed, just click the Play button.

For amusement value, try pressing Ctrl+S to slow things down.

I've got to admit I'd always had a jaded opinion of the Agile software development methodology. From what I knew of it - no detailed requirements document, no functional specification, no prototyping, no design thoroughly first then build it - from all of this it seemed to me that Agile was something dreamed up by a software developer, for software developers, but a potential nightmare for testers, technical authors, marketing, sales and support. To me it seemed like Agile was a kind of a "let's just bash on and make it up as we go along" approach that left developers free to do whatever seemed best (or maybe just easiest), without being tied to anyone else's plan, or maybe any plan at all. And, as a technical author, how do you document something that's evolving from day to day according to the whim of developer? So that was where I was with Agile until the week before last. Not hostile to Agile, but definitely skeptical. Then, as part of the restructuring exercise that's underway at my work, I spent a week with MarketAcuity CEO and Agile guru Sam Bayer. I'm not entirely sure what Sam's mission was: whether he'd been tasked with introducing Agile product development to the company, or just talking us through the Agile methodology. He has a very laid-back, discursive approach, so it's hard to tell. It never felt like he was trying to teach us particularly, more like he was just talking with us about one way of doing things. We started with some basics of Agile product development. What's the point? Answer: it's about accelerating value to the customer. The 4 pillars of Agile:

• Customer The process is centred around the customer. It's not about producing some new, cool product because it's something we think would be interesting to work on, or because it's this year's big thing. It's about finding out what our customers and potential customers need and value and doing that for them.
• Demonstrations Show your customers the real production software (not a prototype or a smoke and mirrors job) on a regular basis and get their feedback.
• Iterative Build something, demo it, get feedback, build some more, and so on. Demonstrations could be a week or a month apart, but probably not more than a month apart, and always on a regular schedule. Don't go away and work on something for six months or a year only to find at the end of that time that it's not really what the customer wants, because they found it hard to explain, or you weren't listening, or they changed their minds/personnel, or the market or operational environment changed.
• Collaborative This isn't the waterfall approach. There's no leader passing down commands that must be obeyed. Within the company everyone's got a role and a job to do, but these aren't set in stone with high walls. The team have to work together according to their knowledge and abilities to get the job done. And, looking externally, you've got to collaborate with the customer and bring them into the process.

Another concept that, first off, I found puzzling was that, as well as accelerating value to the customer, Agile helps you to accelerate failure. Sounds bizarre, but what it means is that if you're producing the wrong thing, or you've made bad decisions, or misunderstood the market, you get to realise this much earlier. You don't work on a project for a year, then have a launch and suddenly get hit with the truth that potential customers don't really rate what you've done, and the stuff they really want is missing from what you produced. If you're really going nowhere with a project then it's much better to find out soon, cut your losses and get on with doing something profitable. All of this, and more, makes perfect sense to me. But it really wasn't until day 3 of the week that things really clicked with me. A lightbulb went on and suddenly I saw a way of doing this product management thing successfully. So now I sort of feel like a convert to Agile. It fits with my way of thinking. Don't overcomplicate things. Don't weigh yourself down with a ton of process and procedure rules. Do one thing at a time, bit by bit. Tell the truth. Don't pretend you always have all the answers. Talk to people. Get their opinions. Keep talking. Keep listening. Be prepared to change your mind.

Suddenly I'm no longer in the documentation business. My job changed from Documentation Manager to Bid Team Manager. I'm currently involved in preparing proposals for a couple of new business tenders, which is going to leave me no time for podcasting, or even blogging.

So - at least for the time being - ITauthor.com is going into hibernation. Thanks for reading/listening, if you have been.

Bye for now.

Alistair