“Technical” Skills
sashalaundy.com
sashalaundy.com
This whole hair splitting about the real meaning of the word “technical” adds little. Yes, people who are good at what they do, whatever it is, are good at it and thus have technical skills. This doesn’t change anything about what the coder means when they ask if the boss is technical. We all know what they mean. They mean “can they code?”
More generally, I would declare anyone who does anything with engineering or numbers in it to be 'technical' in this vague sense. But details depend on context. Eg if you work in a bank, some quants might be very technical (and be seen as such) without necessarily programming.
It is important to know which kind you are working under.
That's really important. It's annoying to constantly have to explain and justify basic things because people in power don't understand what the workers are doing. I'm also pretty sure that's true regardless of who you are, which company or industry you work in and what you do, you'd prefer to be lead by people who understand what you are doing.
My manager is not technical. The work environment is shit. Just a constant stream of brotherhood decisions that don’t work you are supposed to deliver systems into. The whole thing is bloody stupid but if our manager had a clue it wouldn’t happen. Before you ask, yes we try but the stupid bugger can’t stick to a script despite how easy we make it because the other managers constantly pull him into the suck of what suits everybody else rather than what works.
I hate the bastard.
The article makes it sound like it the usage implies some devaluing of those who are not technical which is not the case (outside tech bro culture)
"is this person one of us or is he an outsider not understanding how great we are, and how do we make sure we convince him our skills are better than his".
Programmers are often very proud. Too proud to accept other people's skills. That's arrogant and unintelligent. Stupid even.
Doctors ask "have you ever treated a patient?"
Pilots ask "how many flights have you flown?"
This distinction is pretty important for the expectations to be set right, so throwing ourselves into another euphemism treadmill feels like a bad idea, this always leads to a lot of confusion for questionable gain. I'd rather we just tried to make people value "soft skills" more if the problem is that people do not.
If
The rationale was: there is no use in your hard skills in our environment if you can't communicate and collaborate.
It doesn't seem to me like "soft skills" are particularly in need to be valued more than they currently are. I would argue that the opposite is often true -- perfectly good developers being undervalued because they aren't assertive enough to "sell themselves".
varies a lot per company. But places lately have definitely skewed towards "hard skills". Training in my industry was always a joke, but they basically want 5YOE out of college these days. IDK if I would have gotten hired at any of my previous roles if this mentality was present 8 years ago.
Things like leadership, creativity, collaboration, ability (and drive) to learn new things quickly.
Basically the only ones you have a chance at demonstrating in an interview are communication (within limited parameters) and problem-solving (assuming the hiring team knows how to put together a problem that's well-calibrated for the type of candidate they actually want). And even those can easily be thrown off by the extremely high pressure of an interview.
Lots of words making a point nobody contested.
Context of our language matters. I wouldn't call my engineering manager technical in my software company just because he is really good at sewing. When program managers are called PM or TPM, there is a reason and function to it.
Also felt weirdly sexist tones in the article, if men do it it's making but if women do it is not technical? Who is saying this? Where is the straw man coming from? Non technological skills are definitely called technical in every field from film making, arts, painting, music construction, cooking, wood working, metallurgy, industrial production etc. Is the article based on solely on opinion of few ignorant people?
It goes both ways. No one is denying that things like sewing, crocheting, hell even putting on makeup takes skill and practice. People similarly are ignorant of "technical" skills too. I have been asked so many times about what is so special about typing colorful text in a window all day. Or why I can't hack their ex's facebook.
() - has a iPhone and an X-Box which in his mind qualifies him to make decisions on backend architecture designs.
Even more annoying: blog posts.
Sometimes I wonder how is it that these folks are unable to see how fundamentally wrong and clueless they are. What I've noticed is that many of these folks aren’t very good listeners. Im currently working under such a manager and it’s really exhausting to have to have the same arguments repeatedly.
The “technical skill” everyone talks about is coding - and it matters. The desire to arrange the world so it can be iterated over, the … I don’t know the difference between someone who understands a three act structure and story arc and someone who has never read a novel is a big gap
not really necessary or sufficient in many cases. the real question is whether or not someone has the background and interest to understand the details at hand and how they fit together.
The important bits about technological choices translate somewhat well between domains. A shitty overly complex motor looks impressive on the blueprint, but it is a shitty overly complex motor.
I suppose you feel you could understand the technical details of another software engineers architecture if they explained it you, even if it were written in a programming language you don't know and without reading the code?
If so, it's probably because you understand the features and limitations of volatile memory, persistent storage, networking, and parallelization. Which suggests its not necessarily 'coding' that matters.
Learning and writing lots of code is a surefire way to become familiar with those things, but I think it's possible to become familiar with them by different means.
Coding skills are different depending on the language and the kind of language, but what they all have in common is the ability and patience to think algorithmically: step by step, in terms of relevant primitive operations.
You don’t need ever to have written code to be able to think algorithmically, and the ability to think algorithmically does not translate into the ability or willingness to think critically about complex systems.
Similarly with knitting, to a slightly lesser degree. Arguably using even more spatial reasoning since you're working with an entirely soft medium.
There are reason why things are done in specific way and in specific order. And understanding those are technical skills.
Putting yourself or someone else in a bucket of "technical" or "non-technical" creates a subconscious barrier to expanding your skills beyond your label while also giving you an excuse, and others the same low expectations.
It is also a gray area I feel. Is writing efficient code a technical skill, while keeping maintainable or readable a soft skill? The difference seems similar to me.
I might be totally off here, but having a distinction has always felt weird to me.
I would draw the line differently. The line needs to be between people who have to care about how things work and people who are not willing to or don't have to care.
If you are in a tech company ideally everybody cares to some degree about the product. And caring about the product means understanding the different alternate-reality versions of that product and comparing them. And that requires some technical knowledge.
If you're the janitor or the security at that company that does not apply to you. If you are running a team, guess what.
Depends on context of course. In game dev someone who is "technical" can be asked to make the FPS higher during the boss fight, but can't be expected to re-sculpt the boss to make them look more muscular. Someone who is "creative" goes the other way around.
Someone who is "creative" uses blender/maya/z-brush/photoshop to solve problems, someone who is "technical" uses a text editor/compiler/debugger/profiler. It is a very different role. Some can do both, which is great of course, but pretending that everyone is a unicorn will not make happy outcomes.
> Putting yourself or someone else in a bucket of "technical" or "non-technical" creates a subconscious barrier to expanding your skills beyond your label while also giving you an excuse, and others the same low expectations.
Or describing someone's skills accurately they can figure out what they could be improving on.
Making the FPS higher, might require some creative hacks. Making a 3D model look exactly like your vision might require highly technical knowledge about your tools.
Going beyond acceptable standards, imo, requires both technical and creative skills. And I believe the split is closer than we think.
On the second note, I understand the point, however, it's subjective how it makes the person feel. I have seen many instances of "creative" people shy away from technical things because its "not who they are" and vice-versa.
Of course everyone in a knowledge economy needs to use technical skills and also be creative. That is not what those job categories mean.
That is not the case with note-taking, managing or planning, etc. These non-technical skills are usually something you can "pick up" and also there is a huge factor of context where these skills depend on how the organization does things and how people work together. This is why they're also referred to as soft skills. There is a lot of variability in how they can be practiced and learned which depends on many factors that change from team to team and org to org. .
I understand the article is trying to make a point of appreciating these other skills, however at least in the software industry today, I think technical skills have been undervalued and engineers are expected to spend a lot of time and effort on "soft skill" tasks, which I think is a waste of expertise.
To _really_ be successful, most folks need to develop a combination of "hard" and "soft" skills. The "soft" skills are neither easier nor less important. And strong "soft" skills make it SO much easier to leverage those "hard" skills.
I think the distinction here is the difference between learning how to use Jira or your calendar app, versus learning C++. One will take you years to achieve to a degree of professional competency while the other is a matter of just doing it a few times and getting into the habit of it.
I agree you need both soft and hard skills though, to me it's just a matter of how much time your spending your 8 hours on, and it seems so many software companies are happy having their engineers spending less than 20% of their time on technical matters.
Working on large projects is a team sport. Expect to spend as much time (or more) working with others as just writing code.
I mean, it's ok to not worry about soft skills and focus your time and effort entirely on coding, but ultimately that limits the scope of what you can do.
Is there a particular niche in the industry that you've seen this? I've almost universally seen the opposite.
The closest thing I can think of is that someone who truly only has technical skills will usually be limited to IC levels, whereas someone who also has soft skills becomes a better candidate for senior and staff positions. The thing is, that's because soft skills are an actual requirement for those roles. The purpose to them is to herd cats, and someone who communicates poorly or doesn't seek out opportunities to do so won't get them.
With that said, I don't think I've been in any tech focused company where technical skills aren't valued, and continued growth unappreciated. It's more a case that they're considered table stakes, and having strong soft skills is where you stand out.
Engineers get a tiny slice of the app and the majority of the time is spent on tasks that could be done by anybody else who didn't spend 10+ years studying and practicing computer science. Promotions are about managing a bunch of engineers that each get a tiny slice of the engineering. I would love to see promotions based on learning more technical skills and for this "track" to go all the way up the chain of responsibilities until you are responsible for coding hundreds of thousands of lines of code at a time. Ironically if I tried to build a company like that I would end up doing exactly what I am complaining about.
That said, imo the "technical skills are required less the more responsibility you get" mindset is the root of much dysfunction in tech companies... it's how we ended up suffering the car assembly line cargo cult in an industry where ~10 engineers can make Whatsapp ($$$$) when not laden with ceremony and theater.
I think this is a fundamental misunderstanding of what the higher level roles are (or ought to be).
Experienced engineers spend less time on code because the code doesn't live in a vacuum. Changes require planning. Requests for features usually come from people who either don't understand what they're asking for, or don't realize there's a different and better way to achieve the same outcome with less effort. Junior developers need mentorship and review to grow.
If those things don't appeal, that's fine. They still need doing, and the people doing them need a good amount of technical skill- usually the more the better, though the phrase architecture astronaut comes to mind.
There are some organizations that revolve around pure technical competency, but none of the ones I can think of are businesses- mostly, it's open source projects run by their BDFL founders like Linux, that sort of thing.
Software is inherently about automation and abstraction, and the possibilities are limitless as we are witnessing with recent AI breakthroughs. If more engineers had the opportunity to optimize their expertise throughout their career they could produce advanced solutions adding orders of magnitude more value.
It has to do with the nature of software and how you can build an intricate system with whatever properties you want, but instead companies like to use popular frameworks and slice their product into tiny fragments that they can divide among their army of low level engineers, so of course they need a proportional amount of managers as well.
I'm 20 years removed from any deep technical work at this point but I'm quite thankful that my CS degree's philosophy was that by the end of the program, you should be able to sketch out conceptually what's happening on a computer from electrons on a wire to how users react to your UI (basically, Nand2Tetris before Nand2Tetris). I've forgotten the fine details but that conceptual stack still exists in my head and it's an asset I'll always have.
There absolutely are many amazing managers of tech teams that are deeply non-technical and rely on their mastery of the abstraction layers they can grok to drive effective team performance. But there's also many times where the details do matter and the ability to dive deep into the guts of minutiae is an enormously valuable tool in your toolbelt. Management is a diverse set of skills and every manager rolls a different set of attributes on your character sheet and nobody is a 10 across the board. The art of management is to figure out what differentiated management style works with your character stats and build a team/environments to buff your strengths and make up for your weaknesses.
But the kind of technical knowledge you get from a solid CS education is too time inefficient to learn on the job and so there's real value to in absorbing it as much as you can in an collegiate setting.
Hiring even developers with lots of experience but low conceptual skills has mostly been a disaster for me in the past. The same goes for "technical something" roles. Programming experience can be a bit of a red herring for those actually.
For the most part, my "technical" interviews go into conceptual skills and motivations. That's the stuff I really need to know to decide whether to hire someone. Some language/tool/framework, they can learn quickly, given conceptual skills, motivation and _some_ programming experience. (Disclaimer: I primarily hire generalists as FTEs. For specialist skills, I prefer to hire freelancers temporarily, where I focus on what exactly they can do today.)
eg: I would be confident stepping in as a technical manager in a software team but if I were to work in eg, aerospace, I'd still have strong conceptual skills but I'd be distinctly non-technical. There's a pretty shallow set of abstraction layers beyond which, I just don't have the education. If I were to go back to school for aerospace engineering, I'm sure my strong conceptual foundation would mean I could master the material 4x faster than anyone else but it would still be a lot of grinding work doing the math and using the software and building prototypes and testing so I could learn. And like, at this stage in my life, the ROI simply cannot pencil out, which is why it's so important to build the foundation when you're young.
I'd say almost every strong non-technical manager is strong on the basis of their strong conceptual skills but that still makes them a non-technical manager and there is a distinct difference.
the definition "technical people" are using when they make that distinction is close enough to 1a of Webster: "having special and usually practical knowledge especially of a mechanical or scientific subject"
now, it's fine to be non-technical. but don't try redefine "people-people" as "technical, but in a different way". part of being a good manager of technical people is to understand the distinction and the different way they think. i've had great managers and leaders that were technical people that became managers. and the very best managers i've had were non-technical people that were extremely skilled leaders. they grew to understand, trust, and manage technical people. they knew the difference and thrived by providing complementary viewpoints and skills.
but i've seen a whole lot of amateur politicians that didn't really understand people as well as their supposed expertise was touted to. they don't have strong technical skills or even the right mindset, so the recast themselves as being good at other things instead (if not good at engineering, they must be good at management, right?).
they chafe at people calling it "soft-skills" or "non-technical". they use analogies like basketball a lot (and sewing, and rock climbing). to try to equivalate a technical engineering mindset to the way the author thinks is a tell that they don't understand the difference at all. the attempts to change the reality by changing language. mis-ascribing phrasing as some kind a value judgement or slight.
all of this tells me this person is not as skilled in technical fields OR with people as they think they are.
Though in the first example given in the post, relating to technique, it's even ambiguous in German. The joys of natural language I suppose.
Of course this also happens the other way around from time to time, but much less often. I wonder if it's because I'm biased as a German native speaker or because there really is a difference in the languages.
English borrows from everyone. German borrows from itself (to create elephant words). Many of the phrases in German are single words that amount to sentences.
English has some of the same, but it doesn't feed on/into itself
For what it's worth, I do think our society has a comparatively high appreciation for these apprenticeship type jobs. There can be pretty good money in it, often more agency, and a lot of them are obviously needed - far more obviously than most jobs folks study for. Maybe I live in a bubble, but I feel that's appreciated here.
All of that technical (!) stuff aside, the word "fachlich" is, from my perspective, mainly used to describe white collar knowledge or skills. I don't think I've heard it in the context of baking, plumbing etc, and I'd say it has a positive connotation, hinting at education and experience. But I'm neither a linguist nor a statistically relevant sample of Germany, so YMMV.
Both can learn technical skills, the person from the Gymnasium can become an engineer and the person from the Realschule can become a tradesman.
Besides that I think a recent change in German culture, correlating with a moderate decline in the importance of German engineering firms, has been to look down on all kinds of technical work. General social work, preferably working directly for the government, is now the in vogue field.
> they're simply the skills used to produce the work.
it's contextual, words can mean different things in different context.
in my work technical skills just means that you are a manager who progressed through engineering. you understand our problems and speak in the same terms.
non-technical is just someone from a different contextual background. although in their own context of dealing with humans ("soft skills") is also a "technical" skill in that it require specific skills which we engineers may not have.
If what we currently call technical skills is unfairly overvalued - the evaluation needs to change, not the name.
Similarly you don't fix racism by replacing one word with another. That's just magic thinking.
BTW I think technical skills in IT are overvalued, mostly because of outdated perception of rarity. And over time the hordes of people pivoting to IT and the improving generative AI will change that.
Arguably, everything involving people is communication overhead, the larger the organisational structure, the more communication overhead.
Anything non-people related are "things". This includes anything from planning, math, engineering, logistics, marketing.
Orthogonally, there are project managers (PMs) and architects (they need an acronym) who either A. recently had or B. distantly had serious technical chops, and those who C. were the latter of the first sentence.
C'est la vie; the anti-pattern of the corporate machine operating with the efficiency of the Peter principle.
Perhaps the only and irreducible way to discern A. above is to work with someone else on something meaningful for longer than the pop quiz bullshit of 20-30 minute technical interviews.
Possibly, project managers can be effective without technical knowledge if they both check their egos and communicate efficiently and effectively to reduce and consolidate external comms.
Architects also need to defer to people digging away at the problem rather than mandating a vision or some equally ineffective pretend work. Architects and PMs can be extremely effective if they know their limitations, are honest, understand human nature and the natures of their team, and how to manage external expectations.
Programming might be a soft skill under this definition, except it isn't: because programming tends to be judged on results, which are easier to see and harder to argue with.
The definition of "technical" in this article is overly broad. Although I agree that sewing is a technical skill. I'd suggest this definition "A technical skill is the ability to create technology of some kind." A knitted cap is technology, therefore knitting is a technical skill.
When we are speaking of projects in IT, "non-technical" specifically means skills other than those of fashioning hardware and software.
No. And I'm judging them on that.
> A knitted cap is technology, therefore knitting is a technical skill.
To offer a converse example, consider the creation and delivery of devastating rage-inducing insults. It isn't kind nor necessarily desirable on your team... but it's still a "soft skill" because it is hard to evaluate or formalize.
Did they put meetings without agenda? They are not good at communication.
Did they took decisions that impact multiple teams but never inform the teams that were not present? They are not good at communication.
Do they interrupt people when they hear things they don't like? They are not good at communication.
Do they hide important (bad) information because they are ashamed of what they did? They are not good at communication.
Our problem is not really how to identify horrible communicators, but more how to tell the difference between someone who is barely acceptable and someone who is excellent. This is highly contextual. What makes you a good communicator in a biker gang is different from what makes you good at communicating your requirements to people who work for you. Communicating with my wife means I stay quiet a lot. Communicating with my best friends means interrupting them a lot (or else I will never get to say anything at all). They're all men... they get it.
In the early days, my employers sent me to a lot of classes on communication. I didn't hear a lot of clear-cut rules, and the ones I did hear had many exceptions.
For instance, you don't need agendas for most of the meetings you have.
I meet with colleagues, students, or clients literally every day. I never publish agendas in advance. But we all either know the purpose of the meeting or negotiate the agenda as the first item on the agenda. This works just fine.
In a more tense or formal meeting environment, I would circulate an agenda in advance. For some of my classes, I publish an agenda.
My list us what I see as bare minimum. Why you think it was a full procedure on how to eavaluate people I have no idea.
No agenda, means no agenda. It doesn't mean we don't have the agenda in the calendar but we have it somewhere else.
There are a bunch of people who work in tech who have technical skills who don’t know anything about code. That’s a bright line skill boundary and it is an important practical distinction.
I don't think they have a place in SaaS/IT/Tech or any other thing like engineering or finance - but they are there.
"Tech" has also become an allegory of topics that we can discuss where there is a clearer right and wrong. It's still subjective and opinionated of course but at the moment when your mind is really soaked into tech, everything feels so simple and ultimatively true. It's probably part of the God-complex/imposter-syndrome that so many coders experience, but that's another topic...
Yes, there are technical skills in pretty much all fields. But if we recognize this fact it still does not address the starting point of the article. Is it better to have a manager with deep technical skills in the field of the people they manage?
Should a basketball coach be a good basketball player? Should the project manager of a software team be a good programmer?
Yes, there are seperate technical skills in the area of project management and sports coaching. But does the manager also need the technical skills of the people they manage?
No doubt that conversations and sewing require specific skills and techniques. Certainly they are "technical" on some level, it just isn't what is meant.
"Technical" in the context it is used means what level of specifics you can communicate on. Which is why it can be total nightmare to have to work with "non-technical" people, as there often is a relatively easy low level explanation, but that is useless to the other person, so communication starts to break down.
[1] https://www.cambridge.org/core/journals/european-review/arti...
I'm not downplaying soft skills, by the way. Soft skills are what get you successful in life. And the disdain some people have for soft skills vs hard skills is uncalled for, but that's a separate issue. Technical skills clearly mean something technical.
We have limited time in life - I do like to spend time fooling around with computers, other people like to spend time fooling around with other people.
I am never going to be as good in small talk as someone hanging out with people all the time. The same the other way someone dealing with technical issues all the time will just be so much better at fixing them.
I am also not that much interested in other people, well I have my close friends and family, but if I am in group with strangers I cannot crack a joke - even though I know the structure of a good joke and I can make my friends or coworkers laugh (it is much easier to get correct timing to drop a joke with people you meet on daily basis). Then there are those people who just own the room after 5 minutes mostly because they practiced it.
Yes taking it down to some steps looks like there is no difference - but there is difference on what I am spending my time on.
There is also this gap where you can learn and train javelin throwing for all your life but still you might not even get close to starting in the Olympics - even if you have all the steps of "how to throw a javelin" worked out. So I don't agree you can break something into steps and say "well that's the same thing just do XYZ and it works".
If you like computers, the skill floor for comp sci is lower for you. And if you like talking and cracking jokes, the skill floor for stand-up comedy is lower for you. These are subjective.
So the difference in the skill level required between them in reality might not be vastly different. (Only with regards to the skill floor)
I've worked with people like the following:
A) Excellent systems and architecture/big picture knowledge, but hadn't done actual coding in ages, and likely wouldn't be much help if placed in a team to produce code.
B) Terrific coder, but not too interested in the process. Ad-hoc type that would much rather spend time on iterations, than planning. "Get shit done" type.
C) Very good people person, but with fading technical knowledge.
D) Extremely enthusiastic person that came from the business side, but with limited technical knowledge. Would happily spend time on reading and learning about new technical stuff, but didn't necessarily have the foundational knowledge to lead a project alone.
And many more.
If asked "Is [x] technical?" I'd have answer "Yes, but..." or "No, but..."
For one, they are proficient with what are essentially high level programming environments and platforms like Excel, Filemaker, some CRM and CMS software etc. They also automate tasks. They just typically don’t know how to turn a simple text file into a program, like we do, but they do program.
Secondly and perhaps more importantly, they can do technical work for extended amounts of time. They know how to stare at a screen for hours, use the mouse and keyboard very effectively and quickly, spot mistakes and irregularities at a glance, and solve mistakes/issues in a structured manner.
That mechanical aspect of being technical is often overlooked. But I think it’s important and fundamental. Someone who never developed these skills lacks the intuition and sensibilities that are required to make sensible technical decisions.
But then I realized it doesn't make a lick of a difference. Those who find the distinction meaningful will have already internalized the point of the author's article.
Those who feel superior when they themselves are 'technical', while someone else isn't, think that the ability to understand the technical details of their work is proof that they are smarter, more passionate, and more interesting than the other person.
That person will not be enlightened by your word choice.
In other words, a monad is not a burrito [1].
I think that's the reason why I love to watch Real Engineering/Practical Engineering channels on YouTube. I watch what seems like a "simple" task, such as pouring concrete, and then suddenly realize that it's actually not that easy. Or "How It's Made" - Chips? Easy, right? Well, no, lol!
Ehh, maybe if you're lucky. But I wouldn't count on it. Frankly I'd just be happy with not getting a stick in the eye
> Likewise, we can ONLY write off marketing, sales, management, design, product, HR, etc etc etc etc as less important because "they're not technical" if we choose to ignore that they are very technical.
Design requires a lot of hard skills... how many people here could open up photoshop or indesign and not get overwhelmed by the magnitude of features? Seems like a really lazy example
The real distinction is between people who actually work on real products and all the auxiliary people who exist to facilitate business process. Like the difference between a professor and a uni administrator. The former rightfully deserves more props than the latter
We have a progression: unconscious incompetent -> conscious incompetent -> conscious competent -> unconscious competent. And it is completely context and domain specific.
This is a fascinating observation. Can you elaborate on the difference between the last two stages? Doesn't mastery involve knowing what you are good at?
There are many parts of software engineering in several domains that are just second nature to me at this point, I don't think deeply about how to write or structure the code, it's simply an intuitive action and it's usually somewhat solid code when I finish producing it. I just write good code without having to think about how to write good code.
I've also become competent in several other domains as I've continued in the field and I can write good code in those domains, low level systems engineering as an example, however, I have to think through systematically how to structure the code and how to avoid memory issues etc etc. I'm competent, but it takes a bit longer and I'm actively considering structure etc, checking papers, reading docs more deeply.
I can say I'm competent and even good in those differing areas, but the amount of effort needed to achieve the perception of being good is a lot different between them. Some areas are basically effortless and some are effortful.
That's the distinction between unconscious competent and conscious competent as I would define it.
> We often dismiss skills that are not societally valued by pretending they are not skills.
The truth is that "non-technical skills" are valued far more than technical skills. The people who run our world didn't get there from "technical" skills.
Non-technical skills are less legible so it's harder to deliberately practice them and there are many people running around in non-technical roles who are simply not good at the role. Tons of salespeople can't sell. Lots of product managers have no product vision. etc.
People who are actually good at non-technical jobs don't need to be lionized. They already have the money and power.
I don't understand the obsession with calling all skills "technical" though. Why do you feel that need?
Are you playing the game? Do you have to play the game?
I call bullshit on this. Sewing is making. Simple as that. The "maker movement" is not distinct from sewing but encompasses it. At our hack space we have people doing woodworking, people doing machining, people doing 3d printing, and people doing various fiber-arts (sewing, knitting, crocheting, embroidery). Very often they are the same people, because it is all just making.
I can understand that the Silicon Valley culture can be frustrating if you’re “not technical”. But just remember that the opposite culture (i.e. the old Swedish one) is a road to serfdom for everyone involved. If you don’t believe me, just compare e.g. Ericsson’s and Google’s market capitalizations over time.
In the first screenshot, "were the Project Managers technical", the asker means "does the PMs understand technical details"
Then the author argues that marketing, sales, management, design, product, HR people were also "technical" if you pay enough attention.
This article is arguably a very nice write-up, but it misses the main point.
In an emerging field, "technical" means decision makers can adapt very quickly with the know-hows and gets an advantage, but for mature business with tons of off-the-shelf technical solutions, soft-skills means a lot.
It all depends what kind of business you are in. They are not contradictive.