About Soft Skills

During the late 1990s and early 2000s, I was knee-deep in Linux. For about two years, I ran a community site with open-source news and promoted what was clearly going to be the winning operating system. Of course, I also dipped my toes into FreeBSD and OpenBSD and even ran one or the other for a while.

As the other folks and I working on the site gained some traction, we reached out to Linux distributions backed by companies across the globe, and they sent us boxes and CDs with their versions. We received copies of Caldera Linux, TurboLinux, Corel Linux, and many others. I can’t even tell you how many Linux distributions I tried over the years.

The one we connected with best was SuSE Linux. So much so that, at one point, I was invited to man their booth at a major tech conference in São Paulo. I loved SuSE, and for a long time, my main computer ran it. Whenever I got a freelance job, I recommended SuSE.

But as I kept working, tinkering, and evaluating, I ended up loving Debian more. I adopted it as both my desktop option and the server OS I used when deploying systems for customers.

Fast-forward a little, and a former manager invited me to join him at a medium-sized bank where he had just been hired. Apparently, I just had to clear a pro forma interview with a director.

The conversation started well. The guy was smart, funny, and extremely excited about open source and Linux. And then he asked me what I thought about Red Hat Linux.

Oh boy.

I had strong opinions that Red Hat was bad and Debian was good, and I told him very colourfully.

I didn’t get the job.

Many years later, I was managing IT at a SaaS company, and we were looking for a DBA. The application had grown enough, and we had some large customers who were bottlenecking us on the database. No one in the company had the skills and knowledge to take us to the next level. As a fairly small company, we were running on MySQL.

This guy came to the interview, and he did great. He really sounded like he knew his stuff and communicated well.

So I asked him what he thought of MySQL.

Oh boy.

He said MySQL was a toy database, no better than an Excel spreadsheet or an Access database.

I didn’t hire him.

Fast-forward a few more years, and I was officially an enterprise guy. Of course, I also had an RHCE certification by then. That’s when I got an interview at Google.

It was a whole-day process, and during lunchtime they assigned me a Googler to take me to lunch.

The guy had read my resume and asked, out of the blue, “I see you have an RHCE. What do you think of Red Hat Linux?”

This time, I nailed it.

I don’t remember my exact answer, but it was technical, fact-based, and emotionless.

I got the job.

Not only because of that, of course. And, funny enough, Google doesn’t even run Red Hat.

Many times in my career, I have made grave communication errors, or seen other people make them. Not because they were wrong, but because we are so eager to express our opinions that we end up playing against ourselves and our goals.

I remember once having a boss tell me, after a call with a customer, that I had managed to give the most correct wrong answer.

He was right.

What I said to the client was technically correct. There was nothing wrong with the answer itself. The problem was that it didn’t help our case at that moment.

It was something we could address if things progressed, but I had focused so much on being correct that I missed the bigger picture.

And that is probably the real lesson from all these stories.

Being right is not always the goal.

Sometimes the goal is to get the job. Sometimes it is to get the customer to say yes. Sometimes it is to convince someone to adopt an idea. Sometimes it is to keep a difficult conversation from becoming more difficult.

And sometimes, yes, the goal really is to be technically correct.

The trick is knowing which one matters at that moment.

I keep coming back to soft skills because, with the progress AI is making, they are becoming some of the most valuable skills you can have.

Producing code is increasingly becoming easier. AI operations are slowly gaining ground. More and more of the technical work that used to require years of experience can now be assisted, automated, or simply done by asking an AI.

What AI still struggles with is understanding what people actually need.

A customer may ask for a particular feature when what they really need is something completely different. A manager may ask you to solve a technical problem when the real problem is organizational. A team may insist on a particular technology when what they actually need is to simplify the system.

Those problems require context.

They require asking the right questions, understanding people’s needs and desires, communicating clearly, finding the right business solution, finding middle ground, negotiating, and sometimes simply knowing when to shut up.

These are not new skills. They have always mattered.

But as the cost of producing technical work continues to fall, I think their importance is going off the charts.

Knowing how to build something is valuable.

Knowing what should be built, why it should be built, and how to get people to agree on it may be even more valuable.

Need help? If you are dealing with technical complexity, struggling to align engineering with business needs, or simply need an experienced technical leader to help you figure out what actually needs to be done, I may be able to help. I offer selective consulting engagements focused on practical, pragmatic solutions. If you think I could help your team, learn more about what I do at ebastos.dev/about.