In this episode of the Cherryleaf Podcast, we look at hiring trends.
Transcript
This is the Cherryleaf Podcast.
Hello and welcome to the Cherryleaf podcast. In this episode we’re going to be looking at hiring opportunities for technical communicators.
So let me give you some background.
Cherryleaf has a project team that provides documentation services, writing services for organisations.
We mainly deal with software companies, sometimes telecoms companies as well other sectors.
And we have an internal writing team that delivers those services.
But what we also do is at times use what we call associates. So these are freelancers who we have come on board to be part of the team for that particular project that we manage, and they get involved when delivering the content. So we go through phases where we are looking for new associates.
And at different times, the market changes, technology changes, and the skill set that is required from those associates varies as well.
And what’s true for us may also be true for other organisations. So if you are a freelance technical communicator, this information may be useful in helping you assess where there are opportunities, and if you have these skills today to promote them.Oor if you don’t have these skills, to build up your skills in those particular areas. And equally, if you are somebody who’s working within an organisation, there may be opportunities to let other departments or your manager know that you could do this particular type of work, and that may give you some opportunities for career development.
So one type of company is one that is launching a new service often, then stays with the growth of API as it relates to APIs.
And they are looking at documentation within the context of the whole wider user journey. So within the sphere of API’s, what they’re looking to do is provide a whole range of what’s called DevRel or developer relations.
And they may build up a development relations team or DevRel team within the organisation, but also look to bring expertise and resources as and when is needed. So there’s a need for user documentation or developer documentation and more.
And that the developer journey, information that somebody will need before they start to use a product during the time that they’re using a product. And also information that can help encourage them to sustain that use, so there’s still a demand for how to documentation, user guides, and the like. There’s still demand for troubleshooting, information helping people when they get stuck, sometimes in the form of tasks.
But we’re also seeing a great interest, and we’re often asked about what we might call the more training side of the content.
So asking for the walkthroughs, and tutorials that can guide the users through a particular narrow task from beginning to end.
Now sometimes these tutorials and that context can be more technical than the usual user guide, because it can involve some coding elements, but not always linked with that. It can also be the issue of the onboarding emails. And often this starts by looking at the content that people get for starting to use the product. So do they get a username or password in an API environment? Do they get API? How is that information provided to them?
And sometimes there can be a dashboard that people use for getting that information within the application. But often at the start the dashboard isn’t ready and so the way in which that information is provided can be manual. Somebody can email a request for an account, and that is emailed out to them with the details that they can use.
But there should be additional information to help people get started. We have onboarding emails in lots of applications. It can be very useful.
And sometimes that role isn’t particularly well defined. If there is a usability team, it can be part of that sometimes. Or user experience, it can be part of that.
But we are getting situations where we’re asked can we provide that content? Can we write those on boarding emails, so they don’t just get Here’s your username. Here’s your password. Go off and chase that tiger.
And another situation where there is interest, again related to Developer Relations is community-based information. There’s this desire to create a community to get users to self, serve, to encourage others to see the case studies of what can be done.
This is much harder to provide. It’s somewhat tricky to know the secret sauce that makes one community successful and another not, particularly if you don’t have many users at the start.
But where there can be an opportunity for people is with the content that can be linked to both the training and the community aspect. And that is often delivered by newsletters or email campaigns, which have content, about information, to help people solve their problems. And links to that type of content, links to the tutorials. And it can be links to video walkthroughs that explain how to do certain things. And it can be linked to events it can be sessions where somebody is explaining something in a live environment. Or webinars and the like.
And being supplied in that way.
So that content needs to be written, those newsletters need to be written, and that can be another opportunity for people.
Another aspect where there can be the need for content within developer relations is what you might call Marcomm, or marketing communications type information, specifically Use Cases, explaining when and where and why somebody would use a particular feature in application or a particular API or a particular resource within an API.
And that can expand into case studies. When you get to the point, or when a company gets to the point where they have some users using the product successfully.
There can be the situation where you can start to write case studies to spread the message about how this company is benefited from using your particular product or service.
Of those, I would say the ones that are come out most often are tutorials and use cases.
And then following on from that, I would say the interest in or requests for creating onboarding emails.
Another type of project or inquiry that we get is the company that has what you might call the broken developer portal.
And this sometimes comes about because an API has been developed and then the company has been successful and they’ve sold the business to a large organisation, or the initial team has moved on, and there’s a new project manager. Often there’s a new team involved in being responsible for this.
And they’re looking to understand the API they’re looking to get more from the services provided. Often they’re looking at the documentation that exists and scratching their heads and thinking, if this is bad for me, then this must also be bad for the end users as well.
So we gave enquiries for, can we fix this portal? So often these projects, there’s not necessarily a great deal of creating of new content.
What these projects are often about is what we call information design, restructuring and reorganising the information. Or organising the information in a way that has a better, more usable, more user-friendly flow to it. Can the information be more easily found if somebody wants to find information and look at related information? Can they navigate to that?
So it’s also about clarity and making the existing content clearer.
And it can be as part of that information design aspect. The structuring of the content within the page as well as the order and tree structure as it were, hierarchy of the content itself.
And sometimes that extends into looking at a taxonomy. So can there be ways to filter and navigate to the information.
And this problem also can be a situation with knowledge bases.
So we talked there about developer portals. Also, the same situation with knowledge base is that there is a support team that’s using this content, or there can be a knowledge base on the web that the end users are using, but it’s not working effectively.
There are still lots of calls to support. Or it’s taking too long for the support people to answer the questions.
And that again this is around information design, structuring and ordering the information within the sites.
The metadata to find and navigate to information. The sequencing of information on the page, the clarity of the content.
And another type of inquiry that comes across is what you might call, I guess, the content strategy-related or content management-related enquiries.
So this can be an organisation that’s in the middle of a rebuild of a help centre or starting off with a new product.
And they want to look at all the ways in which the users can be assisted. So that can be the help content in a Help file.
It can be contextual Help, it can be guided in-app walk-me type tools. It can be information that might be provided via support. When somebody contacts them that way.
And what they’re looking at, there is often things like an audit of the help content to triage the content. Look at the areas that need fixing at first. And most importantly again, how the information can be structured and reorganised in a lological way.
And it can also extend to the content management process. How can the content be written so it can be future proofed? How can it be written so that it’s written in an efficient way? It can extend to metadata and taxonomies. So that you can look at the best approach for bringing the right information to the surface in most quickest, best way.
And it can also extend into what Rahel- Anne Bailie calls content operations. What are the right tools to use for creating the content? What roles responsibilities do you need?
One common one that’s coming through now is can you create a template that we can use. So that our content, particularly knowledge-based content, used by support staff, is consistent and conforms to best practice? Can there be guidelines that are set up so the teams that are working internally within the organisation?
The team that is creating the content, can they do things in a consistent way and in the best possible way?
So that type of projects can involve looking at and working strategically, setting standards guidelines. It can involve project managing the change within the content. It can involve looking at the information design problem, having information design skills and the confidence to tackle a big project.
What’s not on that list that I’ve mentioned so far has been usability testing and user experience. And also not the creation of SDKs, not creating code samples. Now that may be because we don’t get those type of inquiries because people perceive that we don’t offer those services, or they think that there are other organisations that can do those things that they prefer to use instead of us.
It may be also that there are opportunities if you are technical communicator, that are in those spheres as well, but that we’re unusual in that that others are getting those enquiries. So I should mention that there may be scope for having skills in usability testing, user experience in heavy duty coding. That those are opportunities to you, if you are a freelance or a permanent Technical Author.
So we also looked at some of the job adverts to see if these sort of skills are being asked for by others.
We looked at one of the popular websites in the UK which is Reed, and we looked at the job descriptions for some of the roles which have the job title, Technical Author. And more than really reflects the skills that we’re being asked.
So here they’re very much the sort of traditional technical writing roles, technical writing skill sets that’s been around for years.
Yes, now that may be a reflection that the type of opportunities aren’t being offered as standalone. Freelancers aren’t being offered as permanent roles. Or that these types of roles are not ones where the job title technical author or technical writer is being used.
So what I also looked at was the Jobs Board for Write The Docs, which is more aimed at what they call documentarians or people involved with developer-type documentation, developer portals APIs. Although the community for Write The Docs, has expanded. So the job descriptions have got wider as well.
So let’s have a look at those. Well, one here is actually using the job title of developer educator, and that includes writing documentation, writing code samples, creating new tutorials, refining the API, reference documentation.
So that’s going into the Open API spec file the Swagger file and making that clearer and easier to understand. Writing code snippets. This has also got writing automated tests and setting up metrics to measure things. And if you then will do involve or checking on code testing and linking with continuous integration, continuous development, and software testing in that way. So it suggests there is also opportunities if you have expertise in that area.
Another one here describes this as functional technical writer. In addition to writing the user documentation, rewording release notes. So that they clearer writing scripts for instructions and checking over the marketing copy for the product.
There’s another one here which just destroyed as a developer focused technical writer. And for that role, they’re looking for somebody with API and SDK documentation, experience, and the ability to write test code and example codes. So that recognising that that is more developer focused.
So if you’re interested in looking at what skills you need, or what opportunities are around then looking at the Write The Docs jobs board might be useful for you.
You’ll notice there hasn’t been too many that expect people to be able to code. It seems to be more that you need to be comfortable with in a development environment. That you know what a programming language is, how they work. You know what the difference is between, say Python and C. The difference between Linux and Windows.
And often within the developer environments, the documentation portal environment, it can involve working what’s called the Docs as Code approach. Something we’ve talked about on previous episodes of this podcast. And you’re comfortable working in that way. Writing content that goes up to GitHub ,and gets published, gets approved and processed and published, using that type of approach.
So I mentioned we are looking at the associates we’ve got and looking to see if we can have more on our books, in case, as and when, we need to bring in additional resource for the projects that we have and that bring in the right person with the right skill set.
If you do think that you have a skill set that matches. Then you can contact us at info at Cherryleaf dot com.
Now, because of the taxation rules in the United Kingdom and in the United States we tend to work with people that are working for a limited company. So in the UK there’s somebody that has their own limited company, and that the billing is done through that, rather than self-employed people. Or they go through what’s called a managed services company or an umbrella company.
And there can be also similar issues or restrictions or concerns about taxation for people that are based in the United States.
Most of the work that we get is for clients that are in the USA or in the UK or in mainland Europe, so our preference is also for people that are either in United States in the UK or in mainland Europe. The work is nearly always done remotely, off site, but from a time zone perspective and for other reasons, particularly the taxation reasons, those are the countries where we tend to have our associates.
So that is it. I hope that information is useful. If you’ve seen other skills and other opportunities coming out for technical communicators, things that you’ve been asked to do, and you’d like to share with others, let us know info@Cherryleaf.com.
Otherwise, thank you for listening. If you want more information about Cherryleaf , it’s on our website, www.Cherryleaf.com.
Apart from that, thank you for listening and I look forward to speaking to you next time.
Leave a Reply