One of the most important skills is the one he describes like this:
>> The more specialized your work, the greater the risk that you will communicate in ways that are incomprehensible to the uninitiated.
In my experience (35 years), this isn't just about knowing the right way to describe things, it's also understanding what things to concentrate on when communicating, and what to ignore. If you are a tech person communicating with a decision maker, they are typically looking to understand options and their implications and risks, not the details of how the options work. They can then decide, based on their (presumably) better knowledge of the wider context, which options to select. If the decision makers are genuinely intelligent and motivated, but their eyes glaze over when you describe something, chances are you have chosen the wrong things to communicate to them.
They won't be doing it, they will be doing a simulation of it. How are they going to learn business communication without doing it in the context of a real business with a real P/L line and real consequences for good and bad execution?
It appears that they key skill is coordinating a lot of developers, because the ones left developing are the ones you need a lot of (and who need close supervision) to get anything done. Managers will never rock this boat, because their career KPI is the number of people they manage.
Which is not to say they're doing everything right.
Relevant: https://www.spakhm.com/p/parallel-tracks
"Why did all major software companies settle on parallel career tracks? To keep engineering managers from developing loyalty to engineers."
Having no track even better. Some people like what they are doing and the field is constantly changing. You want your best surgeons doing operations not managing other doctors.
You need some kind of title so people can feel responsible for career growth and so you can calibrate against other companies' pay at least; it doesn't need to control what kind of work you're allowed to do.
And, as you say, to the degree that position titles mean something cross-company, it gives a point of comparison.
This seems to miss the point of teams. Everyone should have a role if you hire someone as a software engineer and they spend all their time doing devops because they like it more you've made a bad hire. If all your engineers are having product meetings with various departments then you've again made bad hires. Everyone should have their role and fullfill that role to work as a successful team. People thinking they're above fullfilling the role they were hired for is one of the fast ways to have a poor performant team. To put this into sports you don't want your defender to be constantly hanging around the other team's goal mouth.
Individual coders/contributors' compensation don't scale until they are shown to "score a goal". And yet, to do so, they may have to stop contributing in their usual, assigned role, but go "above and beyond" - such as redesigning the system, or to make their mark on the product and be recognized as such.
This, i find, is probably what the fundamental problem/friction with teams are.
Your job satisfaction/pay are also a function of how unique your skillset is.
With this in mind, increasing your impact (through soft skills) is just one of two ways to increase pay - the other way is to do something that not many others can do. For many people, doing something unique is far more satisfying than dealing with people problems.
These are not mutually exclusive. If you want to accomplish big unique things, you can't do it yourself. You are going to have to convince others that your big new idea is worth doing so that they will help you achieve it.
I'm skeptical. I mean, sure, for most people, the ability to convince a large number of other people to do things, to do your things, without worrying how they do it, is going to have more impact than any other contribution they could make.
On the other hand, Van Jacobson's algorithm is like four lines of code (I used to know where it is in *TCP/IP Illustrated, Vol II.) and is responsible for the Internet as we know it. That's an awful lot of impact.
Effective software engineering in a business context requires awareness of business needs.
Which part of that is “bashing and shit talking”?
Effective software engineering in a business context requires awareness of business needs as well as the technical skills to address those needs.
I've sat through dumb two hour meetings about deciding which words in a document should be capitalized. Is that what is meant by "make sure your team/business is doing the right things?"
I agree with what you're saying in part. Pure coding skills are essential, especially in critical situations like that. Soft skills won't fix broken things, for example. Salespeople can't deliver the features they promise without someone to develop them.
However, soft skills can help someone with excellent coding skills to know what to apply their skills to and when, and how to integrate their skills within a broad team of different disciplines.
This is arguably true in any field; I think it's often missed in software development because people have such a difficult time distinguishing boundaries of things. The problems you're solving, when you're passively or actively solving problems, when output is applicable to a specific problem, etc. Even software engineers themselves struggle with this.
Your ability to save your company's ass is an excellent skill to have, but it isn't directly related or exclusive to what the original comment was saying.
When I saved my company's ass those times, no non-technical people were present and it was wholly technical knowledge that solved it. I could have and probably should have ignored the problems and let the talkers try to fix it and take the blame for millions in losses. So it is very apropos to the original comment.
Even though it sounds good, this is actually a bad measure because all coding consists of constantly making new zillion-dollar mistakes and then fixing them as you go. You can always do a worse job, and if we're supposed to be impressed by you visibly fixing something, then mess up and fix you will.
Your job satisfaction/pay are a function of your impact. Your impact is a function of your leverage.
If you're a "pure coder" who doesn't have any of the other skills you mentioned, your output is incredibly limited. At best, you produce a day's worth of code in a day, but you also require someone to manage you closely to make sure you code the right stuff.
The more of these other skills you have, the more you can (a) work independently (b) make others more productive and (c) make sure your team/business is doing the right things and (d) drive overall efficiency.
The more of these things you do, you become orders of magnitude more impactful than a pure coder.