*Powerpoint only - for notes, see: http://www.slideshare.net/louisefahey3/louise-fahey-mapping-your-path-in-tech-comms-surviving-the-early-years-tcuk-2016*
Are you a newbie to tech comms? Or are you a tech comms expert charged with the training and development of a newbie? If so, this presentation is for you!
Using my first two years working in tech comms as a reference, I will share tips and tricks that are key to the development of new starters in the field.
This includes advice for breaking into technical communication, entering the profession from a non-technical background, getting over the steep learning curve at the beginning, the key skills you should focus on developing, as well as much more!
6. 6
Get involved with the ISTC
They provide:
• Online resources
• Free monthly InfoPlus+ newsletter
• Local area group meetings
• Mentoring scheme
7. 7
The application process
• Get your CV in order
• Put together a portfolio of writing samples
• Contact an agency or company that takes trainees
– Start with one of the ISTC Business Affiliate companies
13. 13
What makes it so steep?
Need to learn:
• Authoring tools
• Product you are documenting
• Writing style
Best ways to learn:
• Practice
• Training
• Webinars
16. 16
Knowledge is power – keep learning once you’re in
Tools and industry trends change with time – do what you can to keep up to
date:
• Consider more training courses
• Watch webinars
• Subscribe to tech comms blogs
• Go to events such as TCUK
• Attend ISTC area group meetings
• Look at job descriptions – good indicator of what’s hot and what’s not
17. 17
Learn some industry knowledge
• Not as much time spent writing as you might think
• Working in tech comms, you become a jack of all trades:
– Usability
– Testing
– Content Strategy
• Useful to have knowledge of industry you’re working in – understanding of
Agile really helped my career
19. 19
Importance of setting goals
• SMART goals are:
– Specific
– Measurable
– Achievable
– Relevant
– Timely
• Make use of the HR department to help you (this applies to trainees and
managers)
20. 20
Be proactive about your career
• Keep a log of your achievements
– This is evidence to prove why you deserve that promotion or are suitable for that new job
• Get people to endorse you on LinkedIn - it looks good
• Take advantage of any opportunities that come your way – your CV will
thank you for it
21. 21
To succeed in technical communication, you must:
• Persevere
• Learn
• Ask
22. 22
The importance of verbal skills
• Cannot do our jobs without speaking with subject matter experts (SMEs)
23. 23
If you don’t ask, you don’t get
• No stupid questions
• It’s all about how you approach people:
– Be polite
– Show respect for their work
• The more you get to know people, the easier it is to ask questions
24. 24
Tips for getting the information you need
• Instant messages and emails for small questions
• Face to face for bigger questions
• Take advantage of casual chats
• Set up a meeting
• Use the whiteboard
25. 25
And remember…
To succeed in tech comms, you must:
• Persevere
• Learn
• Ask
Thank you very much for your time
Before I introduce myself, I’m going to kick off today’s presentation by telling you the three things that I believe are crucial to developing a career in tech comms. By the time you walk out of this room at the end today’s session, you should realise that to succeed in technical communication, you must:
Persevere
Learn
Ask
Three things that cover a whole lot, and it’s the aim of today’s presentation to inform you how to develop a successful career in technical communication around them.
Technical author of almost 3 years
Work at Clearswift, information security company
Graduate of the University of Limerick
ISTC member
InfoPlus+ copy editor
First time TCUK attendee and speaker (please be nice!)
Going back to my three requirements for succeeding in tech comms…I’m going to start with perseverance. Apparently this is a man who represents perseverance
This graph puts on paper what you’ve all probably noticed already - most technical communicators are of an older demographic.
People tend to have a few years of experience in another career under their belt before they move into technical communication. I am one of the rare few who entered the profession fresh out of university.
Whatever your path, breaking into technical communication, requires perseverance. It took me a few months to get there but if I had my time back, I’d probably have done things differently.
For a start, I’d have gotten involved with the ISTC earlier than I did.
The ISTC provides a number of online resources that give you a better idea of what it’s like to work in tech comms.
You can also sign up to InfoPlus, the ISTC’s montly newsletter which is free for both members and non-members. This keeps you updated on tech comms news, as well as upcoming events and webinars.
If you fancy meeting some tech comms experts in person, you can sign up to local area group meetings: These are open to everyone and free to attend. Gives you a great opportunity to learn more and also to network/speak with those already in the industry.
Also, if you do decide to become a paid member then the ISTC offers a mentoring scheme to its Junior Members.
As with any job, you need to put together an up to date CV. It goes without saying that this CV should be grammatically correct. But considering that professionals who write and edit documents for a living will be looking at this CV, maybe you should triple check the spelling before sending it!
You should also put together a portfolio containing writing samples that you’ve done. Even if this extends to just university work like essays, it’s proof of your writing skills. We had some great workshops on Tuesdays about portfolios and they really opened my eyes as to how important portfolios can be so putting together something is better than nothing.
When you have your CV and portfolio in order, you should then contact an agency that places trainee technical authors. I found an agency through LinkedIn but you could also take a look at some of the companies that are ISTC Business Affiliates as they take trainees too.
I would also strongly encourage you to play up on some of your other skills because aside from the obvious technical and writing skills, most tech comms positions require:
Attention to detail
A team player
The ability to learn quickly
Problem solving skills
And very importantly, a good attitude
Once you do find a company or an agency that’s willing to give you a chance, you will probably have to complete the dreaded writing test!
First of all, don’t panic – this test isn’t to catch you out or quiz you on a product you’ve just heard of. It’s about your ability to you present information in a logical and clear manner.
Second of all, do be aware of time as often you have half an hour or an hour to write a set of instructions or some other task.
Most importantly, maintain your confidence because chances are you’re a great writer if you’ve even reached this stage.
If you still aren’t having much success, then you should consider taking a course. The type of course will depend on a few factors, mainly time and budget.
There are many short courses out there in technical writing and you need to find one with the content that appeals to you must.
If you want to do a university course in technical writing then I’m afraid you’re out of luck if you want to do one in the UK! The good news is that both the University of Limerick and Cork Institute of Technology in Ireland offer post graduate courses in tech comms via distance learning. The Cork course is new but it looks very interesting, and the Limerick course I can vouch for being great as I’ve completed it!
Right so…your perseverance has paid off – you’re in the door and landed yourself a job in tech comms. Now prepare for the learning to begin.
But before it does, you should be warned - the learning bit of your journey also requires a lot of perseverance so I’m afraid you’re not quite finished with that yet!
As is the case with any new job, there is a lot to learn at the beginning. The learning curve is steep. And based on my very reliable source that I’m kindly sharing with you today, this learning curve can be steeper in tech comms than in other jobs.
To be honest, when I started my career in tech comms, this learning curve looked even more steep. I graduated from university with a law degree and my highest level of technical knowledge extended to MS Word. And those were the days when I didn’t even know you could apply different heading styles in MS Word! I knew I loved writing and wanted to follow a career in that. But I wasn’t entirely sure if I could get over the learning curve.
Clearly I did get over it as I wouldn’t be standing before you today otherwise! Aside from my stubborn nature, which makes me very good at persevering, I focused on developing three main areas.
The three main areas that focused on learning and improving were:
The authoring tool we used to create the documentation.
The product I was documenting
And also my writing style
In the two tech comms jobs I’ve held, MadCap Flare has been the authoring tool of choice. A combination of practice using it, alongside some formal training courses helped me gain ability in it. I found the MadCap training courses and free webinars excellent. Adobe offer similar materials for FrameMaker too. Also, the online user forums are great for tips or if you’ve got any questions. The community is really supportive and it doesn’t matter what level of proficiency you have, they will support you!
The product I was documenting happened to be software. Healthcare data management software in my first job and information security software in my second and current job. I received training in both when I started at each company and while this was a useful introduction to the product, it probably didn’t help me as much as actually using the software. You will learn best by doing, so my number one tip on getting comfortable with the software you’re documenting is to use it yourself. Get someone to set up a test machine and then play around with the product to your heart’s content! Once you’ve a better idea of what the user interface looks like and how to complete basic tasks, the product won’t seem so daunting to you.
Also, it’s important to understand who exactly will be using the product you’re documenting. If you don’t have direct contact with your end users/audience, then try to get the information you need from within the company. I will go to product management/product owners and get them to describe a person who is our average end user. When I write content, I imagine I’m writing to this person!
With regards to my writing style, when I started in tech comms, I was used to academic writing – it was all wordy long sentences and most sinful of all, mainly the passive voice! So although writing had always been one of my strongest skills at university, as a technical communicator, I had to adjust my style completely. I learned to use the active voice rather than the passive and I also got to grips with topic-based authoring. I did this by going back to basics and brushing up on my English grammar. I also looked at examples of different product documentation online and in print form. When I got a new phone, I was almost as interested in reading the user assistance than I was in using it! The more examples I looked at, the more I learned how to write and present information.
There was also another major factor that helped me get over the steep learning curve at the beginning - I was very fortunate to have an excellent mentor in my first job. It is thanks to the patience and knowledge of Judith Knowles, formerly of BridgeHead Software, that I gained competency in these three areas after only a few months on the job.
On my first day of work, I arrived to this pile of books on my desk. Clearly I was so excited about my new career in tech comms that I had to photograph everything! As you can see, there’s a few style guides and dictionaries in there, plus Strunk and White. There are a lot of books on technical communication but these books in the picture are the ones I probably refer to most frequently.
Judith set me up with the tools and the knowledge I needed to learn in order to become a great technical author. However, the most important lesson she taught me is that mistakes happen and that’s okay.
In my first few months, I did something with the version control system that took almost four hours to fix. It was embarrassing and I’m sure Judith was slightly annoyed to put it mildly, but it certainly wasn’t the end of the world! People learn from their mistakes and I never made the same mistake again.
Image source: http://www.thiswillblowmymind.com/boss-vs-leader/2/
For all the mangers out there, in case you’re wonder what it takes to become a good mentor, here is what this relatively new technical communicator believes! I believe that:
A good mentor cares about your development. They will help you set goals and support you on your path to meeting them. If a training course comes up, they will encourage you to go on it. They should ultimately help you to get from A to B to C in your career.
A good mentor should give you confidence – they will guide you in the right direction, give you the space to grow and then make you realise the progress you’ve made.
A good mentor will foster an environment where making mistakes are not the end of the world. They will also help you not to take the review cycle personally.
A good mentor will fly the flag for documentation in an organisation – all too often documentation is left until last and not given priority. This sort of attitude can be contagious so a good mentor shouldn’t let it catch on.
Finally, a good mentor will be patient with you. They won’t expect miracles to happen overnight and for you to be able to write an entire user manual on a product you’ve just been introduced to! Going back to perseverance, a good mentor will persevere with you on your journey from beginner to intermediate and beyond.
Even when you’re at the point where you automatically mentally start changing your friend’s FB posts from the passive to the active voice, one of the most important things you can do is to keep going in your quest for knowledge.
Tools and industry trends change over time and you should do what you can do stay ahead:
I had a great mentor and was relatively proficient in the author tool I was using as well as the product I was documenting, but 8 months into my career, I decided to pursue a formal qualification in technical writing. I signed up for the University of Limerick’s Graduate Certificate in Technical Writing by distance learning. I found that what I learnt on the job, complemented what I learnt on the course and vice versa. The course also helped to fill in the gaps in the knowledge I was missing. And it introduced me to new concepts, such as product usability, that I hadn’t come across before. As a result, I would recommend every technical communicator to keep up the training.
You don’t even have to commit to a full time training course. Despite being a year from retirement when I started at BridgeHead Software, Judith kept up to date with the latest trends in technical communication by watching webinars and reading various writing blogs. There is a list of events, including free webinars included in InfoPlus+ each month. So check them out and plan the ones you want to watch.
Conferences such as TCUK are another great way of keeping up to date. If you can’t attend, then watch the slides after. However, attending a conference has the added bonus of allowing you to network and speak with other tech communicators. You get to hear how they do things, and the issues they face. Plus it’s always nice to have a good old moan with someone else feels your pain when it comes to getting review comments back!
ISTC area group meetings are another way of getting to meet like-minded technical communicators who you can offload your work complaints to! These meetings can be quite enjoyable and are a great way of learning. They are free to attend and you don’t even have to be an ISTC member to attend!
Finally, even if you’re not looking for a new job, it’s a good idea to look at job descriptions for various tech comms positions from time to time. This lets you see what employers are after and the skills you should think about enhancing.
After a few months of working in tech comms, it started to dawn on me just how little time I spent writing. Most of my time went on planning the content I would write and also getting the information I needed before I could write it.
In the course of this planning, I had to set up virtual machines, install software, raise bugs, close bugs, decipher technical terms that sounded like another language, check out projects from online repositories, and much more! As with everything else on the steep learning curve, the more of these technical tasks I completed, the more my confidence grew and the more I could do.
It also made me realise that as technical communicators, we slowly become jacks of all trades. Our job encompasses a number of areas, and depending on your interest level, so too can your level of involvement in these areas.
I’ve got a huge knowledge of User experience and usability and I try to bring this into my work. Other tech communicators I know are more interested in software testing and content strategy. The beauty of technical communication is that there’s a lot of room for developing skills in a secondary area.
It helps if this secondary area is related to the industry you’re working in as the company you work for is more likely to support your development in it. I’ve got a big interest in Agile methodologies and my knowledge in this area helped get me the current job I’m in. The company I work for, Clearswift, are really supportive of my interest and in the past have sent me to Agile conferences. I’m currently Scrum Master for our documentation and localisation team which is great management experience to have on my CV, especially this soon in my career. Clearswift really support this and in the coming months, they are sending me on the Scrum Master training course so I can become officially qualified.
Which brings me to my next point – how important it is to set goals so the company you work for can see your progress for themselves.
Does anyone know what kind of car this is? It’s a SMART car and you should be setting goals that match this car!
SMART goals
Specific: You should state exactly what it is you need to achieve
Measurable: Important how to measure progress in order to tell if goal is met. You need to state exactly how you and others will know your objective has been achieved (ideally, but not always a quantitative measure)
Achievable: It should be something doable - Don’t be overly-ambitious.
Relevant: It should be linked to the department goals or the objectives of the docs team.
Timely: You should give an indication of when you will achieve this goal.
Use HR department to help (this applies to trainees and managers)
As well as setting goals, it’s important that you’re proactive about pushing yourself and furthering your own career.
Start by making a note of any big task or achievement you complete, Maybe you completed a major project at work. Or you got something published. Well, make a note of it at the time it happens…otherwise you’ll forget! I keep a log of these achievements in a draft email.
Also try to get people you work with to endorse you or provide a reference for these achievements on LinkedIn. These endorsements make you look like the pro you are!
And finally, please….I urge you, grab any opportunities that come along with both hands, be they opportunities for extra training at work, or to publish some of your own writing, or to speak at an event….take them! Two years ago when I first heard of TCUK, I thought it’d be great to work for a company that would support me to go, maybe in 5 or 10 years it could happen. Now I’m speaking at the event! I’m telling you this because I want you to feel encouraged that despite how new you might be to tech comms, there are so many opportunities out there waiting to be grabbed if you’re proactive about it!
And finally, once you’ve persevered and learnt…you know need to ask!
As technical communicators, we deal with subject matter experts (SMEs) on a daily basis to get the information that we need to do our jobs. There might be some internal documentation or similar products on the market but we ultimately cannot do our jobs without asking the SMEs some questions first.
This might sound like very obvious, but when I started working in technical communicator straight out of university, I was of the mindset that I could get the information I needed myself through the Internet or past documentation. I was reluctant to bother the engineers with what I believed might be silly questions. But, it didn’t take me long to realise that unless I got out of my comfort zone and spoke with them, I couldn’t do my job.
At the beginning, I found this a bit daunting. There is a stereotypical image of software engineers lacking social skills and I really didn’t want to bother them with what I thought might be stupid questions. Of course both parts of this turned out to be false – most engineers are as sociable as the next person, and there is no such thing as a stupid question.
If you approach people politely and with respect and appreciation for their work, generally you can get all the information that you require.
As time passes and you build professional relationships with colleagues, this all becomes much easier.
Here are a few tips of my own that I’ve found work well for getting information from people:
For smaller queries, I prefer sending an email or instant message.
I go directly to an SME’s desk if I have a bigger question or if I don’t get a response to an email.
Take advantages of meeting people by chance in the kitchen or smoking area if . General chit chat like “How’s the release going?” can provide you with an update on the status of a project.
Don’t be afraid to set up meetings with SMEs – you will have their undivided attention and even a short half hour meeting can provide you with invaluable information.
The whiteboard is your friend. If something doesn’t make sense in words, ask an SME to draw a picture. I use the camera on my phone to take a photo of their drawing so I can reference it after the whiteboard has been cleared.
That concludes the final part of my presentation. But let me just drill the following into your heads one final time…