Society is defined not only by what it creates but by what it refuses to destroy. – John C. Sawhill

Before we start, if you are not familiarized with the terminology, here is a short explanation:

Soft Skills: personal attributes that enable someone to interact effectively and harmoniously with other people (Google).

Hard Skills: specific, teachable abilities that can be defined and measured, such as typing, writing, math, reading and the ability to use software programs (Investopedia). In this case, we are using the analytical part of it.

The rise

Before the agile mindset, project managers used to apply the classical engineering style to handle software projects. The PMBOK (Project Management Body of Knowledge) was, and still is, the source of very good practices and tools for project management. And most of them work in regular industries, the ones that are not as organic as the software area.

However, the software industry misused the PMBOK. They thought all the practices that are mentioned in it were too hard-skilled and wouldn’t work in a fast-paced environment as the software industry. And yes, it has all those hard-skilled practices (and some of them do not work with software development), but they were all glued together by team-building actions that people ignored at the time (some of which can be seen in the Human Resources chapter). But, as I presented in the aforementioned blog, a revolution took place, and made the industry crucify and bury those practices, without even look if they were all really that bad. As a result, they saw themselves tool-less and decided to react and build their own tools.

The death

With that, came all the Agile methodologies and their toolsets. Moreover, since the industry lacked soft skills at that time (the trend was to act like bosses: telling other people what, when and how to do stuff), a natural path for the revolution was clear: improving soft skills.

And it happened! At least the new practices facilitate that… if people apply it or not on a daily basis, it’s another story. With that mindset in place, the boss image was abandoned and leader figures were created. Focusing on the code quality and not so much on documenting everything. Letting developers get much closer to product stakeholders than before because that communication between them needs to be proxy-less (in a perfect world at least).

But things were still not smooth. Most companies started using Scrum, improved their process, but reached a stagnation point in which something was wrong, but they didn’t know what. The team felt better, working this way, but it was more difficult to spot problems in the process. Talking about deadlines with clients became taboo. And scrum masters would basically annoy the business area of the companies, which wanted predictions to improve their plans.

Basically, the process improved inward: the development team was happier and more effective. But they forgot to improve the technical communication outward: with other areas, with business, marketing, clients, etc. These areas need more data about the software in order to build their plans. And with that in mind, some hard skills, that got lost years ago, came back.

The rebirth

At Plataformatec we embraced hard skills, as most of our agile blog posts show it. We think that having good and advanced hard skills is not a sin, we can and should have as many metrics as possible. However, with metrics, comes great responsibility (this is somehow familiar… 🤔).

Metrics serve as a way to ease the conversation between areas (or with an external client) and to improve our processes inside the team as well. For both, we need to be cautious and not present loose metrics (showing them without the proper explanation and contextualization). If that happens, they can become a way to demand more work and to micromanage the team’s deliveries, which, usually, is not healthy. (Another post on the common mistakes when using metrics is on its way…)

If you wanna take a step further and improve your hard skills toolset, you can take a look at our free Monte Carlo spreadsheet, which uses Monte Carlo simulations to inform you the probability of finishing your project in each of the next weeks!

So… Which one is more important?

Both are extremely important. Soft skills without hard skills make the team happy at work but probably inefficient. Hard skills with no soft skills make the team aware of their problems but with no motivation to change. We need to balance both. I’ve already heard questions like: Oh but should it be like, 50/50? 80/20? And I answer with this question: How would you even measure how much soft skills and hard skills you have?!

So, the conclusion is: have both, improve both, care for both. If you think you already have enough of each, you are likely wrong. This should be the mantra of all project managers/Agile coaches out there… You must have a motivated team and enough data to facilitate communication and improvement.

What about you? Do you prefer one skill over the other? Leave your comments below!