It’s both more serious and less serious than we’ve admitted
I’ve recently seen a lot of very anxious responses from people in tech at anything which suggests that their “core skills” may be devalued, especially in favor of other skills which they haven’t spent their lives on. Most importantly, this shows up in the argument over “hard” versus “soft” skills. That anxiety is itself a signal of how important this has become. But there’s a hidden assumption we’ve been making that (I suspect) has increased the anxiety far out of proportion: and maybe perversely, it comes from not taking soft skills seriously enough. Today, I’d like to share some thoughts on what’s actually happening, and a set of things we can do to help fix it for all of us.
1. Some observational data
One of the most reliable ways I can see anxious responses on the Internet is to suggest that soft skills may eclipse hard skills in importance for engineers. By “anxious responses,” I don’t mean “disagreement:” I specifically mean emotionally charged disagreement. And that emotional charge is a very important data point.
One very reliable pattern I’ve observed in a lot of situations is that the strength of people’s emotional response to a statement tells you a lot about how close this statement cuts to their biggest worries. It’s sort of obvious if you say it that way, but if you apply it as a detection method, it’s very powerful: strong responses lead you to where the real problems are, the real threats to people.
(This trick is shamelessly stolen from psychology, specifically from psychotherapy, where it’s a reliable way to figure out which issues are most salient to someone. A good rule of thumb is, the harder something is to talk about, the more likely that it’s important. It has many other applications, as well; for example, if you find people very offended by the suggestion that they might be or like something, that’s often a sign that this “something” is closely associated with a group that they’re similar enough to that they’re at risk of being mistaken for it, but that they have a very strong reason not to want to be affiliated with.)
What’s interesting in this case is that people are so concerned about the relative value of soft and hard skills, and not, say, overall economic fluctuations or an oversupply of engineers, two other things which could just as easily threaten an engineer’s status.
We can treat the frequency of strong emotional responses as a sort of covert wisdom-of-the-crowds signal. With regards to cultural matters, the wisdom of crowds is an even better signal than it is in general, because the culture is made up of those very same crowds. Reading the pattern of conversations and responses over the past few years, the scale of anxiety I see when the issue comes up suggests a pattern: lots of people have the gut instinct that the rise of “soft skills” is going to be big, but are afraid of what that may mean for them.
2. What‘s going on beneath that
Stepping back a bit, it’s not horribly surprising that it would be big. The reason the “brilliant, irascible loner” has become increasingly rare is that very little technology is built by a single pair of hands anymore. My previous job consisted, in no small part, of trying to build and maintain a consensus among hundreds, sometimes even thousands, of people, in order to keep everyone moving in one direction. This was something extremely difficult; like most people in the field, it’s very far from what I was trained for, and I had the perpetual sense that I was faking it and hoping nobody would notice.
When you’re working with large groups of people, communication and collaboration complexities quickly become the dominant factor in success or failure. Concepts like “psychological safety” and “mutual trust” become the things that dominate your day-to-day work far beyond any specific technical challenge. At the junior level, it’s because this affects your quality of life: trying to do good technical work while surrounded by people who hate you is both difficult and awful. At more senior levels, this becomes more and more of your responsibility to manage and create. This is closely tied to the deeper difference between junior and senior roles: a junior person’s job is to find answers to questions; a senior person’s job is to find the right questions to ask. The number of purely technical questions requiring any given level of expertise decreases relatively sharply once you pass a certain threshold, and the increasing prevalence of everything from reliable compilers to Stack Exchange means that more and more of the hard technical questions are straightforward to answer.
[Bad management] is a field that was built up out of people who often believed that they had good soft skills, while actually having atrocious ones. The simple fact that people feel not respected by their managers should be a tremendous red flag.
There always remain various hard ones, of course, which are critical and which can’t be solved by any number of inexperienced people except by them getting experience; that’s why we need to continue to build and grow our technical skills. But if you continue to grow your skillset, you’ll quickly discover that the amount of time that needs to be spent on these extremely difficult technical problems tends towards significantly less than a full-time job; instead, the crucial (and incredibly hard) problems that affect a system have more to do with how that system interacts with the outside world — which is, more and more, people.
Interestingly, there’s a lot more crossover between hard and soft skills than many people realize: when you start to see your system as a component of a larger system which includes humans as elements, and you start to ask how humans interact with each other and what their behaviors are, then many of the same “hard skills” systems design approaches not only make sense, but can provide even better answers to traditionally purely “soft” questions. Abuse prevention on multi-user systems and result ranking of all sorts are two classic examples; in both cases, the ability to convert freely between very “soft” intuitions about what people want and very “hard” mathematical expressions of those same intuitions is priceless.
But beyond the cases where soft and hard skills overlap within the technical work itself, a lot of the “soft skills” being required now have a lot more to do with people management. This is a field which historically has a bad rep among engineers, because it’s historically been done by people who had no engineering skills, and crucially, who lacked respect for said skills or the people who had them. This is because a lot of management came out of the early 20th-century version of industrial management, the same field that gave us phrases like “human resources:” the workers are an annoyance and an expense, something which has to be “managed” to keep production quotas high.
This kind of “management” — I use the term loosely — doesn’t constitute good soft skills, either. It’s a field that was built up out of people who often believed that they had good soft skills, while actually having atrocious or even actively pathological ones. The simple fact that people feel not respected by their managers should be a tremendous red flag: a manager’s basic job, after all, is to coordinate people and get them to work as a team, and if they can’t hack the most basic aspects of mutual respect themselves, there’s no way they’re going to be able to create that for everyone.
The fact is that the kinds of “soft skills” we’re talking about aren’t the ones that come for free to anybody; they’re not the things taught in “manners classes” or in fraternity hazings. They come from studying people, paying attention to them, and understanding what they need even when they can’t express it themselves — and as such are as brutally difficult a set of skills to acquire as any other professional expertise. Our habit of treating them like they’re not “real” skills, of trying to deprofessionalize and devalue them, does us no favors; when we’re called upon to do them ourselves, we quickly find out that they’re not trivial.
(I’m reminded of a Certain Engineer I Know who, when moving the team into a new building, made the fateful statement that interior architecture should be easy, he’s an engineer, he doesn’t need to get someone else to do this. The results were certainly interesting. Engineers, scientists, and executives all seem prone to the disease of believing that everyone else’s speciality should be easy.)
3. Good news: there’s a way out.
I think there is one very “simple” thing we can do to improve this situation: start to treat these skills like serious professional skills, value them as such, and both train and hire people for having them — the exact same way we do with every other critical skill.
A good first step is to make sure we have, and share, a language for it. It’s very hard to value something you can’t name. Some common tasks which we often ignore are “make it possible for everyone to see what’s going on in the project at once,” “create a shared language for the core technical ideas so that everyone can explain the same thing,” “make sure that everyone’s voice is heard, and that important warnings don’t get lost because someone didn’t feel safe saying so,” and “make sure all the stakeholders feel a sense of personal ownership in the project and that their success is tied to its success.” (There are many more) Some common measures which we often ignore are “how often will a user/customer experience frustration or negative emotions while using this product, and how does that affect their long-term usage?,” or “when someone has a negative experience using the product, what is the following experience on each time scale from 10ms to one week, and how does that affect their experience of the product?”
None of the things in that previous paragraph are new: in fact, they’re all tied to professional specialities, from project management to user experience research. But if a team as a whole treats these as side things rather than as core to their success or failure, they can easily end up in the middle of a disaster: milestones missed, different groups building subtly different systems which only clash during final integration, a critical problem being ignored until it’s too late, a project being subtly sabotaged because one team actually didn’t want it to succeed, users hitting one “small” bug and revolting in horror (leading to anything from mass exodus to legal and regulatory action), slow erosion of user trust. I’ve seen projects fail for every one of these reasons — even projects where the purely “technical” aspects of the engineering were beyond reproach.
To treat such things as core rather than peripheral, we would expect that everyone on the team have at least basic knowledge of them, enough to evaluate their significance even if they aren’t the person running it themselves. These need to be considered parts of roles on the team, just like front-end engineering, back-end engineering, security, and site reliability, and the team needs to think about who’s going to be covering which job.
It is more than OK for each engineer to not be individually able to do all of these jobs. In fact, it would be stunning if any one person could do all of these jobs. But if we treat some of these jobs as “invisible labor,” unvalued and unaccounted-for, with skills we pretend don’t exist, all we do is shoot ourselves in the foot.
We do this in the obvious way by not provisioning for them. But we do it in a less obvious way, by frightening ourselves unnecessarily. The anxiety that this story began with is a symptom that we all know that something is profoundly missing, and that this missing thing is becoming more and more important. If we treat this missing thing as “not a real skill,” something which some people (I’ve often heard “women” and “frat boys” given as examples, typically not at the same time) just can do automatically while engineers can’t, then it becomes frightening because it starts to sound like engineers are going to get thrown out in favor of random people off the street, who will then have no respect for the engineers at all. But if we recognize this as being a real skill — something people practice and get good at (or bad at) over their entire lives — we have a different language for it. That’s the language of “Crap, our team has nobody who knows how to do X, and we’ve been faking it really, really, badly:” a language painfully familiar to anyone who’s worked on a project before. It is absolutely true that a lot of the people who are best at these skills don’t come from an engineering world, because the engineering world has been steadily failing to train people at them for decades; but that doesn’t mean that these people don’t have any understanding of, or respect for, engineering.
At the risk of stating the obvious: Someone who’s supposed to be doing a job involving coordinating engineers, or connecting engineering systems to users, or anything else like that who doesn’t respect engineers is going to be terrible at that job for obvious reasons, and you shouldn’t hire them. “This person makes the team feel miserable” is a serious red flag, not a normal side effect of how any of these jobs work.
But to state the flip side of this: Everyone on a project needs to value, and to understand at least enough of the basics of to participate in, every other skill on the project. If there’s a legal issue relevant to the system, everyone needs to know that bit of law. If there are user studies showing that people react well or badly to something, everyone needs to put those into their designs. If there’s a latency constraint which makes certain classes of product behavior impossible, everyone needs to understand the issue. And likewise, everyone needs to understand and value the human skills: after all, you’re building a system which at the very least includes you.