Blog

Stop Calling them Soft Skills

I’ve had a bee in my bonnet about the phrase ‘Soft Skills’ for as long as I can remember. I can recall thinking, and indeed being told, that ‘Soft Skills’ are super important and I needed to master them if I was going to succeed in life. Oddly very little emphasis was put on ‘Hard Skills’.

I’m pleased to report that I still have no clue as to what succeeding in life looks like (leave a note here if you know). In addition, I recently realised that despite me hating the phrase ‘Soft Skills’, I’d not taken the time to work out why I hated it. This is what I set out to do here. Hopefully, I will also make you think twice about using the phrase in the process. The same goes for ‘Hard Skills’ but that stirs up less irritation for most.



soft skills rocks.jpg

First up, hard and soft are used as adjectives in this context. Hard conjures up notions of challenging or effort. 

Soft conjures up notions of agreeable and smooth. Quite a contrasting picture!

In order to understand why we should stop calling them ‘soft skills’, first, we need to know what they are. If you’d have asked me 20 years ago for examples of ‘soft skills’, I would have reeled off a list like:

  • Communication, Empathy, Respect, Integrity, and Authenticity (to name but a few)

When I started to really think about this, I came to the conclusion that I didn’t really know what a ‘soft skill’ was. Like all self-respecting human beings who are seeking information in the information cesspool of the digital age, I turned to trusty Wikipedia (that never lies, right)?

Image by Gidon Pico from Pixabay 



soft hard skills equal.png

Apparently, Soft Skills are:

…a combination of people skills, social skills, communication skills, character or personality traits, attitudes, career attributes, social intelligence and emotional intelligence quotients, among others, that enable people to navigate their environment, work well with others, perform well, and achieve their goals with complementing hard skills.

Hard Skills, for completeness, are:

… also called technical skills, are any skills relating to a specific task or situation. It involves both understanding and proficiency in such specific activity that involves methods, processes, procedures, or techniques.

I read these definitions multiple times before I realised what irked me. The definitions imply that ‘soft skills’ are easy and somehow less relevant, and indeed less valued, than ‘hard skills’.

Furthermore, the ‘soft skills’ all are behaviours and there is nothing soft about them! They’re HARD!

So with that in mind, what if we call them what they are?

What if we stopped calling them ‘soft skills’ and ‘hard skills’ and started called them behaviours and tools instead?

Note: Please don’t call them “technical” tools, that’s just another categorisation that excludes people.



When we take down the barriers and division of skills and call them what they really are we can assign appropriate value and weight to them.

What would you value more? Someone’s behaviours that overlay every single interaction they have? Or someone’s skills at using a machine, something that can be relatively easily taught. Which one of those things sounds hard?

I could go further too and argue that behaviours are needed when learning tools.

These behaviours:

  • Can’t be as easily taught (but they can be taught)

  • Are not deterministic (A + B may or may not always equal C)

  • Are hard to quantify (metrics to measure many of them don’t exist)

  • Are hard to qualify (they appear defined by what hard skills are not)

  • Modifying behaviours for a human being is hard (well I find it so anyhow)

Behaviours take time, passion and practise to master!

So please, stop underselling and undervaluing them, and start investing in them!

If you are interested in learning more about where the notion of Hard and Soft Skills came from, I encourage you can read the US Army Report from 1972 here https://apps.dtic.mil/dtic/tr/fulltext/u2/a099612.pdf.

Technical Writing – Everyone’s an Expert

I was driving to see my Gran the other day musing over recent events when what I can only assume was a Pterodactyl flew across my car, depositing on my windscreen at least three days worth of breakfast, lunch and dinner. I’ve since had to top up my screen-wash.

You know the drill, you’ve spent hours composing what you consider to be beautiful instructions for the product to assist the user in their hour of need. You’ve gone through all the review gates (that you likely set up) and you’re ready to go live.



tw everones an expert seagull.jpg

And then in comes the expert with their swoop and poop. They read your pride and joy, they glance over who’s reviewed it (if you’re lucky) and then they offer forth their opinion, after all, it’s just some words — everyone’s an expert in those!

You don’t see this with code (usually).

You have PRs, someone reviews it, any changes are made and then the PR is approved. Fortunately, not everyone thinks they’re an expert in Java, which is most definitely a good thing! However, words aren’t afforded the same level of respect, everyone can do words, right?

Deep down, during the aforementioned fly-by, you’re cringing. You want to pull up any number of Hemingway quotes, and wave them about, as well as and stamp your feet (maybe just me). Instead, you sigh, make the requested change (because it’s easier than fighting your corner), and then you likely begrudgingly send it back through all the revision gates because what choice do you have?!

So how can you perform a preemptive strike on potential swoopers and poopers (aka, stakeholders) and what can you do if it’s already happened?

Image by Engin Akyurt from Pixabay

Identify your stakeholders

If you’re new to the business or the role, identify your stakeholders, include them early and get them on board. Find out from your colleagues who is a closet Technical Writer and who always has an opinion as well as the regular list of stakeholders that you’re expecting to work with.

You need to identify their drivers, what makes them tick. Have they been left out in the past? Do they feel like they need to “add value” in all areas of the business so they swing by ‘cos words are easy? Do they want to be you? Do they like to have fingers in all the pies? You have to talk to them!

In fact you have to talk to everyone, leave no stone unturned in your hunt for stakeholders. You need to check behind the sofa, under the rug, and most definitely in the box room. You don’t need to make everyone a reviewer (no one has time for that), but you do need to identify the people that not only care, but are in a position to give a sign off on your creations.



tw everones an expert parrots.jpg

Not all of these stakeholder challenges are easy to solve as many of them are outside of your circle of influence if you take them at face value.

However, this is where your skills of taking people on the journey are absolutely invaluable.

Don’t make them all be a tick box quality gate (although some will be just that), instead ask for their opinion early, show that you value their advice, build their trust in you and your ability to do the job.

Stakeholders who have been allowed to invest their time and energy in the creation of the content will become your biggest advocates. Elevate them and enjoy the extra pair of eyes that you control on your timescales.

Image by Vinson Tan ( 楊 祖 武 ) from Pixabay

They still swooped and pooped! 💩

Okay first up, we’ve all been there, do not have a pity-party. It does no one any good and just serves to make you wallow in your own pit of gloom, eat pizza and get that really judgemental message from Netflix.

Instead, pick yourself up and ask yourself why the fly-by happened. I bet that if you really soul searched you could find something that you can directly change and influence that would dramatically reduce this from happening again.

However, we’ve covered that. So now it’s happened, job one (we’re not doing that pity-party remember), clean up! Now I don’t mean like a Roomba would when the dog deposits a gift in the kitchen; don’t go smearing it everywhere. Instead, graciously pick it up, examine it (I am regretting using this analogy now), deposit it in the nearest bin, and wash your hands (‘cos, eww gross).

Now you need to engage with the pooper to explain what you’re going to do to address not only their concerns with your creation, but future ones. For this one, I strongly recommend that you try and avoid jumping into defensive mode. Signs that you’re in that mode include the urge to explain your processes, justify your methods or wave other reviewer’s feedback at them. If you find yourself there (we all have, I certainly have), take a step back and ask yourself what you want from the situation. What you want is a stakeholder that is your ally early on in the process.



Instead of being the defensive Technical Writer who feels like they now need to justify their efforts, try having an open conversation of asking them why they gave you the feedback, and then keep asking why (in a non-aggressive way). Keep drilling down until you reach the source of their pooping ideology. Channel your inner two-year old self that drove your parents mental with your constant questions.

Once you know the source of their pooping ideology you’ll know what to do with the gift. It may be that while delivered poorly, the feedback is actually crucial and needs incorporating for reasons you didn’t even realise. It may be that they know something you don’t and while it doesn’t need rehashing this time, their ill-timed feedback will save you a lot of pain in other projects.

Alternatively, it may be that they just can’t help themselves, in which case early involvement will likely save you a lot of pain just before release day.

Image by TheOtherKev from Pixabay

When all is said and done, stakeholders who review your content (invited, or otherwise) are both your biggest advocates, and at times, your worst nightmare. Take a step back, ask why they’re giving the feedback and then turn it around so it’s on your terms next time. It’s your content, you’re the Technical Writer. Own it and accept that it is, and always will be, a shared vision.

How do you get into Technical Writing?

Or Technical Authoring, whatever 😉

I realised the other day that despite nearly twenty years in various roles in technical writing, and more recently product, I’ve never written a blog or shared some of the experiences. I’m now going to attempt to rectify this behaviour!

So let’s start back at the beginning with the age-old question — how do you get into technical writing? Well, you fall into it usually! No, I don’t mean it’s a massive hole, although some days that metaphor is apt, nor do you fill in one of those questionnaires at school and it spits out “hey, you’re gonna be a kick-ass technical writer one day”! Nope, sorry, that’s not true either, it’s never on those forms (for reasons I’m not entirely clear on).

So if not that, then how?

Well, sometimes a well-meaning friend pushes you into it with sage words such as “I think you’d be good at this” or “you kinda suck at your job, you need to try something else” (both of these happened to me).

However, an increasingly common route seems to be somewhat more sneaky and subliminal (but you can make it active if you know it’s what you want!). Imagine that you’re in a role, it’s your dream job, it’s what you’ve studied for, and it’s why you have a student debt that is at least 25% of your prospective future mortgage. One morning, while you’re munching your unbranded flakes of corn, you have the sharp realisation that some unseen force has been at work and you’re now the person that is trusted to not only review product documentation, but also create it because you enjoy it. You do your day job too, (you know, the dream one), but you’re also rather invested in the product documentation.

Wait, what?! I don’t even know how that happened! You carefully place your spoon back into your unbranded flakes of corn and wonder how you got here, what turns you took and why you find documentation, heck, technical documentation at that quite so alluring.

This is a great way to get into technical writing! Position yourself as the go-to person for the product documentation and demonstrate your awesome skills with each and every piece of valuable product documentation you create! Go ahead and create a business case for your dream job, mk II, (if it doesn’t exist yet) and land that technical writing job that maybe you didn’t even know was a thing, let alone your thing.

Are you broken? Nope! But you are a special and unique kind of person that is incredibly passionate about helping the user to achieve their goals when you know deep down that if they’re reading your prose, they’re likely already annoyed and have been failed by the product. Yet you still care, you still want to help champion them, you still see the beauty in the written word, and you want to wield it to solve the user’s challenge and help serve the product.

Good for you!