What the heck are soft skills and why are they important?

A good engineer is more than just a sum of their technical knowledge and ability to code - this is something I learned very early on in my own career in IT, as my first foray into the industry was as a client relations trainer for Ukrainian-based engineers.

Even these days, when the IT market has never been hotter, a common issue with failed collaborations and endeavors boils down to a breakdown in communication and a lack of so called “soft skills” within the engineering team. But what are these so-called soft skills, and why are they so essential to the success of a given project? Let’s review a few of the more nebulous skillsets and discuss how they play such a crucial part in software development teams.

Proactivity

One of the first common issues that teams run into, particularly within outsourcing engagements, is the seemingly absent ability in developers to take initiative and be proactive in their efforts in putting together a platform. A PM might find that without constant poking and micromanagement, a developer might simply “sit on their hands” and wait for concrete directions to complete a task. In other cases, a developer might follow a set of given instructions to the letter, but not take into account any architectural or design improvements that are not explicitly written out in a given assignment.

I’ve found that there are a variety of reasons for this phenomenon -

• The instructions from the product owner/manager are well and truly vague, and developers are too shy or afraid to call out the PO/PM on this issue.
• The devs are scared to make a mistake (this is especially true with clients who want things done exactly a certain way and therefore put off the developers from thinking outside the scope of their mockups/tasks).
• Some devs have a firm belief that the PO/PM’s job is to do all of the planning in such a way that there is zero room for misinterpretation. If a feature is not precisely laid out in the scope document, and the final project isn’t what was expected, then that’s the fault of the PO/PM. The engineer just does what they are told - nothing less, nothing more.

The key issue with this approach to development is that often enough, the client simply doesn’t have the time or resources to spell out every element of a task - for many startups, the manpower isn’t there to create high fidelity mockups and technical scope documents for the engineers to follow. Therefore, it falls on the shoulders of the developers to be proactive and treat the project like an actual shareholder would.

Accountability

Another key element to the success of any team is having a high degree of trust between members. It’s important for folks to feel secure in their co-workers ability to fulfill their duties and responsibilities, and to “get the job done.” If people start to suspect that other team members aren’t pulling their weight or need to be babysat in order to complete a task, productivity breaks down and a dangerous toxic workplace can develop in its place.

Oddly enough, in most situations I’ve seen where accountability was an issue, it wasn’t even the case of people avoiding work or being lazy. Often it was simply a lack of communication to other shareholders, i.e., engineers not reporting to the rest of the team what they were doing and where their focus was.

With an inexperienced product owner (who might be expecting visible improvements/new features on the platform on a daily basis), this leads to suspicion and eventually paranoia as they start to assume the worst about the engineers who are in fact knee deep in building the platform.

This also is apparent when mistakes are made. Bugs and issues are an inevitable part of software development, but it is far better for the developer to be upfront and transparent about a problem as opposed to downplaying the origin or seriousness of the issue. Obviously it isn’t practical to expect developers to keep track of every edge cause bug and glitch, but clients understandably are concerned when engineers act surprised when the entire platform is down for a standard sprint retrospective.

Taking ownership of these situations when they happen helps maintain that degree of trust, whereas playing dumb and acting shocked when they occur is a surefire way to lose all confidence from the client.

Empathy

The final quality I’d like to mention is probably the most vague and subject, yet potentially the most important - empathy. People like to work with folks that they feel are committed to the same cause and are truly engaged in the project. It’s also a lot more fun and interesting to work with people you get along with, and who listen and take into account your concerns.

Much like the other skill sets mentioned, I don’t doubt that most engineers care about the projects they work on - people like investing themselves into their work and seeing the fruits of their hard work and effort in the form of a successful launch. However, it is communicating this desire to team members, most often ones you rarely if ever see in person on a regular basis, that can stir up the feeling of outsourcing engineers being “emotionless drones” or “mercenaries” who are completely indifferent as to whether the platform goes on to be used and appreciated by other people.

Demonstrating empathy as a software engineers basically boils down to three things:

1. Asking the client what they want (specifically)
2. Listening to what they say they want
3. Repeating back what they want in the developers’ own words, demonstrating that they and the client are on the same page

Doing this constantly requires work and effort, but it provides an immense help in avoiding unfortunate miscommunication and instills a great deal of confidence and respect for the team from the customer’s side.

Is it possible to learn soft skills?

I’d argue a resounding “yes!” - while many feel that these sort of traits are inherent in an individual’s personality, I strongly believe that all of these skills can be learnt and perfected by anyone who recognizes their value and is willing to dedicate focused effort on improving them.

Unfortunately, there aren’t any widely accepted certification courses in “empathy” or “accountability,” probably because it’s hard to quantify these traits into measurable accomplishments (“I’ve listened to clients 100 times over the last year!” doesn’t sound impressive, although honestly it is an achievement, assuming you produced good results from all of that listening!).

However, at Binary Studio, we spend a great deal of energy and effort in developing these skills in our engineers through our own training program, Binary Studio Academy. A major part of our Academy program is emulating an actual commercial development environment, where our cadets work under the same pressures and deadlines that we’d expect them to run into with a real client. Management members at Binary Studio fill the role of product owners, giving real world experience to future Binarians while allowing us to evaluate and select those who already have a strong start in each of the skill sets mentioned.

In the end, while engineers are ultimately valued for their technical capabilities - their ability to work in a team and demonstrate a high degree of professionalism and ownership in what they do separates the average developer from the top-tier ones we aim to have in the Binarian family. And for those engineers on the fence as to the importance of soft skills - just ask your current customers their thoughts on the subject, and I’m sure they’ll agree that these traits are essential in climbing the professional ladder and being the best engineer one can be!