Are Technical Skills Overrated?

Hold on, before you go all out on me, I’m a software engineer myself and as such, I understand the impact of technical knowledge. The impact of knowing React, NodeJS, Python, Ruby, Rust, PHP, and whatnot — you could build an Uber or Facebook and solve some of the world’s toughest problems with that knowledge. You could probably build your own Amazon, Microsoft, Google, Slack, SafeBoda, Jumia, Twitter and any other tech giant you could think of but what enables you to thrive while at it is not exactly the tech that you know, as we will see further on in this article.

First things first, think about this: was any of those tech giants built to their current capacity by a single individual in a dark room with a hoodie over their head and lots of caffeine in their system? The answer is most definitely no. It took several people to bring those ground-breaking applications to the glory they have today. This simply means the knowledge of how to code isn’t all there is to it. It takes a team and as such, one must be able to work productively in a team. That right there is where technical skills tend to get overrated.

I once worked on a project with a software engineer who didn’t have much programming experience and it was very evident in the quality of work he delivered. It was probably the toughest time of my work — not because he didn’t know what to do sometimes (because that happens even to the best in this industry), but because he was never receptive to feedback that required him to think differently about things, however nice we’d try to craft it. He just never liked being shown that what he’d done could be improved and as such, we ran into multiple problems whenever anyone was working on a task that related to his. We would have to change a lot of what he touched and as such, the progress was really slow and in some cases, the quality of the work we had in the end product by release time was subpar.

In contrast, I worked with another person on another team during a boot camp and the experience was completely different. He was not as technically adept as the former engineer, but he acknowledged that and it was very evident that he wanted to learn from those who knew more than him. He always reached out when he didn’t understand something and repeatedly bugged us until he understood it. He always kept us in the loop about what he was working on, in as little proportions as he worked on. He always asked for feedback and he, ironically, wanted to hear the negative feedback more. Whenever you praised his work, he always asked questions like “How would you do it?” followed by “Why would you do it like that?” and if he realized that your approach had performance benefits to the products, he’d strive so hard to implement his next task with those benefits included in his solution. He was the ultimate workmate. Working with him felt like a challenge even to those who knew more than him because he got you to think about why you’re doing what you’re doing and in the process, you all learned together.

One may argue that at the end of the day, it was the technical knowledge that brought this awesome product to life but if you think about it, it wasn’t. It was the fact that our team was teachable, had great communication skills and those aspects powered the technical side of things. Even in a situation where you don’t have a struggling team, moments where you have only superstar engineers on your team, where they seemingly can’t do anything wrong, they most definitely need to remain teachable because user needs evolve, and technologies evolve as well. Today we’re writing Javascript but 30 or so years ago, it didn’t exist. Several decades ago, programs were written in BASIC which is rather obscure today. Technologists have to evolve through many technologies for us to remain relevant and create better solutions for the world.

Anybody can learn code but not everybody is ready to always remain teachable. Not everybody is ready to take in negative feedback positively. Not everybody is ready to change their introvert selves just a small bit to start communicating effectively. Not everybody has a high degree of integrity. A lot of these aspects are attached to one’s personality and that isn’t something that changes over a day or two. In some people, it never changes and yet we’ve seen the depths to which they impact the progress of a product that’s intended to turn out like the next Amazon, say.

People don’t just wake up one day and the grumpy attitude from the previous night (and weeks before) is suddenly turned into a charming and welcoming attitude to their teammates. It takes a much longer process for that to happen, but if it was a matter of writing code, some people can quickly check out a Django documentation and, by the next morning, they could build kickass Django apps. This also introduces the concept of EQ (Emotional Quotient/Intelligence) and IQ (Intelligence Quotient). It is much easier to grow your IQ than it is your EQ and I think this has been a crucial part of Andela’s hiring since the company’s inception and as such, has helped us become a strong force to reckon with. EQ (Emotional Quotient/Intelligence) goes a long way to impact your IQ (Intelligence Quotient).

An engineer that works with EQ as much as they do IQ will forever be relevant and you just can’t afford to ignore them.

I’ll leave you with a short quote from a renowned author.

“There is no separation of mind and emotions; emotions, thinking and learning are all linked.” — Eric Jensen