In this episode of the Cherryleaf Podcast, we look at the skills we’ll need in the future. This a practice recording of Ellis’ keynote presentation at the Evolution of TC 2019 conference, which was held in Sofia, Bulgaria earlier this week.
Transcript
This is the Cherryleaf podcast.
Hello and welcome to the Cherryleaf podcast.
This episode is about what skills will technical communicators need in the future.
It’s very early on a Thursday morning, and I’m talking about this topic at the Evolution of Technical Communication conference next Monday.
I’m the keynote speaker in Sofia, sorry Sofia in Bulgaria, and, as part of the preparation for that presentation, I’m going to be doing a dry run today.
So the conference ends on the Wednesday, the next podcast episode is due the Thursday. One thought is to record the presentation in Sofia and to send it back to the office get them to edit it all in time for it to be uploaded the day after, but in case things don’t go to plan, and to reduce the pressure, in terms of time, what I’m going to do is record my dry run and then we can use that.
And then, perhaps as a later date when we have a bit of time, replace it with the live recording.
So this is me going through the presentation that I’ll be doing next week on this topic.
So if you can imagine you’re in Sofia in Bulgaria, looking out from the city to the mountains that surround the city, and in a hotel, I think it’s a Holiday Inn next to the airport, and let’s start from there.
So I’d like to welcome you and say hello, and thank you for inviting me to be the key note speaker, and to say so Здравейте.
So I think that’s how it’s pronounced, or welcome in Bulgarian, and what we’re going to cover in this presentation on what skills will Technical Authors need in the future.
A little bit about who I am, why we’ve chosen this topic to talk about, we being myself and the conference organisers, and then into the presentation itself:
The skills that are needed for the role of a technical communicator today.
We’ll look at something called fluency, and the skills that will be needed for the future, and then some time for questions at the end.
So just to set the scope of this presentation, what we won’t be going into in this presentation is industry 4.0, and we won’t be looking at augmented and mixed reality, partly due to time and partly because of just focusing on the things that I know about.
Just a little bit about myself.
I’m a director at a technical writing company in the UK called Cherryleaf, and we’re a technical writing services company.
We also do training, training technical communicators, and we also have a recruitment service for people that want to take on permanent or contract technical authors.
I don’t know if any of you have been to the UK, if you’ve done a language course there’s a fair chance you’ve done it in Brighton on the south coast of England, or you’ve had a day trip as part of the course to Brighton.
Most of the team actually are based in Brighton on the south coast.
It’s a really nice place to work and live unfortunately I’m 100 Kilometres away, near Heathrow Airport, just outside of London, where I live, and work isn’t quite so glamorous as the seaside.
But I do my meetings, informal meetings at least in central London, and at least when I’m meeting people some of the views and places where those happen are nice places to be.
Because of my background and experience, I probably have a bias in this presentation towards technical communication in the software sector, and changes in that particular domain.
And because we’re based in the UK, and although we do work around mainland Europe (in fact we’re working at the moment with a school in Rousse in the north of Bulgaria), most of my experience and expertise is how technical communication is done in the UK.
So why have we picked this particular topic?
Well, in the past we’ve done presentations, and we’ve written articles even on podcast episodes on what are the future trends in technical communication, and there are some issues and problems with talking about that.
I was struck by a conversation I had with somebody a while back when they said, gosh weren’t you clever to know that this change was going to happen within the technical communication, within the software sector.
And I was thinking afterwards, well, it didn’t really help us when it happened.
We still were as unprepared, probably, as everyone else to actually adapt to those changes.
And asking about skills is, in many ways, a better question, because it does encourage you to take action and plan and prepare and be ready for when changes occur into in the future.
It’s also a question that’s being asked by other people, and Scott Abel, as part of a project for the Society for Technical Communication in the States, asked a number of different people via video if they could recall their thoughts on what skills are needed.
I was one of those people that was asked.
I did a little bit of recording, I think it was about two minutes.
And what Scott has done is he’s put those little video clips together, compiled them, and uploaded them onto YouTube.
Now my piece didn’t actually make the final cut, so this gives me an opportunity to talk in more depth about some of the thoughts I had, and to share some of my ideas.
Have a look at the video on YouTube, see what others are saying about this topic, and we can all compare ideas and thoughts on the future skills that are needed.
So in the show notes for the podcast, I’ll include a link to that video.
OK, so what skills are needed today for the role of a technical communicator?
To answer that, we can look at some of the competency frameworks that are around.
tekom has developed a competency framework in its conversations with some of the academic bodies in Germany, in defining a curriculum for teaching formerly technical communication.
These topics, as you can see on this slide: context analysis, planning, content development, content creation, media production, publication, and distribution, and the seventh on being observation of information product.
From the surveys and studies that we’ve done in the UK, we have a slightly different list or maybe using different words to those in that competency framework.
And certainly from looking at job roles and doing surveys for key skills for being an effective technical communicator, of these, Number one: the ability to write well writing skills and, with the world of online, being able to create content using the principles of minimalism that work effectively in an online environment.
So number one skill that a technical author technical communicator needs is writing skills.
Number two: time management skills; being able to deliver your content on time ready for when the product is due to ship.
Nobody wants a product held up because the content, the documentation isn’t ready.
And the Number three and Number four sometimes swap around.
Sometimes people think these are very important when they’re not always quite as important as people imagine.
Number three: domain knowledge; knowing the subject matter that’s around.
So what the area that the software or product is involved in there
Often with products there is a beginning and middle, and then there’s a process and the skill of the technical author is to identify that process and to document it clearly.
To explain what you need to do before you do something.
What happens after you’ve done something.
Often domain knowledge isn’t as important as people imagine, particularly if the product is for new users.
They need to understand from the beginner, and somebody that is less familiar can ask the questions that a beginner would ask.
Slightly different with documentation for developers or certain other areas, but often not as important as we as as required.
So number three domain knowledge and Number four tools knowledge
The skills in knowing a particular Help Authoring Tool or a particular XML standard, because that can be acquired fairly quickly.
Needed but not necessarily essential or the top priority.
So in looking at what skills are needed for the future, we need to ask will any of those skills become less relevant than they are today?
Will any of those change, and will there be new skills that we need to help us in the future?
And one thing to say is there’s no one right answer.
It’s likely there’s going to be multiple skill sets, different variations for different authors, in different sectors, and if you have skills or strengths in one area then they should be possible with you to play to those strengths.
So focus on the things that you are good at and enjoy, rather than say you have to build up skills in something where your interest doesn’t lie there or your to the past you haven’t had skills in that particular area.
So how do we answer this question?
How do we answer what skills are needed?
And in thinking about this, and looking at different information from people, one thing I came across was a presentation in particular about what’s happening in the world of design, and how designers are thinking about what skills they need for the future.
So let’s look at what’s happening in the world of design.
Similar questions are being asked.
Sometimes it’s like technical authors, do they need to become more technical?
Do they need to become more like programmers?
Should they need to learn code?
For designers, they’re asking questions like, should they learn how to write more?
Should they learn how to code?
Should they learn how to study business?
Should they embrace data?
And I was really struck by a presentation by Diana McDonald, or Di McDonald, that she did last year at a conference called “Should I bother learning to code?”
Di McDonald is a product designer, well, she’s a polymath in many ways, very interesting person, and I’ve included a link at the bottom of this slide to her talk, which was recorded.
You can watch the video on that.
And one of the things she talks about in her presentation are some reports that are done by John Maeda every year.
They’re called the Design in Tech reports.
And he looks at how the trends are happening within the world of design, for technology, and what are the emerging trends.
And one thing that John Maeda noticed in one of the reports a few years ago, was that design is becoming more writing based.
That designers now getting involved with chatbots and voice interfaces and smart home devices.
And in one of the reports that he did, the Design in Tech reports, he looked at the trends towards verbal design, words as material, and also how UX design is becoming like writing.
For this podcast I’ll read out what’s on this slide in the presentation itself.
I will just leave this slide up for people to read.
So let me quote from Jennifer Van “We talked about the power of words, both content and style all the time when it comes to friendships, romance, work dynamics and dare we even mention it, though nothing is more telling, more relevant, politics, words have the power to change our opinions, incite action, divide or unify us, move us, words can shape reality”.
And Nicole Fenton, she’s quoted on an article she wrote on words as material:
“I think of design as a process of articulation. We join together to express an idea in a coherent form. We bring ideas to life, we connect the dots or build bridges for our users. This often means being specific about what a product does, who it’s for, why it matters, and how it works. We have to trek through a pile of ambiguity to do this”.
And the other final quote is by Susan Stewart, why UX design is a lot to like writing:
“Here’s where I’d like to draw the parallel with writing, because a core skill of the interaction designer is imagining users, characters, motivations, actions, reactions, obstacles, successes and a complete set of what-if scenarios.”
So in the world of design, and there are people looking to recruit the perfect unicorn designer .
What there is within that perfect role of designer of four Unicorn skills: our visual design, which has always been there for designers, prototyping front-end development, being able to take those prototypes and make them into a code example, and the fourth unicorn skill is writing.
Writing is seen now as one of the unicorn skills that designer has, but with this of course, unicorn skills and unicorns don’t exist – trying to find the perfect designer that has everything very, very unlikely you’d find somebody.
And for designers that want to improve their skills, to be able to do all these four things, there’s a time cost.
iIf you spend time learning a skill in how to become a better writer, you don’t have the time
But the time to learn the skill, to become.
So you acquire some basic skills in being a front-end developer or have those front-end development skills.
One of the things that Di talks about in her presentation, and it’s true for us as well, is it makes sense to have a team.
So you have as it were, like a radar diagram, people with strengths in certain areas, and not necessarily great strengths in others.
But where you build a team, you can get people that specialize in certain areas.
And I guess Jack’s of all trades or Jack’s of some trades.
With some skills in in certain areas, and that there’s overlap.
And by building the team, you get this, if it were, if you imagine it as a radar diagram, almost like a perfect circle of the all the skills that are needed.
And Di’s argument is that, as a designer, they should acquire, still have the design skills that are needed, but also extend their skills out a bit to some of the new areas.
But, of course, if you’re talking about building a team to design a product, and there’s this need to have somebody with writing skills, can you think of the type of profession where there are people that have writing skills and could add value to a product design team?
You might think of technical communicators, technical authors.
So is this good news for us as a profession?
Is this good news for technical communicators?
Well, maybe.
So the next thing I want to talk about is how to address these unicorn skills, and this, extending of our ability and a need for fluency.
And the reason for this is the in the past there’s been situations where there’s been opportunities for technical communicators to get involved in other areas of the business ,and it hasn’t happened
It’s been a bit like Cinderella waiting to be asked to go to the ball, but somebody else gets asked to go there instead.
And partly that has been down to what you could describe as a lack of fluency – ability to communicate the value to the organisation.
So let’s talk about what we mean by fluency.
So fluency is the ability to communicate with other specialisms, to be able to talk their language, to explain things in the context and with the vocabulary that they understand.
To have a shared language, a shared understanding.
So if we’re talking to front-end developers, understanding the process of what goes into front-end development, explaining technical writing in the context of front-end development, being able to perhaps show a very rough example of how something might look with words in them, by having some very basic rough-and-ready skills, and coding perhaps, that type of thing.
So to do that what, we need to do, I’ve shown on this presentation, lots of radar diagrams, where there’s different skill sets around the circle, and then the radar goes out.
We have strengths in areas, and the shape of the radar diagram this narrow where you don’t have skills.
We need to assess ourselves and look at what we can bring to a team in the context of that.
All the skills that are needed for a design project for example.
For a design team, the skills that might be needed are writing, visual design, brand design, prototyping, front-end development, strategy research and motion design.
And we can look at where we can contribute in some of those.
Certainly writing. Perhaps visual design, perhaps prototyping, and show where how we can contribute to make that overall set of ideal skills for that design team.
And if we’re working in a development team in a software house. then the skills might be slightly different.
This is the skill set that’s defined for development from the Wikipedia page on development: specifying, there’s designing, there’s programming, documenting, testing, and bug fixing.
Obviously, we can contribute with the documenting, but we may also be able to contribute to the design aspects of the project also.
Certainly if we extend our skills out into that particular area.
So what we can do is we can educate people on the edges of our roles there.
Our expertise of the overlaps where we can contribute.
We might not be the best, but we can lend a hand and get things done.
And explain how we have a set of skills that are different from anyone else.
That we can bring to the team things that others just cannot do.
And as part of that, we can explain our processes, how we need the team to work to being able to get our bit done.
So this means, as I said, we need to figure out where we fit in.
We need to build our own radar diagrams, mapping to the skills that the team needs, and then we need to spend some time on learning.
To push out to some of the areas where we can do more than just one specialist thing, but help in another area.
So this means part of the skill set that we need is to be able to communicate effectively, internally, being able to explain in two minutes to somebody what you do what your value is.
So it’s understanding the business so you can put your work and your plans in that context, yes.
So there’s a need for leadership, to provide a vision for the future of what is going to happen with user assistance, explaining why it matters, what’s at stake, and why it needs to be done.
And telling others what is their role, where they fit in.
Let’s move on now to specific skills that are needed.
We talked before that there was this existing skill of writing and that being there and needing to be done.
And the core skill, will still be writing. It is still going to be needed.
Developers and designers, if they spend time on building up their writing skills, they’re losing time on other areas.
It makes sense to bring in a technical communicator with those skills, and they can focus their time elsewhere.
And even where the developer chatbots are, there’s still going to be a need to create source content for the chatbots.
Chat will still need a source of truth.
And even API documentation, they’re still going to be a need for a technical writer.
Some of the recent projects that we’ve been involved with within API documentation has almost been like copywriting, because a lot of what’s been required is encouraging people to use the API.
And so there’s been a need for documentation: to explain what does this API do, why somebody should use it, and how do they sign up, how do they start to use it.
And that type of content you can’t generate automatically from a OpenAPI specification file.
So a core skill has always been, and is likely to be in the future, of writing.
What about new skills?
Skill number one that we are likely to need: user experience.
Documentation now is part of a bigger ecosystem. We’re moving away from the idea that someone gets stuck, they stop what they’re doing, they go to a manual, they find the page, they read it, or stop go to a help file, find what they need.
Documentation now is part of the customer journey, and a lot of organisations are saying content as being one their key ways of getting people to buy products.
That content is becoming more and more the organisation’s best salesperson.
And we’ve been involved with a project recently for a very large multi-billion dollar company where they have all manner of different systems and applications to help the user through the journey, from pre-sales to onboarding, to continued use, where there are personalised emails that go out when they first are spotted as using the application for the first time.
And with SAAS applications, Software as a Service applications, you can identify when somebody starts paying for a product, but you can also identify when they first log in and start going to a particular screen.
You can identify the first time they use a particular feature, and then send them training material or guidance, or have onboarding screens appear to go to help them.
You can detect if they suddenly stopped using an application, and then give them information to help in case they found something too difficult or they are not certain what it does.
With some companies, even if somebody hovers over a screen for a couple of seconds, it can detect that and bring up a pop-up with an application to give them encouragement to use that particular feature, to tell them what will happen when it happens.
And we have now with Service Cloud, and features like that, you can do with Salesforce.com on the support side, you can have information when somebody goes to raise a support ticket rather than information pop up.
So documentation now is all part of certainly within the software as-a-service field the process of supporting the end user through all of the stages and trying to minimise people abandoning apps and customer churn.
So we need to be able to write for the right context in the context of the customer journey.
That means putting the content where it needs to go.
So that can be in a Help file, a user guide, but it can also be, is likely to be in the future ,embedded into the user interface itself, in chatbots, in a whole manner of different places throughout the customer journey.
so that means we need to think about more than just manuals.
Outside of the traditional boundaries of what is seen as the things that technical communicators deliver.
We’re also going to likely to see a trend of content being built synthesised, as Mark Baker calls it, by machines, by algorithms, structured and structured and formatted so it can be readable by machines.
And that’s going to mean to do that, we need to write our content in a way that is structured and semantically marked-up and adaptable.
So we’re talking not about really manuals or Help files, but experiences.
The problem with this and saying all this at the moment is that really many technical authors don’t understand their users enough.
When it comes to user research and usability testing, often there’s no time, or it’s not seen as needed or the technical authors don’t have the skills to do that.
And often, the only research is that there’s the assumption that the technical author represents a typical user, and the technical author’s experience of using the application and writing about it, is representative of all users.
And we need to do something about that.
We need to do more user research and usability testing, and that means we probably need to improve our skills in doing user research.
Another area where we might want to improve our skills is in UI.
If we could build documentation into the designs, the prototypes themselves, then there’s more likelihood that it would be considered and incorporated into the product, and considered at an early stage.
So one thing we may want to do is build the skills so we can create examples of UI text screens.
So one thing I’d recommend is learn about the design tools, the tools like Sketch or Figma.
Now we don’t necessarily need to be at the level of creating content that’s production-ready, but something that uses the language and the tools that the team understands and that they can use to extend and develop.
Another skill that you may be considering: programming coding.
And Tom Johnson did a presentation recently, there’s a recording of it and there are slides on it, it’s a presentation at the STC conference on the theme that Tom’s been talking about about: do technical authors need to specialise more?
And he had a slide up saying that one approach can be that technical authors position themselves as developers writing for developers .
And if we did have some coding skills, it certainly would make it easier to talk the language of programmers and help us understand the requirements of what’s needed for machine learning and for chatbots and so on.
But certainly a good group of technical communicators aren’t orientated towards coding, aren’t interested in it, aren’t necessarily good at it, wouldn’t necessarily ever want to do it as part of their role.
So my view on this is, if you want to build up skills and you want to take that path, then fine, but if you don’t, it’s not necessarily the end of the world.
It’s not inevitable that the technical authoring role is to be going to become more developer orientated and more coding, or in require you to have coding skills, because what we tend to see is that there is a pioneer group that dive into the technical aspects and the coding aspects, and can get content created in very interesting ways, and then there’s a second wave where the tools venders in particular Help Authoring Tool vendors hide the complexity from you and make it possible for you to do those types of things in a way that means that you don’t necessarily need to know coding and programming.
For example, with the latest version of Madcap Flare, they’ve introduced the ability to do micro content.
And that can be then used to create the microformat type search boxes for Google and also keep question-answer information for chatbots.
And as a writer, you don’t need to know the coding or the more technical elements.
That’s hidden from you.
You can use a tool that you’re familiar with, and write and create content that can be then imported, ingested into a chatbot.
So what next after this conference?
What should you do?
I would suggest you reflect on your skills.
And this idea of the radar diagrams of key skills, and seeing how you rate yourself and the shape of your skills as it were, I think that’s a really good starting point.
To see what your strengths are and your weaknesses, in the context of the skills that are needed for the team.
I would be very interested in seeing those. so if you do this, do send them to me.
I’m really interested in seeing how the the similarities and differences between the different people.
I’d also suggest you watch Di’s presentation, particularly if you’re interested in building up your skills in the coding area.
In the presentation that Di did, she talks about how designers can learn how to create prototypes, can learn to do basic coding, and those paths to do those things are applicable to technical authors as well.
And what we’ve been saying is, also extend your skill sets, stretch out.
So specialise, be a master of writing perhaps, become a jack in one other set of skills.
So taking courses would be a good way.
Courses in things like UI writing, usability testing, user research, could be one way.
Coding might be another.
And as the people at this conference will be doing, have done, are doing, go to conferences and learn.
That’s a great way to learn, also.
To summarise.
When it comes to learning and building out skills, there’s always an opportunity cost.
There’s a time cost.
If you spend your time doing one thing, you can’t do another.
So in the context of a team developing and designing an application or a product, you as a writer have a great position in being able to provide to that team the writing skills that are needed already, because you have those skills already.
And implicit in that, is this need to be fluent in the language and in the understanding of what the team needs.
And if you can build that fluency in understanding perhaps even some basic skills and things like coding or Sketch to sketching applications, there is a value in helping people understand how you fit in.
So this means we need to use the skills we already have, and improve them and promote them, as well as extending into some new skills.
So that is then into the question and answer stage for the presentation.
So for this podcast if you do have any comments or questions on it, then you can email us info@Cherryleaf.com and let us know what you think of this presentation.
We will include in the show notes for this links to Diana MacDonald’s presentation and the Design in Tech reports. I think those the two main links.
I suspect I will put the slides up on to LinkedIn on to SlideShare. I’m also going to be doing this presentation live at the TCUK conference, which is being held in Warwickshire in England in September. So the presentation might be nuanced, developed, iterated, between then and now.
But if you aren’t going to the conference the Evolution of TC conference next week, and you would like to see this presentation and talk about it, see what others think, then it’s a good reason to attend the TCUK conference.
I think that’s it for the moment.
If you want to know more about Cherryleaf for technical writing services that I mentioned in the early stages of the presentation Cherryleaf.com is the place to go for that.
You’ll find details on our training courses and our writing services and our consultancy services.
Thank you for listening and we look forward to doing another episode in the near future.
Leave a Reply