Technical skill and human skill are usually presented as rivals competing for the same hours of a career. They are not. They answer different questions, fail in different ways, and each becomes more valuable when the other is present. This guide sets out what the two labels name and how to decide which one needs work next.
Quick Overview
What you’ll learn:
- Why the contest between the two is a badly posed question, and what survives once you drop it
- What each label actually names, and why one of them is measured far better than the other
- Where deep technical knowledge still decides the outcome regardless of anything else
- The point at which European law stopped treating competence as a matter of preference
- How to build both halves at once without splitting the week into two training tracks
- Which way to lean at each stage of a career, and what signal tells you to switch
Who this article is for:
- Engineers and analysts deciding where the next block of learning time goes
- Team leads accountable for whether their people can explain what they built
- Learning and development staff designing programmes that are supposed to cover both
Reading time: 24 minutes
Why the Dichotomy Survived Longer Than It Deserved
The framing is old and it persists for a structural reason rather than an intellectual one: the two kinds of capability are taught by different institutions, assessed by different instruments, and bought on different budget lines. An organisation that sends an engineer on a database course and a manager on a negotiation workshop has not made a judgement about which capability matters more. It has followed the shape of the market it buys from.
That shape then feeds back into how people describe themselves. A specialist whose training record is entirely technical concludes that technical work is what they are for, and treats the rest as personality — fixed, unteachable, somebody else’s department. The conclusion is wrong, but it follows honestly from the evidence available to them.
The second reason the framing survives is that one side of it is easy to certify and the other is not. A vendor examination produces a pass or a fail on a stated date. Whether somebody can hold a design review together when two senior engineers disagree produces no certificate at all. Faced with two capabilities and one measurable, organisations optimise the measurable one — not because they decided it mattered more, but because it was the one that showed up in reporting.
Dropping the contest does not mean declaring them equal in all situations. It means noticing that the question “which is more important” has no answer that is not conditional on a role, a stage and a task. The useful question is narrower and answerable: given what you are trying to do next, which side of the profile is the binding constraint?
What the Two Labels Actually Name
“Technical” names knowledge of a system: how it behaves, what it guarantees, where it breaks, and what the documented ways of working with it are. It is domain-bound. It goes stale when the domain moves, which is why a technical profile has a maintenance cost that never reaches zero.
“Soft” names something closer to a set of operating habits applied to other people and to ambiguity: explaining, listening, deciding under incomplete information, absorbing disagreement without escalating it. The label is bad — nothing about doing this well is soft — but the underlying category is real and it behaves differently from the first. It decays slowly and transfers across domains almost intact.
The European Commission’s own classification separates these along a similar line. The European Skills, Competences, Qualifications and Occupations (ESCO) classification distinguishes knowledge from skills and then marks a subset as transversal — capabilities that belong to no single occupation and are expected to appear across many. That structure is worth borrowing, because it replaces a value judgement with a scope statement: some capabilities are bound to a domain and some are not.
| Domain-bound capability | Transversal capability | |
|---|---|---|
| What it is | Knowledge of a specific system, tool or body of theory | Habits of communication, judgement and collaboration |
| Typical evidence | Certification, portfolio, code, passing an examination | Behaviour observed over time by people who worked with you |
| How it decays | Quickly, when the underlying technology moves | Slowly; the principles outlive the tools |
| How it is acquired | Structured instruction, documentation, deliberate practice | Practice with feedback, exposure to consequences, mentoring |
| Failure mode when absent | Wrong solution, built correctly | Right solution, never adopted |
The last row is the one worth sitting with. The two capabilities do not fail in the same direction. A technical gap produces something that does not work. A transversal gap produces something that works and is ignored, which is more expensive because the cost arrives later and is harder to attribute.
Where Technical Depth Still Decides the Outcome
There is a version of the balance argument that quietly concludes technical depth has been commoditised. It has not. Depth is what makes a judgement trustworthy, and no amount of communication skill substitutes for being right.
Several areas illustrate this without needing forecasts to support them. Machine learning systems fail in ways that are invisible to anyone who does not understand how the model was trained and what its inputs mean. Data engineering decisions about schema, lineage and retention constrain everything downstream for years. Security work turns on knowing exactly what a protocol guarantees and what it merely implies. Distributed systems punish intuition; the behaviour under partition is a property of the design, not of the team’s optimism. Regulated engineering — anything type-approved, certified or audited — requires knowing the actual text of the requirement rather than a summary of it.
What these have in common is that the expensive errors are silent. They do not announce themselves in a demonstration. They surface later, in production, under load, or in an audit, and the person who could have prevented them is the one who understood the mechanism. That is a technical property and it is not delegable to good judgement about people.
Anyone deciding where to invest a scarce block of learning time should note that depth compounds within a domain and transfers poorly outside it. A useful way to keep the investment honest is to look at what the current market actually asks of the role rather than at what feels interesting — our overview of IT skills worth acquiring is a reasonable starting point for that comparison.
What Automation Did to the Price of Judgement
The common claim is that automation raises the value of human skills. The claim is right, but the usual explanation for it is wrong. It is not that machines cannot be creative or empathetic. It is that automation changes which parts of a task remain scarce.
When a system can produce a plausible first draft of code, a report, a test plan or a summary, the scarce work moves. It moves to specifying what was wanted precisely enough for the output to be assessable, to deciding whether the output is acceptable, and to owning the consequences if it is not. Every one of those is a judgement made under incomplete information and communicated to somebody else. That is exactly the territory the transversal capabilities cover.
This has a sharper consequence than the usual framing admits: the harder the automation, the higher the technical bar for supervising it. Assessing whether a generated implementation is correct requires knowing the domain better than writing it from scratch would have, because you no longer see the reasoning that produced it. Automation therefore raises the value of both halves at once, and raises it most for people who have both.
The failure mode to watch for is the reviewer who cannot tell confident output from correct output. It is a competence problem wearing the costume of a tooling problem, and no procurement decision fixes it.
The Human Skills That Complete a Technical Profile
Not all transversal capabilities matter equally to a technical specialist. The ones that matter most are those that close the gaps a technical education predictably leaves open.
Technical explanation is the ability to state what a system does, what it costs and what it risks, in terms a decision-maker can act on. It is not simplification. It is selection: choosing which of a hundred true statements the listener needs.
Written argument carries more weight in distributed and asynchronous work than any spoken skill. A design document that survives being read without its author present is worth more than a presentation that requires them.
Structured disagreement is the ability to be opposed without the discussion becoming about the people in it. Teams that lack it converge on whatever the most senior person said first, which is an expensive way to make decisions.
Reading a stakeholder means noticing what somebody actually needs as distinct from what they asked for. It is the practical content of design thinking, and it is why user-facing work goes wrong when it is treated as a requirements transcription exercise.
Working across a boundary — with a supplier, another department, a regulator — requires holding an interface stable while the two sides disagree about everything behind it. This is a project skill and an engineering skill at the same time.
These are learnable, and they are learnable by the same method as anything else: instruction, practice, feedback, repetition. The idea that they are personality traits is the single most costly misconception in this whole area, because it converts a training problem into a hiring problem. A more detailed treatment of how these capabilities behave inside engineering teams is set out in our article on social competencies in the IT environment.
The Point Where Competence Stopped Being Optional
The most significant recent change in this area is not a shift in employer preference. It is that European law began writing competence requirements into binding instruments, which moves the whole subject out of the development conversation and into the compliance one.
The Artificial Intelligence Act requires providers and deployers of AI systems to take measures ensuring a sufficient level of AI literacy among their staff and other people operating those systems on their behalf, taking account of technical knowledge, experience, education and training as well as the context of use. That obligation is not addressed to a training department as a suggestion; it sits on the organisation, and it explicitly couples technical knowledge with the situation the system is used in. The Artificial Intelligence Act also applies that duty from an earlier date than most of its other provisions, which means it lands before the parts of the regime that people spent longer preparing for.
Directive (EU) 2022/2555 does something structurally similar for cybersecurity. It requires the management bodies of entities within its scope to follow training themselves, and to offer comparable training to their employees on a regular basis, so that they can identify risks and assess management practices. Directive (EU) 2022/2555 also makes those management bodies accountable for approving the risk-management measures — which turns “understanding the technical position well enough to challenge it” from a nice attribute of a board member into a statutory expectation.
Read together, these instruments do the same thing from different directions. They make an organisation responsible for whether its people actually understand the systems they are accountable for, and they refuse to let that responsibility be discharged by hiring one expert. What they describe is precisely a combined profile: enough technical grasp to evaluate, and enough judgement and communication to act on the evaluation.
For teams working out what this means in practice for AI systems specifically, we set out the preparation path in our guide to the AI Act and team competencies.
What a Competence Framework Actually Buys You
Once competence becomes an obligation, an organisation needs a way to say what it means by it. This is the work a competence framework does, and it is worth understanding what such a framework is for before adopting one, because the common failure is to buy the artefact and skip the reasoning.
A framework does three things. It names the units — the tasks a role performs, and the knowledge and skills each task consumes. It separates the units from the people, so that a gap belongs to a role rather than to an individual’s reputation. And it makes the gap addressable, because a named unit can be trained, assessed and recorded, while “needs to be better at working with the business” cannot.
NIST’s Workforce Framework for Cybersecurity is a usable model of the shape even for organisations outside security. It builds roles from tasks, then attaches to each task the knowledge and skills required to perform it — which forces the transversal capabilities into the same structure as the technical ones instead of leaving them as an appendix. A role that includes briefing an executive on residual risk carries that briefing as a task with its own required skills, and can therefore be trained and assessed like anything else.
The European Skills, Competences, Qualifications and Occupations (ESCO) classification does something complementary at labour-market scale rather than organisational scale. It provides shared vocabulary across languages and countries, which matters more than it sounds: two organisations describing the same capability in different words cannot compare their gaps, and a person moving between them cannot carry evidence of what they can do.
Where frameworks go wrong is predictable. They are adopted wholesale, producing a document too large to consult and a mapping exercise nobody finishes. They are used for performance management before they are used for development, which teaches people to game the vocabulary. Or they are treated as a fixed inventory when the work has moved, at which point the framework describes an organisation that no longer exists and quietly becomes an obstacle.
The version that works is smaller than the version that gets bought. Take the handful of roles where the gap actually hurts, describe their tasks concretely enough that independent readers would agree whether a task was performed well, and attach the knowledge and skills to those tasks. That produces a development plan with named units on both sides of the profile — which is the whole point, and is achievable without a multi-year programme.
Developing Both at Once, Without Splitting the Week
The default approach is to buy technical courses for technical people and communication courses for managers, then wonder why the two halves never meet. The approaches that work share a property: the technical content and the human content are exercised in the same activity, so the transfer happens automatically rather than being hoped for.
Real projects with real stakeholders are the strongest instrument available and the least used deliberately. An engineer who has to defend a design choice to somebody paying for it learns the design and the defence together.
Business simulations compress that experience into a controlled setting where the consequences are visible and the cost of getting it wrong is a debrief rather than a customer. They are particularly effective for the capabilities that only appear under pressure — negotiating scope when two groups want incompatible things, or holding a position when the room is against it. The Balance of Interests business simulation is built around exactly that dynamic, and it is worth noting that this is not soft-skills theatre: participants are making decisions with modelled consequences, which is why the behaviour it surfaces is the behaviour people actually have.
Mentoring transfers the part of expertise that never makes it into documentation — when to escalate, which risks are worth naming early, how a particular organisation actually decides things. It is slow and it does not scale, which is why organisations that rely on it exclusively lose the knowledge when a mentor leaves.
Review as a teaching instrument turns an existing obligation into development. A code review or design review conducted as an explanation rather than a verdict trains both parties, and costs nothing beyond the discipline of doing it properly.
What does not work is the standalone soft-skills day disconnected from the work. It produces recognition without capability: people can name the techniques afterwards and do not use them, because nothing in the following week required it.
Why the Second Half Is Harder for Technical Specialists
The difficulty is real and it has identifiable causes, none of which is a deficiency of character.
Technical education optimises for problems that have a determinate answer. That is appropriate — the problems it teaches do have one — but it builds an expectation that ambiguity signals an error somewhere. Interpersonal situations are irreducibly ambiguous, so the same instinct that serves an engineer well at a debugger works against them in a disagreement, where the goal is not to resolve the ambiguity but to act sensibly inside it.
Precision, similarly, is a virtue that transfers badly. Technical language exists to eliminate the reader’s freedom to interpret. Most communication with non-specialists requires the opposite: leaving out qualifications that are true but irrelevant to the decision being made. Specialists often experience that omission as dishonesty, which makes them add detail exactly when they should be removing it.
There is also a feedback asymmetry. Technical work provides fast, unambiguous correction — the test fails, the build breaks, the query returns nothing. Human capabilities provide slow, indirect, easily-misread feedback, and often none at all. A person can be poor at explanation for a decade and receive no signal that says so, because the cost lands on other people.
Finally, the practice conditions are worse. You can practise a language in private. You cannot practise handling a hostile question in private, and the public version carries a reputational cost that makes people avoid it. This is the specific gap that simulation and structured practice exist to close, and it is why the answer is a designed setting rather than encouragement.
What Employers Can Change Structurally
Individual effort runs into organisational ceilings quickly. The changes that actually move the distribution are structural rather than motivational.
The first is what gets rewarded. If promotion decisions are visibly driven by technical output alone, everything an organisation says about collaboration is noise, and people are correct to ignore it. If they are driven by opaque judgement instead, people conclude the criteria are political. The workable position is stated criteria covering both, applied consistently enough that the pattern is legible from outside.
The second is who is asked to explain things. Organisations concentrate explanation in a small number of people and then treat the rest as unable to do it. Rotating who presents to stakeholders, who writes the design document and who runs the retrospective distributes the practice, and the capability follows the practice.
The third is dual career tracks with real parity. If the only route to seniority runs through management, technical specialists are pushed into people-leadership roles they did not want and organisations lose depth to acquire mediocre managers. A genuine expert track — with comparable pay, comparable influence and comparable status — keeps depth where it belongs and makes the choice honest.
The fourth is treating regulatory training as capability rather than paperwork. Where obligations already require staff training, the cheapest possible interpretation produces an attendance record and no competence. The more useful interpretation uses the obligation as budget and mandate for training people would benefit from anyway; our guide to NIS2 training for IT teams works through what that looks like in scope terms.
What Formal Education Can and Cannot Supply
Universities and technical schools carry a share of the blame for the split, and it is worth being precise about which share, because the correction belongs partly to them and partly to employers.
What formal education supplies well is the domain-bound side: sustained exposure to theory, the discipline of being examined on it, and enough time to build the mental models that make later learning fast. It also supplies something rarely credited — the experience of being wrong about something you were confident in, repeatedly, until the habit of checking sticks.
What it supplies badly is practice under social consequence. A student can pass an entire technical degree without once defending a decision to somebody who disagrees and has authority. Group projects nominally cover this and mostly do not, because the incentives point at the deliverable rather than at the collaboration, and the group’s strongest member routinely absorbs the work to protect the grade.
Several corrections are visible where institutions have taken the problem seriously. Project-based instruction with an external client introduces a stakeholder whose interests are not the tutor’s, which is the missing ingredient. Assessment of the process rather than only the artefact — reviewing how the design decision was reached and communicated — changes what students optimise. Interdisciplinary teaching puts technical students in rooms with people whose vocabulary is different, which is exactly the condition they will work in. Deliberate reflection, structured rather than sentimental, converts experience into transferable habit; without it, experience accumulates without generalising.
The limit is honest and should be stated: none of this produces a graduate who is good at difficult conversations, because that capability requires years of consequence. What education can do is remove the belief that such conversations are somebody else’s job, and supply enough vocabulary that the first years of practice are productive rather than merely painful.
That leaves employers holding the second stage, and holding it whether they plan for it or not. An organisation that hires technically strong graduates and provides no structured exposure to explanation, disagreement and stakeholder work will have technically strong specialists who have not developed, and will conclude — wrongly — that they cannot.
What Hiring Gets Wrong About the Combination
Recruitment is where the dichotomy does the most damage, because the decisions are irreversible for a long time and the instruments are weak on precisely one side.
The technical assessment is usually adequate. Work samples, system design discussions and portfolio review give a reasonable read on domain-bound capability, and their weaknesses are known and correctable.
The other side is typically assessed by inference from the interview itself, which measures interview performance. Confidence, fluency and social ease read as collaboration skill. They are not the same thing; a candidate who is comfortable talking may still be unable to absorb disagreement or to write a document somebody else can act on. Meanwhile the reverse error is more common and more costly: a quiet candidate who explains a mechanism precisely and asks a sharp clarifying question has just demonstrated more of the real capability than a fluent one who talked past the question.
What improves the read is designing for evidence rather than impression. Ask for a written artefact and read it. Run a design discussion where the interviewer genuinely disagrees, and watch what the candidate does with the disagreement rather than whether they win it. Ask them to explain something technical to somebody in the room who does not share their specialism, and observe what they choose to leave out. Ask about a decision that went wrong and listen for whether the account contains other people as agents rather than obstacles.
The organisational counterpart is to stop treating the combination as rare and therefore expensive. It is uncommon in candidate pools mainly because it is uncommon in development paths — which means an employer who can build it internally has a cheaper route to it than an employer bidding for the finished article.
Sectors Where the Combination Is Not Negotiable
Some settings tolerate a purely technical profile. Others do not, and it is worth knowing which kind you are in before planning a decade of development.
Healthcare technology places engineers in direct contact with clinical practice, where a misunderstanding of the workflow produces a system that is technically sound and clinically unusable. The domain knowledge cannot be acquired without sustained conversation with clinicians, which makes the conversation part of the engineering.
Security is unusual in that most of its failures involve people. A specialist who can find the vulnerability but cannot persuade anyone to prioritise the fix has produced a report, not a security improvement. NIST’s Workforce Framework for Cybersecurity makes this structurally explicit: it describes the field as work roles built from tasks together with the knowledge and skills those tasks require, which puts communication and coordination inside the role definition rather than adjacent to it.
Consulting and vendor-side engineering require reading an organisation as accurately as a system. The technical recommendation that ignores who will have to operate it is a recommendation that will not survive contact with the client.
Public sector and regulated industries involve constraints that are legal rather than technical, and stakeholders who are entitled to explanations. The ability to translate between a requirement’s text and a system’s behaviour is the core skill, and it is neither purely technical nor purely transversal.
Technical education and training is the limiting case: the entire value delivered is the transfer of understanding, which requires both possession of the knowledge and the capability to move it.
Which Way to Lean, and When
Balance over a career does not mean equal attention every quarter. The allocation should follow the binding constraint, and the constraint moves.
Early in a technical career, lean technical. Credibility is the prerequisite for everything else; advice from somebody who cannot do the work is discounted regardless of how well it is delivered. The transversal work at this stage should be the cheap kind — writing clearly, asking better questions in review, taking the notes and circulating them.
When you start being accountable for other people’s output, switch. The constraint is no longer what you can build but what you can get built, and that is a coordination problem. This transition is where most of the visible failures happen, because the skills that earned the promotion are not the skills the new role consumes. The changing shape of these roles, and what they now demand, is set out in our look at new roles and required skills in DevOps.
When you change domain, lean technical again, hard. A specialist moving into a new field is temporarily a beginner in the first half and an expert in the second, and the transversal capabilities they bring make the technical re-learning faster rather than substituting for it.
When the environment is unstable, invest in the meta-skills. Learning how you learn, and how to hold a position under uncertainty, pays across both halves and is the only investment that does not depend on guessing which technology wins.
Approaching a leadership role, the constraint is almost always transversal — but the technical floor never disappears. A leader who has stopped understanding the work cannot tell an ambitious plan from an impossible one, and will approve both.
The signal that it is time to switch is worth naming plainly: when your problems stop being about what you know and start being about what other people do with what you know, the constraint has moved.
Measuring Something That Resists Measurement
The asymmetry in evidence is what keeps the false dichotomy alive, so it is worth addressing directly.
Technical capability is assessed with instruments that are cheap and reasonably honest: an examination, a work sample, a portfolio, a review of shipped work. None of them is perfect and all of them are better than nothing.
Transversal capability resists that treatment because it only exists in interaction. The instruments that work are correspondingly indirect. Multi-source review collects judgements from the people on the receiving end, which is where the capability is actually visible. Observed simulation puts somebody in a designed situation and watches what they do, which is the closest analogue to a work sample. Behavioural evidence from real work — did the design document survive review, did the disagreement resolve, did the stakeholder get what they needed — is the most valid and the least systematic. Self-assessment against a described standard is weak as measurement and useful as direction, provided the standard is concrete enough to argue with.
Two failure modes recur. The first is measuring satisfaction instead of capability: a course rated highly and changing nothing. The second is measuring the measurable and declaring the rest unmeasurable, which is how organisations end up with detailed certification dashboards and no idea whether their teams can explain anything.
The workable position is to accept lower precision on the transversal side rather than accepting no measurement at all. An imprecise signal that points the right way beats a precise signal about the wrong quantity.
What Each Half Does for the Other
The reason the contest is badly posed is that these capabilities are not independent variables. Each raises the return on the other.
Technical depth makes explanation possible. Vague explanations usually indicate vague understanding; the specialist who can state precisely what a system guarantees can also state precisely what it does not, and that second statement is where trust comes from. Depth also supplies the authority that makes a difficult message land — the same warning carries differently from somebody who has demonstrably done the work.
Analytical training improves decision-making under uncertainty, which is nominally a transversal capability. Separating what is known from what is assumed, and noticing when a conclusion rests on the assumption rather than the evidence, is a habit that technical education builds and that most organisational decisions badly need.
In the other direction, communication accelerates technical learning. Asking a precise question shortens the path to an answer; explaining a mechanism to somebody else is the fastest way to discover you did not understand it. Teams with strong internal explanation converge on shared understanding faster, which shows up as fewer integration surprises.
Reading users well produces better technical decisions rather than merely better-received ones. Knowing which failure the user actually fears changes what you optimise, and that is an architectural input.
The practical conclusion is that development effort spent on the neglected half tends to have a higher return than the same effort spent deepening the strong one, not because balance is virtuous but because the constraint is usually on the side nobody has been working on. The golden mean is not a compromise between two goods. It is the recognition that neither half pays out fully while the other is missing.
Making a Combined Profile Visible
A profile that exists and cannot be seen is worth what an invisible profile is worth. The instruments that make the combination legible are different from those that make technical depth legible, and most people use only the second set.
A portfolio of decisions outperforms a portfolio of artefacts. Showing what was built demonstrates the domain-bound side. Showing what the constraints were, which options were rejected and why, and what the trade-off cost demonstrates judgement — and judgement is the part employers have no other way to assess before hiring.
Written work is evidence in itself. A design document, a post-incident review or a public explanation of a mechanism proves the capability by being the capability. This is the rare case where the demonstration and the artefact are the same object, which is why writing is disproportionately valuable to people whose other skills are hard to display.
Accounts of work that went badly are more informative than success stories, and interviewers who know what they are doing ask for them. An account that names what the person misread, what they did about it and what changed afterwards demonstrates the capability directly. An account in which everything was somebody else’s fault also demonstrates something, less usefully.
Certification carries the technical half and only the technical half. It is worth having and worth reading correctly: it establishes a floor, not a ceiling, and it says nothing about whether the holder can work with anyone. Treating a certificate as evidence of the combination is the same error as treating fluency as evidence of collaboration.
The one thing worth avoiding is the vocabulary without the substance. Listing transversal capabilities as adjectives — communicative, adaptable, collaborative — is a claim nobody can check and everybody makes, so it carries no information. Replacing each adjective with a situation and an outcome converts noise into evidence.
What the Combination Returns to the Organisation
The individual case is easy to argue. The organisational case is what actually releases budget, so it is worth putting plainly and without invented figures.
The first return is fewer expensive misdirections. Work that is technically sound and aimed at the wrong problem is the most costly category of waste in technical organisations, because it consumes a full delivery cycle before anyone notices. The capability that prevents it is the one that surfaces the real requirement early, and it is transversal.
The second is faster recovery from being wrong. Teams that can disagree without escalating change course sooner, because the cost of raising a problem is lower. Where that cost is high, problems are raised late, by which point they are expensive.
The third is retention of depth. Specialists leave organisations that offer no route to influence other than management. Where a technical track carries real weight, the expensive knowledge stays, and the organisation stops paying the replacement cost of rebuilding it.
The fourth is credible accountability. Where regulation now requires an organisation to answer for its people’s competence, the answer has to be demonstrable. An organisation with a combined profile can produce that demonstration from its ordinary working records rather than assembling one for an audit.
None of these shows up on a single line of a budget, which is why the investment is chronically underfunded. All of them show up in delivery.
Build Your Skills
The gap between knowing that explanation matters and being able to explain under pressure closes with practice and feedback, not with agreement. The Business Communication Skills comprehensive course works through structuring a message for a specific audience, handling questions that are not asked in good faith, and writing documents that survive being read without you in the room. Check the programme and sign up.
Frequently Asked Questions (FAQ)
Is the T-shaped model still a useful way to think about this?
Yes, provided you read the horizontal stroke correctly. It is not a claim that breadth substitutes for depth; it is a claim that depth without adjacent understanding cannot be applied outside a narrow lane. The common misreading treats the horizontal as a list of technologies to be superficially familiar with. The more useful reading treats it as understanding the neighbouring disciplines well enough to work with the people in them, which is where the transversal capabilities live.
Does AI reduce the value of technical expertise?
It relocates it rather than reducing it. What becomes cheaper is producing a plausible first version. What becomes more valuable is specifying the requirement precisely, judging whether the output meets it, and being accountable when it does not — and judging an implementation you did not write requires knowing the domain better, not worse. The people most exposed are those whose contribution was volume of routine output; the people least exposed are those who can tell correct from confident.
Are soft skills teachable, or is it a matter of personality?
Teachable, and the evidence for that is the same as for anything else: people who practise them with feedback get better at them, reliably. Personality affects the starting point and the preferred style, not the ceiling. Treating them as fixed traits has a specific organisational cost — it converts a training decision into a hiring decision, which is slower, more expensive, and does nothing for the people already employed.
Where does the law actually require any of this?
In more places than most development plans reflect. The Artificial Intelligence Act obliges providers and deployers to ensure a sufficient level of AI literacy among staff operating those systems, taking account of their technical knowledge, training and the context of use. Directive (EU) 2022/2555 requires management bodies of entities in scope to undergo training and to offer comparable training to employees regularly, alongside their accountability for approving risk-management measures. Both make competence an organisational obligation rather than an individual preference.
How should an organisation forecast which skills it will need?
Not from vendor marketing, and not from a single consultancy report. The instruments built for the purpose are the ones to start from — Cedefop’s Skills Forecast projects occupational and qualification demand across the European labour market and is published with its methodology, which is what makes a projection arguable rather than merely quotable. Combine that with your own evidence: which roles you struggle to fill, which work sits in a queue waiting for one person, and which decisions get delayed because nobody can explain the options.