We’ll start by digging into what soft skills are, and then define what it means to “engineer” them.
Soft skills refer to skills for dealing with people. “People” includes both yourself and others, and “dealing with” covers not only communication but also documentation, creative thinking, management, and more. Even within communication there are synchronous and asynchronous forms, and management also includes self-management. In that sense, it’s an extremely broad domain.
When you hear “skills,” you may think of hard skills. Hard skills are skills for working with machines and tools, laws and regulations, accounting, and other academically established systems. Even if they’re about humans, medicine is a hard skill, and psychology or economics might also be considered hard skills.
Put differently, what separates hard from soft is whether there is a correct answer. Hard skills have correct answers, and they can be measured reliably, quantitatively or qualitatively. You could say you can know the results. In contrast, soft skills are not like that: there is no correct answer. There are only decisions and their outcomes. That’s because they deal with human beings—something extremely complex and deserving of respect.
A definition you often see is “soft skills are mainly skills related to communication,” but you should discard that definition immediately. Communication skills are only one component of soft skills. In fact, getting fixated on communication skills leaves no room to think about other soft skills.
Communication skills within soft skills are like the C language in programming. They are fundamental, and with them you can do a lot—but they’re also classic and primitive. People and organizations that chant “communication skills” all the time are like those who chant “C language” all the time.
I wrote that soft skills have no correct answers. What exists instead is each person’s and each organization’s way of being.
Let’s use 1on1s as an example.
There is no single right way to do 1on1s. It might be a 30-minute one-on-one meeting held once a month between a manager and a direct report. Or it might happen weekly. The topics can range from serious ones like work and career to simple small talk. And even the same manager would likely adjust their approach depending on the person and situation.
What’s important is to give concreteness to the “answerless practice” of 1on1s. You could even say to implement it. It’s the same as software. Just as you implement software from requirements, you create and operate a concrete instance from the concept of a 1on1.
For example, you might define a concrete instance like this:
It’s like a function or an instance. Of course, by changing parameters you can create another instance. See below.
I’m developing an approach called Free 1on1, where “any employee can request a 1on1 with anyone at any time.” The original inspiration is GitLab’s Coffee Chat.
Because it’s developing a concept, it might look difficult, but it’s not. As described above, it’s nothing more than a configuration file.
Do you see it now? Soft skills are like software: they are something each person can implement.
However, there is one obvious difference from software. Software runs by being executed, but soft skills must be operated by humans themselves.
The Free 1on1 described above is also just text. People have to act on it. Of course, you can’t suddenly force the entire company to adopt it (in software terms, deploy it as a company-wide system). If you truly want to do it, you’d submit it formally as a proposal, or start with a small volunteer effort and build momentum bottom-up. Naturally, this requires communication, management, and many other soft skills.
In that sense, it’s similar to software. During software development, you use a huge amount of software. Likewise, when developing soft skills, you also use many soft skills.
Now that the groundwork is ready, let’s get to the main point.
Soft Skill Engineering is the engineering discipline of enabling you to handle soft skills yourself. It includes putting implicit practices into words, customizing existing ones, and of course creating new ones from scratch. Since that’s long, it’s sometimes abbreviated as SSE.
It’s engineering, but the approach leans soft rather than hard. In other words, it’s not a “game-like world” where a single or a small number of absolute theories or phenomena exist, and everything is about learning them and mastering them through practice and experience. It’s softer than that.
Just as software is made of parts like functions and modules, soft skills are also made of parts called concepts (verbalized text). “Concepts” may sound abstract, but here you should think of them as including anything put into words: concrete procedures and other lists, guidelines that state clear principles, and so on. Of course, some concepts are proven effective through research, while others are simply verbalized on a whim by a particular individual.
With that, we can define it even more clearly.
Soft Skill Engineering is the engineering discipline for creating concepts. This includes two things: creating concepts themselves, and implementing some soft skill by combining concepts. It’s a system organized so that anyone can do these two things.
There are no correct answers when it comes to concepts. While they differ in effectiveness and authority, you are free to use anything. This property is what we call “soft.” In contrast, in the world of hard skills, there is a single correct answer or a small number of theories, and everything depends on how well you can follow them. In essence, it’s a game. To win, you have no choice but to choose the most established means available and keep using them. We called this “common” property “hard.”
Software engineering is hard, and we developers, managers, and others in business tend to prefer hard things—but Soft Skill Engineering is different. It’s soft.
Soft skills:
Concepts:
Soft Skill Engineering: