I have spent the last two weeks switching between Captivate and Camtasia Studio. Talk about schizophrenic. I spent a lot of time trying to remember which command I had to use in which program, but overall it’s been an interesting experience.
For those who are not familiar with either program, they are both programs which allow […]
The last month has been so flat-out busy at work that I haven’t had time to post. Funnily enough, this busyness in my department is not reflected in the whole business. Or rather, everyone is busy, but it’s only because we have less people to do the same amount of work. Things are slowing down, and not in a good way.
If you have been reading the newspapers anywhere in the Western world lately you can’t help but notice that the stock market has dropped. A lot. More than a lot.
I work in the financial services sector. The company I work for gets most of their money from in fees from funds under administration—usually from the market value of shares and funds that we manage. 80% of the company costs are people costs, the other 20% are building and infrastructure. When share prices drop by 20-25%, our funds under administration also drop by 20-25%, which means the company income also drops by 20-25%. We can’t cut infrastructure costs, we can only cut people costs, and our department was one of the first.
Back in the dot com bust I found that tech writers were often the first to go. After all, developers can write documents, but tech writers can’t write code, can they. Or so the thinking goes. I was rather surprised I wasn’t asked to leave this time.
It’s made me think more about the future though. I am currently in a permanent job, and have consequently been less careful about putting money aside than I had been in prior years. When I was contracting I used to put aside enough money for three months to tide me over non-contract periods, and I had income protection insurance in case something went badly wrong. I also paid my credit card in full every month.
I dropped the income protection when the price of the policy doubled in 12 months, then doubled again the following year. But as for my emergency money to tide me over until the next contract, or even paying off the credit card in full—when did I stop doing that? When did I stop noticing that I had stopped doing that?
In down times like this the per-hour rates for technical writers also drop. Now, more than ever, it pays to have skills that employers want. XML, modular content, web 2.0, Office 2007 rather than 2003, and so on. A technical writer who could get by before with minimal, older skills will soon be competing against a lot more people for the same job.
Now is a good time, I think, for most technical writers to take a long hard look at any contingency plans they have; and to update their skills to make them more marketable. Just in case.
I’m feeling depressed today. It’s a combination of a lot of little things:
That’s right. One single SharePoint list. Yet they were prepared to spend hundreds, maybe thousands, of dollars to buy a new product just to produce the same information as a single SharePoint list with a number of different views.
We discussed how many lists my workmate really needed. She thought ten, one for each of our major customers.
I try to tell her that, no, if she adds an extra (checkbox choice) column for the customer name then she only needs one list, especially since 90% of the information is exactly the same for each customer. But no, she wants to duplicate the information ten times over. I set up a sample for her but she goes away not convinced.
I have no authority. I am only the technical writer. Had I been, say, a business analyst or system architect, or even a developer, then obviously I would have known what I was talking about and she would have seriously looked at the proposition.
It’s the same with the access problem. It’s a remote system. I can’t get into it. Our Service Desk guys can’t get into it. So, we (Service Desk and I) have logged a request with the people who manage the remote site. I know that request will drop right to the bottom of the pile. Because I am only a technical writer and therefore unimportant in the scheme of things.
[I have no complaints with our Service Desk, by the way. These people are fantastic. Patient, good-natured—which is pretty hard given some of the work that is heaped on them, always ready to help—despite how stupid a question may be. They keep systems running smoothly 99.9% of the time, and yet the only time they really get noticed is when something goes majorly wrong. Then it’s usually bad notice.]
But it’s the new boss that really depressed me. Here we go again. I now have to sell myself and my product—me, and my technical writing—all over again.
Sometimes I wonder if it is worth it.
The problem with being a sole technical writer in a team or a company is that no-one really knows who you are or what you do, and you have to convince them of your value. It’s even more of a problem if your team leader or manager doesn’t accept that you really are a part of the team. You become demoralised, your work gets worse, which affects your morale even more, and your ability to fit into the team, which affects your work and so on in an ever increasing downward spiral.
I think that most of us who are sole technical writers have experienced this problem.
At a recent conference I attended, one of the presenters spoke about this alienation, about no-one understanding your value to the company or your team. A goodly number of us in the audience nodded.
“You know,” he said, “That it’s your fault. It’s up to you to convince people of your value, it’s not up to others to do it for you.”
I agree with him.
Just being able to write doesn’t automatically make you a good technical writer. Two other skills that are more important are project management and people skills. People skills do not just mean being able to coax the developer into giving you time out of his/her busy schedule, it also means networking and selling yourself. Yet a lot of technical writers are far stronger in the technical and writing side than they are on the people side.
I am one of these.
Marketing is hard work, and right now in my depressed state I wonder if it’s worth it.
I will feel better tomorrow. Most jobs have components you’d rather not do, and there aren’t many better jobs than tech writing, so tomorrow I will see how I can convince my boss I add value.
But for tonight, I think I’d like to wallow in self-pity.
In Disaster Recovery part 1 I talked about how important it is for us as tech writers to back up information we have on the PC at home. Information that we may not even realise is important, particularly if we do most of our work for a company on the company PC. However, we still have contacts, emails and a portfolio that we really couldn’t afford to lose.
In this article I want to talk about another backup you need to consider. This is aimed mainly at tech writers in smaller companies, because in larger companies this is covered as part of the implementation project.
Suppose you have the following scenario:
You’re a lone tech writer in a team. Your information is all over the place and you’re desperate to organise it. You go online and find an open source content management system like Joomla (or even WordPress), or an inexpensive one like KBPublisher that you can convince your boss to buy. You get on well with the IT guys and they help you set up a My SQL database and give you space on a server to run it.
(Tech writing) life has never been better. You have a nice little content management system going. People use it. They even add to it, and recommend it to others.
A small system like this is often better for a small company than a monster like SharePoint. Don’t get me wrong. I like SharePoint, but it is big, and unweildy, and has an incredibly steep learning curve. Sometimes, it’s like using a b-double road train when a bicycle is a better option.
But …
Maybe you have even discovered that your company has SharePoint and have convinced your IT people to implement Windows SharePoint Services for you and are using this for your documentation.
Either way, what you have is a database system that has fallen outside of the usual IT control. They have let you implement it, and you’re managing it. This means you are responsible for disaster recovery too.
If you have implemented a system like this, ask yourself, “Can I afford to lose this information?” and “What will happen if I do lose it?”
If you answered ’No’ to the first question, and anything other than ’I/we have a disaster recovery plan and we can restore almost everything from the latest backup’ then it’s time to do something about it.
Most larger system projects provide for regular backups as part of the implementation process, but when a project sneaks in the back way, with a single person implementing it, backups are usually the last thing one thinks about. The implementation is experimental anyway and it’s only when the whole project turns out to be a success that it becomes a real problem.
If you have implemented a content management system like this:
You always have to expect the worst, even if it never happens. Data is only as good as your last backup. If your database becomes corrupted, you lose everything.
For years now disaster recovery has been a hot issue in larger companies. Smaller companies don’t take as much notice, and little one or two people contracting companies often take no notice of it at all. Yet for writers, whose future work depends on what we can show prospective clients, disaster recovery is a must.
Some of us work from home either full-time or part-time. Many of us have work samples and partly completed work (and even partly completed novels as well) on our PC at home.
What would happen if your hard disk crashed, or someone stole your PC? How much would it set you back?
I am not talking about a simple lack of a computer here. You can walk into any computer store, buy a new one, and be up and running within minutes—or at worst in a couple of hours if you have to install special software.
I’m talking about work in progress, your portfolio, your notes, your contact information and your emails.
Many people only realise how valuable this is when they lose it.
Writing is a business, and we have to treat it like a business. This means keeping our business information protected, and ensuring that we have a back-up plan for when disaster strikes.
Most of us insure our homes and our health; many of us also insure against loss of income. Yet there’s one really important thing that many of us don’t consider. Ensuring your data is safe. This one doesn’t even cost as much as the other insurances, all it takes it some time, a blank CD/DVD/flash drive, and a regular back-up habit.
What sort of things should you back up?
at the very least.
Where should you back it up to?
When should you do it?
Automate the process as much as you can. In an ideal world your whole backup process would run automatically, and all you would have to do is put a disk into the drive to write the data. That’s my ideal, but I haven’t got around to it yet.
If you don’t yet back up your home PC, you should at least consider the consequences of losing the data. The worst time to discover you need that data is just after your PC has died.
In part 2, I look at another area of back-ups where tech writers often run into problems.
I’m back from the AODC. Exhausted, but stimulated. Here’s a smattering of thoughts, notes and other things, in no particular order.
Tools and buzz words
Final comments