How do you do it?

I’ve conducted a fair number of interviews over the past few years, not a huge amount but definitely into double figures. Some have been good, some not so good, and some just embarassing.

I recently read about an interview that was more like a planning meeting, outlining the job in terms of the issue that was being addressed, discussing requirements and asking for ideas. As a way to evaluate how a prospective employee works, and how they would fit into your organisation or team, it makes some sense. I’d still use the more traditional question and response session as well, but this has gotten me thinking.

Are there other, better ways, to conduct an interview?

Just for kicks, here is my typical interview routine:

1. Meet and greet with a firm handshake and set the tone with a friendly enquiry. Check that the formalities have been dealt with (interviewee has signed in and has a pass).
2. Take them to the location of the interview, usually one of our meeting rooms.
3. Outline the interview process to them.
4. Give them a tour of the building, and talk a little about the history of the company, and point out some ‘how we work’ stuff.
5. Back to the interview room, offer them a drink (coffee, tea and water will already be there).
6. Then chat with them through their CV, asking them to explain and expand on certain points. I do ask for examples of work as well.
7. I’ll then expand a little on the role they are interviewing for, and go over some of the employment terms.
8. Then it’s final questions and we’re done.

It’s point 7 that could be expanded to be more of a scenario based discussion, and whilst I do use that approach on a small scale when I’m asking them questions, it might be interesting to outline a larger scenario and see how they handle that.

I’m always looking for better ways to do these things, as interviews can be hit or miss for both participants, so anything that would help keep it interesting and engaging would be beneficial.

Do you interview when hiring new staff? Any favoured approaches?

This post is directly prompted by a discussion on TechWR which, whilst it occasionally frustrates, continues to provide plenty of scope for thought.

Sylvia Braunstein asked about “Avoiding documentation bottlenecks whilst maintaining quality” and a couple of emails later the responses headed into a familiar territory. I call it the “management choice triangle” (or sometimes just the “pick two”) but you’ll all know the triangle, in one format or another, and under various guises, the premise is largely the same.

“Good, fast or cheap, pick two.”

However, as much as I prefer and encourage a minimalist writing style I think that summation is damaging. This particular triangle has been discussed, at length, by others but it’s always been something that perplexed me. I’ve always understood the basic presumptions being made and also that, despiting being sold by some as a hard and fast rule, it most certainly wasn’t as black and white as was being depicted. But then, what ever is?

Of course the basic (extracted) statements do seem to contain, and be entrenched in, some rather ineffable logic. Namely that you can have:

• something good, quickly, but it will cost you (in resource)
• something quickly and at low cost, but it won’t be any good
• something cheap and good, but it will take a long time

All of which, of course, is utter tosh.

Without stepping on the toes of others, I’d suggest that “good” really should read “good enough”, that “fast” is meant in terms of “good enough within a given timescale” and that “cheap” really means “at some cost which we’ll do our best to minimise”. Thus we now have “Good enough within a given timescale, and at a cost which we’ll do our best to minimise”. There is no “pick two” of course, what kind of manager would abide by such a rule?

Deciding what is good enough for your organisation requires an understanding of who the audience is, budgets are set although can be influenced with some discussion, and timescales are things which need to be agreed. Money and time will always be constrained by senior management - everyone wants things faster and cheaper these days - so maybe, as technical writers, we need to concentrate harder on figuring out how we decide what we consider, and how we can measure, “good enough” documentation.

Previously that was largely the job of audience analysis but, perhaps, today there is another tack we can take.

If you work in software development, you are probably used to discussions around the prioritisation of functionality. The old “must have, should have, would like to have” type thing for example, and you may do the same with your documentation but, and here’s the twist, if you DO have a list of “would like to have” documentation features then why not publish it? Better still, create a Wiki, create empty pages for those areas and see what happens.

It may just turn out that those fringe areas of the documentation, which should match fringe areas of the product, are BETTER documented by the specialist users out on that fringe. Most products have users like this, the ones who know more about a specific area of your product than you do (because they’ve used your product for years whilst the developer who created it has long since left the building, perhaps) and they are usually more than keen to share (ok, to display) their knowledge.

So, maybe, good enough means we can publish documentation that is incomplete in certain fringe areas, making sure we make everyone know that is what we are doing. Maybe good enough starts with the creation of a living, user-contributed document, that very quickly becomes something better than it’s original. Maybe then “good, fast or cheap” can then be negated completely? OK, it is a bit of a leap but as different ways of accessing information continue to gain popularity, we, as a profession, need to be aware of this because if that “triangle” comes up in discussions with a project manager, then they may already be thinking of OTHER ways to provide information that is FAR cheaper than you can manage, and no, I don’t think that (overall) the quality of information provided by user-generated content will be all that far from “good enough” for that senior manager who is desperate to cut costs and timescales.

I’ll close with a couple of pertinent quotes from the mailing list, both of which can be found in the archives. First up, Beth Agnew points out the real value of the triangle:

I think the triangle, with its humorous variations, is meant to be more an aphorism than an axiom, a general rather than absolute truth. It’s a good way to help people understand the factors involved in quality projects. We could just as easily hang our hats on scope/risk/resources, or any other threesome that makes sense for our situation. I’ve found the good/cheap/fast idea to be very useful in educating clients who don’t seem to think a documentation or marketing project is an actual project where multiple factors must be managed. Once they realize that change in one area prompts changes in the other two areas, they start to understand the relationships among the variables and why some of their great ideas show up on their bill as an additional charge. :-)

And Chris Borokowski makes a valid point when he says that:

It’s important to remember the triangle isn’t created like a three-position switch. It’s a slider switch. If you want anything done faster, there are going to be tradeoffs. If you want it done more> thoroughly (”better”) there will be more time requirements. If you want good, cheap and fast, it will be possible, but material will by the nature of time be left out.

It’ll be interesting to see how the triangle stacks up in the future, as it certainly seems as if some of the points are starting to fragment.

Might seem a bit of an odd topic for a tech author who is employed, as opposed to contracted to, a company, but someone made this comment in passing and it kind of struck a nerve as it applies regardless of your current position. We all have something to sell.

It took me sometime to develop enough business-savvy to realise that, despite knowing that doing X instead of Y makes more sense for my users, and my team, business decisions and the drivers behind them don’t always work that way, and sometimes you have to take some pain before getting to where you want to be.

A lot of authors I’ve worked with in the past that share that mentality, are usually now managers, or senior writers or whatever the next step up our career ladder happens to be, so from my limited experience, I’d suggest that it makes sense to understand the business impacts and opportunities available, and how you can sell the services of a technical communications teams to the rest of your organisation.

There are some obvious things to try, and looking at how your marketing department are selling the product is a good place to start. But I’m curious to hear if you have tried anything in this area, and if so, what worked for you?

My ‘other’ site holds brief details on my little side job stuff, which is mainly focussed on web design. I’ve just finished a website (with another on the way) and it’s nice to get that little glow of achievement. I deliberately choose small projects, and it’s fun to take what I learn there into my day job as a technical writer.

Taking the lessons I’ve learned over the past couple of years whilst “running” one man designs, which is in essence a small business, into my dau job has been interesting. Treating a small team of technical writers as a distinct business makes sense on many levels. One I hadn’t really considered in great depth was marketing the services of the team, selling what we do to the rest of the company.

I guess I’d considered it an educational function and, once educated, everyone would (somehow) know to get the technical writers involved with their project, or introduce the latest functionality to them. Of course this is never the case. Now, don’t get me wrong, I knew this but just hadn’t really considered it in great detail before… what with being busy, you know, writing stuff. ;-)

So how do you approach this kind of thing? Do you hold meetings, talk to the other team leads/managers directly? How do you “sell” what you do?

Recently, as part of my induction, I completed a simple questionnaire as part of a Belbin team role analysis exercise. This sounds much grander than it really is, although the simplicity of these things always amazes me. Who would have thought that by taking a few minutes to consider ten different questions, each with eight possible statements, and ’scoring’ yourself against three (or less) of those statements, you’d be able to see which role you typically take when working in a team environment. And who would have thought that, mostly, the damned things would be so accurate.

It’s the second time I’ve taken this particular test (the other common one is the Myers-Briggs personality test… I used to be an INTJ for that one, but that’ll have changed by now) and it’s proved itself to be accurate on both occasions. This is despite the fact that I’m not the same type of ‘person’ that I was when I first took the test. Impressive stuff.

The Belbin definition of a team role is:

“A tendency to behave, contribute and interrelate with others in a particular way.”

Briefly, during the 1970s Dr. Meredith Belbin ran several experiments to try and determine what types of people, when combined in a team, produced the best results. One of the key principles he found was that every team needs a mixture of roles, and that every team member, as well as bringing a set of strengths to the team dynamic, also brings a set of ‘allowable weaknesses’. The idea being that not everyone is perfect and you need to accept that. Dr. Belbin discovered that every team needs a mix of around nine different types of team role, and that there should be at least four people with a mix of roles (some roles are interchangeable before any of you math heads leap on that).

Based on his findings, he devised a series of questions, the answers to which help to pinpoint your typical team roles, with each person having a primary and secondary role within a team environment. These typically aren’t things you can plan or cheat, they are reflections of your personality, manifest in the workplace, and whilst they will change over time, they can be hard to influence.

Yes, it’s one of those things that, to many, seems obvious and the very fact that a test exists to try and “theorise” about this kind of thing is tantamount to management-wankery. I disagree with that notion though, as it’s only because of the early-thinkers about this are of business (and life) that we have ended up with the idea of teams in the workplace (to a degree).

Obviously every team needs a good mix of the right kind of people. You need someone to provide ideas and excitement at the start, to organise and motivate people, you need people who will take that idea and question it, pull at it and delve further into the roots of the problem, you need people who will help keep things on an even keel, and you need the people who will sit and churn away until the job gets done. Those people are not one in the same.

Me? I was, primarily, a co-ordinator, a chairman, the type of person who gets all excited about new ideas and helps organise and motivate people at the start of a project. Unfortunately, coupled with my secondary role (resource/investigator) my “allowable weakness” amounts to the fact that I tend to drop things after the initial excitement has died down. I wish that weren’t true but it’s an easily identifiable trait. Hell, you need look no further than this website for an example. There are still things I had planned to do here that I haven’t gotten around to, and likely never will.

But what really got me was that, the first time I took this test, the outcome was completely different, but equally as accurate. I was still enthusiastic, still excited about new things but lacked the ability to organise and motivate others. Which would be true as the last time I took the Belbin test I was still very much a team member, not a team lead.

Is Belbin analysis useful? Yes. From a personal point of view, it was a timely reminder of my weaknesses and helped me to focus on them in the past few months. From a team point of view then, again, yes. Knowing that you are working with someone of, say, a similar nature to you allows you to realise, and plan to deal with, the potential conflicts that may arise.

As most technical communicators work with a variety of different people, in different parts of the organisation and almost by definition, those people have widely differing personality and team types, then any information which can help you to tailor your contact methods is surely a good thing.