About the Technical Author skills map

Introduction

The Skills Map for Technical Authors is something that emerged from a project at Redgate to address the problem of career development. It has a number of potential uses, but its primary purpose is the following:

To present to authors a visual guide to the range of options that are available to them when they consider the question “How can I progress as a technical author at Redgate?”

Background

Each functional role within our development teams has its own Skills Map:  software engineer, test engineer, UX specialist, project manager, technical author.

Career development means different things to different people, but what struck us during our investigation was that at Redgate the majority of people weren’t especially interested in ‘vertical’ progression (for example acquiring Senior job titles or moving into management) but wanted help understanding how they could broaden their skills and experience. The idea of a simple visual representation of the valuable skills for each role came up in response.

A few points to consider about the skills map:

• It’s relevant to Redgate (and was never intended to be used outside our company) and so lists those skills and areas of expertise that are most valuable to us as a company at this moment in time. It’s not proposed as a generic guide to ‘technical authoring’ as a profession.
• It’s intended primarily to facilitate discussion about an individual author’s current strengths and general predilections.
• This is still an early draft, designed to trial the concept with people, and so the skills listed may be a little vague in places and in need of further elucidation.

The Skills Map explained

The Map is divided into five main areas:

1.       The central circle: Core Skills

Initially, the Skills Map was designed for people who were already performing the role of technical author to a reasonable level of competence, and so it focused on skills beyond the basics of the job.

However, as we continued to prototype the Skills Maps, we realised that it would be useful to explicitly include the “core skills” for each role at the heart of the map. This made the diagrams more comprehensive, and also meant that we could use them for everyone, regardless of their experience. For inexperienced staff, the core skills section is a useful reminder that there is a range of key competencies to be mastered first, before thinking about specializing or taking on new challenges.

We expect everyone in technical communications to have a solid grasp of all the skills in the central Core area. For new hires, we think this should take about two years.  In that period, we would discourage those authors from thinking too much about what’s in the outer quadrants. (That’s not to say a new author can’t specialize in something outside of the middle. In Redgate we explicitly gave a graduate responsibility for administering Confluence, for example).

The four quadrants

Outside of the core skills, the map is quartered into four general areas. These quadrants represent very broad categories of skills and expertise, and are there primarily to encourage an author to reflect on where their strengths and interests lie, rather than map out a direction of travel towards a different role or job title.

At the edge of each quadrant, the job titles (“product manager” or “function head”) are an indication of someone in Redgate who – in theory at least – has many of the skills in that quadrant already, and would be able to offer advice, training or coaching. So, they are more of an example than a destination. However, for someone who has a very clear ambition to become, say, a project manager, the skills inside the quadrant represent a useful guide to what would be expected of them in that job, and a starting-point for discussion as well as a means for assessing their current suitability. An author can review the skills in that part of the map, and then talk realistically with their line manager about a development plan to ‘level up’ across a range of relevant areas. This may of course be a long-term proposition.

2.       Top right quadrant: Product/domain

The top right quadrant is a collection of skills that are focused on product expertise, market knowledge, customer research and understanding users.

This is the quadrant where authors who have a particular interest in the commercial side of software development would probably focus. At Redgate one of our former writers describes himself as “having exited top right” when he became a full time marketing specialist.

3.       Bottom right quadrant: Project

The bottom right quadrant contains skills that are related to how projects are run. As technical authors at Redgate are fully integrated into cross-functional agile development teams, these skills are all relevant, but some authors may want to deepen their knowledge and practice, and take more of a lead in their teams.

At least four of our technical authors have ended up as project managers. It turns out that the skills we look for in good technical authors overlap surprisingly closely with those of project managers.

4.       Bottom left quadrant: Leadership

This is the ‘people’ quadrant. It contains a range of skills related to dealing with others, such as  recruiting, line managing, coaching, and evangelising the role of authors and Redgate itself.

This is the quadrant where we would expect to find more experienced authors. At Redgate we have one full-time “functional head” who spends all their time on the activities in this quadrant, and two divisional leads (not called that, but operating in that role) who co-ordinate authoring in their business area while still working as authors on project teams.

5.       Top left quadrant: Specialist

This quadrant contains a bunch of stuff that doesn’t really fit anywhere else, including technical specialism, ownership of tools or processes, and any area of knowledge or practice where someone might be the “go-to” person. In Redgate, this includes things like administering and configuring our support platform, Confluence, managing our style guide, learning new technologies such as HTML 5, and investigating different types of content such as video.

The top of the map: The trident of technical skills

At the top of the map, there are three arrows representing the other technical roles in project teams. Each of these roles has their own separate Skills Map. The idea is that an author who has a particular passion for say, coding or testing could follow the arrow to the other map to investigate the core skills listed there.  It’s possible that an author might switch roles to become a full-time developer, tester or UX specialist. (This hasn’t happened in my time).

It’s worth calling out that we expect all technical authors at Redgate to have a solid grounding in UX skills. It’s a defining aspect of how we approach tech comms that all our authors collaborate closely with UX specialists. On teams without a dedicated UX specialist, authors often step in to manage the designs themselves.

How we use the Skills Map

In personal development sessions

The main use for the Skills Map is for line managers to use as a starting point for discussions in one-to-one meetings with their reports. The arrows on the map can be used to talk with an individual about their general “direction of travel” if they have something already in mind, for example project management, or the arrows can be ignored if the individual does not have a clear view of where they might strengthen their skills. If an individual does have a particular direction, the Skills Map is a great tool to talk through the skills listed in the relevant quadrant for that role, and how currently qualified someone is for that role.

For some people, the Skills Map is a useful visualisation of the fact that they are strong across a range of different areas (that is, they have skills scattered across all the quadrants). It’s helpful to recognise someone as an “all-rounder”

For measuring current skills

Optionally, the Skills Maps can be used to assess someone’s current skills, by asking the individual to assign a value between 0 and 10 to each box representing experience/ability/confidence. This eventually produces a rough ‘heat map’ showing someone’s strengths and weaknesses across all aspects of their role. It can highlight certain gaps, but it is not a formal part of any process at Redgate, and is certainly not mandatory. We don’t do formal appraisals of this kind.

To help with planning

One of the benefits of the Skills Map is that it can be updated to reflect skills or technical expertise that we know will be useful to certain parts of the business or to Redgate as a whole. For example, we have HTML5 as a skill in the tech author map, which we know will become increasingly common in developing newer applications. By adding these kinds of skills to the map we can encourage authors to develop in areas that are useful to the business.

For recruitment

As the Skills Map presents a fairly comprehensive range of activities authors can be  involved with at Redgate, they can be useful as part of the interview process:

• To better explain the nature of the role here by showing the sorts of skills we look for
• To advertise the myriad opportunities for technical authors at Redgate
• To facilitate a discussion about career development with the candidate, by asking them to indicate which quadrant best represents their profile
• To help candidates assess their current skillset against the skills we are looking for

What’s next?

So that’s our Skills Map. It’s only really a starting point, and we still have lots of work to do to make it useful in practice rather than just something that looks good in theory. In particular, we need to:

• Train line managers in using the Skills Map to have a career development discussion, to a point where they are able to actually help any author who says they want to improve in a particular skill.
• As a first step to help with this: add supporting background information for each skill, so that someone with an interest in it can read more and know how to get started. We’ve come up with a template for this which contains the following sections:
  • A short definition
  • Why this is valuable
  • Current level of experience or expertise
  • Who are the go-to people for this skill in Redgate?
  • What does ‘mastery’ of this skill look like?
  • How to get started (introductory blogs or books to read, talks to watch, training courses to attend, examples to investigate and so on)
  • How to practice this skill
• Consider how best to continue to support authors who are learning new skills, and understand their level of competence.
• Embed this approach as a routine set of practices throughout development

So, still a lot of work to do. It turns out that writing the description for each skill is a really interesting exercise in itself. I may write  a blog post on this at some point too.

What do you think?

Would the Skills Map work in your organisation? Are we missing anything obvious? Share your thoughts.