Thoughts

3 life changing soft skills for technical leaders

And quite different from the usual soft skills pegged around

(Image rights Dilbert.com)

3 main takeaways for those in a hurry:

Tech leaders need to:

  • Use analogy to simplify
  • Using more than one kind of story
  • Practising Self awareness when delegating — patience, appreciation, engage, validate, trust

When people speak of soft skills, there is a sh*t load of articles that contain a refurbished version of what a recruiter or a salesperson might have told you 20 years ago for a job that you were desperate for. I have no problem with recruiters or salespersons at all (in fact, I love them!) and the soft skills they mention — some of the are actually full of real value. Things like communication, body language, vocal variance, honesty (!), and so on are the most common soft skills being drummed around. However, like any other skill, they are not fitting every situation and role, and need special care customised to the role, situation or challenge you may be facing.

What I am pointing (no special) finger at, is the concept of taking some soft skills from one place and shoving it to every scenario.

Over the last 20 years, I have met many CTOs and technical leaders, from one-person companies to Fortune 100 firms. Some of them have been in their roles for a real good time, and have seen both the challenges and the fun parts in being a CTO.

While spending longer periods of time, I was an audience to several arguments (very useful to get a load of feedback in a short time), as well as celebrations.

In addition to looking at the usual soft skills, here are 3 crucial, life changing soft skills that care enhance your skills as a technical leader, by nearly 3 fold.


Use analogy to simplify

I was sitting in the audience for a tech pitch where there was a question from a gentleman, that could be answered only by explaining multi-dimensional arrays. The gentleman was from a background, which made it clear, that he does not understand anything related to arrays, let alone multi-dimensional. The gentleman was an investor. In many cases, an acceptable answer is to say, ‘I will explain this in detail offline, or in a separate discussion’. The way this is said, could border on condescending. As I watched, part of the audience was getting upset with ‘such a silly question’. I overheard, someone saying, ‘Why is this guy here if he doesn’t get it?’.

With ultimate calmness, the founder explained, ‘… this is like a set of multi-storey apartments — in order to find someone’s exact address, you need to know the building number, the floor number, and then the apartment number…’.

There was a moment of silence. It is not that the gentleman did not know how to find an address.

When an extremely complex topic is compared with an extremely simple topic, you will be surprised with the number of similarities and how quickly you can convey the concept.

What technical leaders struggle with is to show only a few ways of explaining the concept — mostly the one they used to learn the concept themselves. As you expand, you have to interact with people, whose strengths lie in areas other than yours.

Using an analogy to simplify quickens the learning without being condescending or insulting in any way.

Two points to remember:

  • Your analogy has to be simple for the concept being explained. You may not find one analogy that explains everything that you want to share — such comparisons will further confuse the audience.
  • It has to be perfectly clear that you are using the analogy only in a temporary attempt, to accelerate the understanding of the audience. You don’t want, say, concepts in blockchain to be compared with say, apartments, in the worst possible context.

Using more than one kind of story

One day a technical leader went to an expensive seminar where they were taught to put stories in their narration. It was also pointed out that solving a problem is the greatest way to explain something that creates the biggest impact. Problem-solution-story. I have seen hundreds of pitches use this format.

While it is a good way to focus the audience in a pitching event, this is only one way. This is especially true, when you are not in a time-constrained, pitching event.

When you are communicating with the rest of your team, please use one of the following story models, using tech and data points weaved through your story.

The main story archetypes are:

  1. Overcoming the Monster (a big challenge in your case) (this is the problem-solution format used in pitching)

2. Rags to Riches (boot strapping / code from scratch to success or similar)

3. The Quest (research and solution or similar)

4. Voyage and Return (lots of external work culminating to something closer to home, or similar)

5. Comedy (make it fun, within formal limits of workplace as per where you work and if the comedy is non-insulting)

6. Tragedy (try to avoid this in a communication unless you have an angle that you can use — in most cases, tragedy repels people)

7. Rebirth (the phoenix rises — how you made it happen when everything failed)

You should use only one of these at a time in your communications. While you use these models, subconsciously the audience (even if one person) is relating to stories, fairy tales, comics or even movies — you can relate all such stories to one such model.

Experiment talking with people using these models, and in no time, you will start seeing how quickly you can make your point across compared to logical and technical explanations.

Image Dilbert.com

Side note: If you need specific help with soft skills during pitching events, this is a good link.


Practising Self awareness when delegating

— patience, appreciation, engage, validate, trust

In the long list of soft skills, I would rank high the practice of self awareness and delegation skills, and would consider them together.

Combining self awareness and delegation brings out the essence of communication — that it is a transference of value from one personality to another.

When you know yourself to some extent (your patience triggers, at what level you start with distrust, if you detest repeating yourself and so forth), it is easier for you to customise them the audience you are communicating with. One trick is to lay it bare in front of them — eg saying, ‘I have issues when I see a million versions of the same file’ will go a longer way than saying ‘You don’t know how to keep the latest updated version of the file’. The first sentence starts with ‘you’ while the second one is a clear accusation.

Even when you are right and the other person is clearly missing the point you have to share, start a communication with understanding of your own issues.

When I say issues, I do not mean problems of catastrophic proportions. By issues I mean, things that make you communicate less efficiently.

Let’s take the example of delegation. In any job roles, this is a highly emphasised soft skill. However, when you are in a tech role, it is more complicated.

As a tech leader, you inherently take great pride in the quality of your deliverable, and this has got you where you are. When you delegate, you are worried about that standard of quality going down, than the actual miscommunication (or ineptness of the person you are talking to).

What if she/he doesn’t get it? They haven’t got it… it took me years to get it — did they really get it? These thoughts are testing your own patience, trust, and even the ability to appreciate someone else.

Here’s the solution — break the communication into smaller chunks that fit your comfort. Practice it with team members who are already tech-literate at a level that you are happy with. Keep version control and backups for your own peace of mind.

An evidence that the communication is going to go well, is your own comfort level. This particular soft skill is really effective from practical experience.


Communication is a bridge that you build as you progress — and it is a bridge between confusion and clarity.

If you don’t practice enough, you may be stuck on one side with your audience on the other side — meet together at the middle and you will see how well you have communicated.


3 main takeaways for those in a hurry:

Tech leaders need to:

  • Use analogy to simplify
  • Using more than one kind of story
  • Practising Self awareness when delegating — patience, appreciation, engage, validate, trust

Jeev Sahoo

Share your thoughts :)