When a coder asks another coder whether a boss is technical, it just means “can they code?”. There’s not much more to it. You may not like this, but it’s how the word is used, and language is defined by usage. I don’t like that y’all use the word “crypto” for get rich quick schemes either, but I suck it up, the ship has sailed.
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?”
I would also add that what the question really really means is "Do they understand what we and I are doing here? Do they understand what they are asking of me? Can they emphasize with me?"
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.
It’s important for a technical manager to be able to effectively advocate for their programmers. Otherwise you just get constantly railroaded by the high priests of sysadmin or devops into technical decisions that make no sense.
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.
Yes, this is it. The goal of the question is "Do they understand what we and I are doing here? Do they understand what they are asking of me? Can they empathize with me?". And the meaning is simply if they have programming skills.
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)
It’s not even a tech thing, there has always been a distinction between a leader who climbed the ranks and someone who jumped directly into leadership (whether from education, nepotism, whatever).
It is important to know which kind you are working under.
At least that's the meaning in a generic software company context, yes.
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.
In this context I have seen more than once that it's more often a cargo cult thing
"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.
Non-programmmers are also often very proud, and also devalue things they can't do, so even if there's no technical issues that the boss needs to understand (e.g. if there's conflict or trade-offs) then this could be an issue.
To be honest, I don't really think it's actually that deep. Usually, the purpose of the distinction in this context is just useful to convey if someone is skilled in software engineering specifically. For example, when I hear "technical manager" in the context of programming, I think of "the type of manager that weighs in and leads 'technical' decisions directly".
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.
Seems like the author just doesn't understand what people mean when they talk about a manager being technical or not. I don't think anyone means "this person has no depth of knowledge about anything". We just mean "they don't know programming", more or less.
I meant it semi-sarcastically but you don't seem to disagree?
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".
>I'm happy to report that most places I worked at valued "soft skills" much more than "hard skills" during hiring.
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.
That is because the people with soft skills that are paid well need people to get things done, so they go and hire cheap people with hard skills. That is how it works at every single company, the people with soft skills are paid the best and rule over those with hard skills.
The problem is, so many "soft skills" are things you can claim to have—and maybe even think you have—but can't actually be meaningfully tested in an interview setting.
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.
Yeah, it's not that I don't believe the hidden fractal nature of human knowledge where all modern problems are deeper than they first appear--It just happens to be the established jargon among software companies for software stuff.
These kinds of articles which endlessly dissect semantics give me similar energy to the trite gymnastics many speakers do like assigning numbers of letters of a words and adding them to make a point. Or finding substrings in a word (leadership is a ship).
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.
My heart sinks every time a "non-technical" manager has opinions on technical matters and makes decisions based not on the case presented by the technical team but on made up stories told by other managers, architects, and consultants. I spent a decade fighting with those types to deliver good work and do the right thing, but they have worn me out so I switched to pure dev work. At this point I am undecided as to whether a non-technical manager is worse than a "slightly technical"() one.
() - has a iPhone and an X-Box which in his mind qualifies him to make decisions on backend architecture designs.
> but on made up stories told by other managers, architects, and consultants.
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.
A good manager is at the service of the team, not the boss of the team. The main reason is that the expertise is at the bottom layer, not the top. Any good manager realizes this and know (s)he will have to trust the team.
I am writing a book the premise of which is “software Literacy” - the ability to code is a major inflection point. You may, 100 years ago have been a brilliant solider / seamstress/ sailor / sushi chef but if you were illiterate you were at significant disadvantage - and I believe the same is true today for software.
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
> The “technical skill” everyone talks about is coding
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.
I would say so as well. I would take a manager who can't code, but is a car mechanic nut in his spare time over one who can code a bit, but has no private interest in anything vaguely techological 7 days a week.
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.
The ability to code is not generally important, and in no way is comparable to literacy.
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.
Agreed, actually I'd say the practical value of learning to code for the average person has been declining for some time. It is easier than it ever has been to get computers to do what you want. I think it will continue to get easier. The whole idea that programming is a life skill may have had some merit years ago, but I don't see it anymore.
Agreed that sewing is "technical". Imagine you're an artisan seamster and your clueless boss (zero sewing experience) says stuff like "go faster, it's just putting the needle in the hole isn't it?" or "can't you just tape this part together to meet the sprint deadline and do the sewing stuff later?".
Weaving is even more technical. The origin of computer science. I have a significant fondness for warp and weft and remembering which iteration you're on through the pattern
Similarly with knitting, to a slightly lesser degree. Arguably using even more spatial reasoning since you're working with an entirely soft medium.
I have always been a fan of fashion, but I just think those designer clothes are too expensive, one day I thought "huh I should probably make my own thing, it couldn't be that hard?", I was wrong, DEAD WRONG!, I had no clue how to sew, after digging a bit deeper of "pattern making", I realized that being a consumer is good enough :) I don't mind spending 200 USD on something that may take me years to make and design
I have zero experience in tailoring, but I have seen some patterns and they are not straight... You cannot just ask so can we get square piece of fabric and cut hole in it? And then later demand answers why you did not get fitted suit...
There are reason why things are done in specific way and in specific order. And understanding those are technical skills.
I agree with most of the article. There's a part of the world that makes a distinction between "technical" and "creative" which bothers me even more.
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.
As a guy with an MA in fine Arts who now leads a technical job I think this is an arbitrary decision.
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.
> There's a part of the world that makes a distinction between "technical" and "creative" which bothers me even more.
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.
> 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.
Of course everyone in a knowledge economy needs to use technical skills and also be creative. That is not what those job categories mean.
I think the main reason there is a distinction between technical and non-technical skills, is because usually technical skills require a lot of time and effort, and depending on the subject matter it could takes months, if not years, to be competent.
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.
> in the software industry today, I think technical skills have been undervalued
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.
I am mostly talking about what you just pointed out. The fact that soft skills are required to move up is evidence that technical skills are required less the more responsibility you get. There is a minimum bar requirement at entry level, and maybe one or two more levels before it gets taken for granted and rarely becomes an expectation for the higher positions that pay more. The more experienced engineers spend less time on code, and this is justified because they want people to be a "force multiplier" by becoming managers, essentially.
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.
> The more experienced engineers spend less time on code, and this is justified because they want people to be a "force multiplier" by becoming managers, essentially.
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.
I agree to a certain extent, mainly that it is a matter of appeal and it's about finding the right match, etc. That said, I can't help but think there is value being lost by thinking engineers need to scale their productivity by managing more people rather than by managing more software.
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.
Unless you're RMS level weird orgs use "soft skills" as cover in the same vein as "bad culture fit" for likeability, politik and empire building.
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.
Hmm...programming is also one of those skills you can "pick up." Lots of people do.
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.
By that measure almost anything could be picked up, but then it loses all meaning. I'm sure people can just pick up quantum physics if you just get the books and start reading.
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.
Yeah, learning JIRA or your calendar app is straightforward. Learning to work effectively with other people, whether as a member of a team or leading a team, can be remarkably nuanced and can take years of work and improvement to get really effective at it.
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.
I would say that being "ok" at managing or planning is easy but being very good at both those skills is extremely hard, so hard that you cannot achieve it with effort alone.
To me, "technical" in this context simply means how many layers of abstraction are you capable of piercing together with me?
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.
I tend to use "conceptional skills" to describe someone's ability to understand a complex system. When hiring - especially for roles like "technical product manager", I could care less about "coding experience". CS education is a plus for sure, 1-2 years coding too. But beyond that, I feel the conceptual skills are far more relevant. How much modelling can someone do in their head? How quickly? How honed is that ability in them? Sounds like your university trained your conceptual skills, that's awesome. Other people train them through other means, consciously or not.
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.)
To me, the two ideas are slightly orthogonal. Conceptual skills are cross-domain applicable and is a good measure of your ability to gain new technical skills whereas "technical" in the context I'm using it refers purely to your ability to pierce abstractions in the domain you're working in.
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.
True! I'd still argue when people want something like a "technical product manager", it often means "someone who can dive into the details of some complex system", at least from what I've seen. Hiring someone who did some programming a few years ago isn't necessarily going to give them that.
disagree with this. there is clearly a difference between "technical" and "non-technical" people.
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.
It's bothered me every now and then that the word "technical" is quite ambiguous. In German, we have a separate word for skills relating to any particular field, which is called "fachlich" ("field-y"). And then we have "technisch", which primarily means "relating to technology". Both translate to "technical". In the software world, I tend to express the former as "domain expertise", but it's not an exact match of what I mean usually.
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.
I find that English often lacks words to express the same thing I can say in German. There might be a word that's close but it's often subtly different or lacking in nuance.
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.
As someone who only learned enough German to insult, I'd say it's part of the identity 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
Well, those are slightly separate concepts I think. I went to a "Realschule", and those still exist. It's a school form that ends after grade 10, where the majority of students moves on into an apprenticeship, to work in either some kind of trade/craft, or low to mid-level white collar work. OTOH, "Gymnasium" is the common path towards A levels and then university. It is, however, also pretty common to go on to do your A levels and then study after Realschule like I did (at a computer science focused "technical high school" (!) for grades 11-13, yet another eccentric thing we have, but I'm a fan).
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.
The distinction between Realschule and Gymnasium is whether the student will learn a trade or go on to university.
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.
Changing the name changes nothing. The distinction will remain useful and people will invent a new word.
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.
"Technical" skills just means a person has or can switch to a "technical" mindset, which I find to be quite different from non-technical people. Not to say that one is better than the other, but I do find it much, much easier to communicate with other people who have "technical" skills than those who do not. Mainly because I also happen to think in similar way. In that regards, it's a very useful heuristic.
Another way to look at it, is that there are people and there are things. Humans will inevitably have to interact with each other, at least in order to mate to prevent the species from dying out.
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.
There's an unfortunate distinction between people who are very curious and possibly have formal training in a technical field, and those who do it because it makes lots of money.
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.
I like the term soft skills. I find it relevant and meaningful. To me, soft skills are skills for which we have no strong evaluation mechanism. Are you good at communication? It's hard to tell. A lot of judgement and context is involved. That makes it a soft skill.
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.
You think communication ability can be evaluated purely on a long explicit list of unbounded verifications based on your own personal preferences? Then you are not good at communication! (assume I put a softening emoticon here)
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.
“Programming tends to be judged on results” - I’ve seen plenty of very skilled programmers spend oodles of time on complex things that don’t matter to anyone except to them. Are those results?
Yeah, the "softness" refers to epistemology, rather than emotional content.
> 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.
“technical” is just shorthand for “has ever once used a text editor to read or write code professionally before”.
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.
Bit biased, but I'd say this is an non-technical article about overthinking terminologies. As others already mentioned, we use techie /non-techie to quickly categorize people into coders and non-coders, but techie also works for the embedded-guy or the kick ass devop or Linux neckbeard.
"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...
I agree. But one thing that I think the author should have talked about more (or eloborated on in case I missed it) is the natural followup to the articles conclusion.
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?
I used to work with someone who thought of themselves as a technical manager, because in his years after college he managed a couple of devs who mage Flash games. Then, by some skilled office politics and association with non-technical blow-hards he managed to become a manager on a complex greenfield project where he was managing a team of 30+ and had to work within an organisation of 150+ people who thought he was the person to answer technical questions. He mismanaged the team causing a lot of people to suffer mental issues and leave. Every time there was a technical question he'd pick the most idiotic solution you could think of. There was no way of fixing this problem, because the management above him were even more clueless. I have no respect for non-technical managers.
What people mean by "technical" is whether a person has a background and education in some field related to what they are doing now.
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.
Ok, we get it, you can do your job. But when I ask a fellow engineer if someone is technical I'm asking if they can do my job. So yeah, feel free to call me non-technical in conversations with other sewers.
Go back to C.P. Snow's "two cultures".[1] This is not new, but it's not that old, either. The concept appeared in the 20th century when tech started being important.
Don't have time to recap the history of technology right now.
Hard disagree with the premise. It's disingenuous to pretend there isn't a difference between knowing how to resolve an interpersonal conflict vs knowing the calculations needed to build a bridge. Yes, the skill ceilings may be high, but the skill floor is clearly different.
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.
There is a chasm of difference between the two skills - it is time.
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".
I agree with you. I think I wasn't clear in my comment.
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)
Like everything in life, these things fall on a distribution, and usually have more hidden variables than the visible ones.
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..."
Accountants, admins etc. are often very technical. Similar to developers who program every day.
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.
At first I wanted to suggest: 'will he or she understand the technical details of our work?' instead of 'is he or she technical?'
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.
Such a breeze! I love to remind myself that some things I take for granted require extraordinary skills that I just don't have the time or willingness to process and understand.
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!
> Do you know how to defuse an entrenched argument between coworkers, help a burned out coworker get out of a rut, or tell someone they're not doing a great job without making them furious? Managers do.
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
I have learnt over the years, that rather than calling a specific skill "soft" or "non-technical" to actually learn it and get good at it. Along the way I have learnt a great deal about the unknown unknowns.
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?
Not OP but let me try to define by example. I've been programming for 19 years give or take, starting as a kid I'm now 29.
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.
This article starts with a false premise that non-technical skills are undervalued then works backwards to try to defend them.
> 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'm not sales person myself, but I think it's pretty obvious to spot the difference between a sales person who is actually achieving sales, and one who is not. Perhaps much more legible than arguing whether a Dev team is creating or destroying value by deciding whether to refactor the mess or keep piling up technical debt. Listen to any sales podcast for five minutes, you'll see it's full of people deliberately practising specific skills, and lots of things we would probably characterise as "technical" activities once we have the language to identify and classify such techniques.
Are you responsive to selection pressure? Are you accountable for anything? Is your employment coupled in any way to the success of the organization? How, exactly?
Are you playing the game? Do you have to play the game?
> And consider the "maker movement," which, in my most frustrated moments, I call "arts and crafts, but for boys." The "movement" has been careful to highlight its technical skills to position itself apart from similarly technical fields, like sewing.
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.
This is a bit hard to digest for me who have lived most of my life in a culture where technical skills are not valued but soft skills are (Sweden). It has turned around to some extent over the last 15 years, but I still fondly remember how I “destroyed” my manager back at Ericsson by interrupting a long rant about how little she understood about engineering and pointing out that her title was in fact “technical manager”. If a look could kill I wouldn’t be here today.
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.
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?”