An IT competency profile is a description of what an engineer can be trusted to decide alone. What has changed recently is not the list of technologies on that profile but the set of things an engineer is now expected to be accountable for, including work produced by something other than themselves.
Quick Overview
This article is deliberately narrow. It is about competence inside information technology roles — engineering, operations, security, data, platform — and about the horizon that opens once the current wave of adoption stops being novel. The market-wide version of the question, which is about employers of every kind and about work outside technology entirely, is a different subject with a different answer and is treated separately in Competencies Employers Will Require in 2030: From Tools to Judgment.
Within IT, the changes worth planning around are fewer than the trend literature suggests. The signal is that generated output has entered the toolchain and someone has to own it, that security has stopped being a separate function’s problem, and that cost and energy have become properties an engineer designs for rather than discovers afterwards. Those are the technology shifts. Alongside them runs an organisational one, about how teams are staffed and how a career is planned, which is arguably harder to respond to than any of the technical ones.
What follows takes each in turn, and then says plainly which parts of the job have not changed at all — because a competency article that implies everything is new is misleading in a way that costs people money.
What Changed in Demand, and What Did Not
Demand for IT specialists did not fall; its shape changed. The clearest movement is away from the undifferentiated engineer — someone who can build roughly anything, in roughly any stack, at a competent level — and toward two distinguishable profiles that are both harder to hire.
The first is deep specialisation in something with real difficulty in it: distributed systems behaviour, applied machine learning, security engineering, data platform design. These roles are hard to fill because the capability takes years and cannot be certified into existence.
The second is a profile that is often described badly. It is an engineer who understands the business context well enough to shape the technical decision rather than merely execute it — who can tell which non-functional requirement is load-bearing for this organisation, and which constraint everyone repeats without anyone having tested it. This is not a management track. It is an engineering profile with commercial literacy attached, and the reason it is scarce is that most career structures never require anyone to develop it.
The gap between those profiles and the available supply is not a temporary recruitment problem, and treating it as one leads organisations to bid against each other for a population that is not growing fast enough to matter. The mechanism is structural: education systems produce entrants at the rate education systems work, and the capabilities in shortest supply are precisely the ones that require years of consequential practice rather than instruction. Wage pressure follows, and so does a familiar failure pattern in which an organisation pays a premium for a specialist, gives them work that any competent engineer could do, and then loses them because nothing in the role used what they were hired for. The organisations that escape this are the ones that stopped treating capability as something purchased and started treating it as something produced, which changes who owns the problem — it moves from recruitment to engineering leadership.
What did not change is the underlying evaluation. Employers still hire for the ability to make something work, keep working, and remain understandable to the next person. Every shift below sits on top of that, and none of them substitutes for it.
Generated Output Entered the Toolchain, and Verification Became the Skill
The first shift is the one most often described in terms of the wrong competence. Assistance from generative systems is now ordinary in editors, pipelines, review tools and operational runbooks. The competence this creates is routinely written down as the ability to phrase a request well. That is a small part of it and the least durable part.
The durable part is the ability to be accountable for output you did not write. An engineer accepting a generated block of code is making a claim: that they have read it, that they understand what it does under conditions the sample case did not exercise, and that they will be able to debug it at an unpleasant hour. Making that claim honestly requires the same depth as writing the code would have required. It just requires it in a different order — comprehension first, authorship second — and comprehension without authorship is a genuinely harder cognitive task that very little professional training addresses.
This is where an under-discussed risk sits. Assistance is most useful precisely where an engineer is weakest, which is where they are least equipped to notice a plausible mistake. A senior engineer using assistance in their own domain gets faster. A junior engineer using it in a domain they have not yet learned gets output they cannot evaluate, and the gap does not announce itself until something breaks in production.
The regulatory layer adds a second requirement. The European regulation laying down harmonised rules on artificial intelligence (Artificial Intelligence Act) places obligations around the competence of people deploying and using these systems, alongside its risk-tiered requirements on the systems themselves. For an engineering organisation that means being able to evidence understanding, not merely usage — a documentation and training obligation rather than a tooling one.
The practical competence, then, is a combination: enough depth in the domain to evaluate what comes back, a habit of testing generated code against the cases the prompt did not mention, and the professional willingness to discard fluent output that is wrong. Structured development of exactly this evaluative capability is what the programme Artificial Intelligence: Developing Future Competencies is built around.
Security Stopped Being Somebody Else’s Job
The second shift is a redistribution of duty rather than a new technology. Security was historically organised as a specialist function that reviewed work produced by other people. That arrangement survives on paper in many organisations and has stopped working in practice, for a structural reason: the volume and speed of change exceeds what any review-gate can inspect without becoming the bottleneck everyone routes around.
What replaces it is an expectation that ordinary engineering roles carry security competence as part of their baseline. Not the depth of a security specialist — that role does not disappear and its scarcity has not eased — but enough to recognise a familiar failure class while writing the code rather than after an audit finds it. The catalogue of those classes is not secret: the OWASP Top Ten Web Application Security Risks has been the common reference for long enough that unfamiliarity with it now reads as a gap rather than a specialisation.
Regulation has hardened this from a good practice into a compliance requirement in several sectors, with obligations landing on how organisations run and evidence their security posture rather than merely on whether they have a security team. The practical effect on competence is the same wherever the sector rules apply: the ability to demonstrate that engineers understand the risk model of what they are building has become something an organisation must be able to show, not merely assert.
The infrastructure side of this has shifted in the same direction and for the same reason. When environments are defined in code and provisioned on demand, a misconfiguration is a commit rather than an operator error, which means it is created by an engineer, reviewed by engineers and prevented — if it is prevented — by engineering practice. Identity and access configuration has become the boundary that most reliably determines what an incident costs, and it is now edited by people whose job title says nothing about security. An engineer who can reason about which credential is doing what, why a permission is broader than the task requires, and what a compromised component would be able to reach has a competence that used to sit entirely in another department.
The competence this actually requires is narrower than a security curriculum and harder to fake. It is the ability to ask, about your own design, what an attacker would try first, where trust is being assumed rather than established, and what the blast radius is when a component behaves badly. Engineers who can do that make the specialist function effective. Engineers who cannot make it a queue.
Cost and Energy Became Engineering Properties
The third shift is the least glamorous and the most reliably underestimated. In an environment where capacity is purchased continuously rather than procured in advance, an architectural decision is a spending decision, made by an engineer, usually without a spending conversation happening anywhere.
That is the whole content of the discipline described as What is FinOps? — bringing financial accountability into the variable-spend model of cloud, so the people making the technical choice can see its cost consequence. The vendor guidance says the same thing structurally: the Cost Optimization Pillar - AWS Well-Architected Framework treats cost as a design property to be reasoned about alongside reliability and performance, not as an accounting exercise performed later by somebody else.
The competence this creates is a form of literacy rather than a tool skill. An engineer needs to be able to read what a design will cost to run, to recognise which choices are cheap to reverse and which lock in an operating expense, and to raise the question early enough that it can still influence the design. Nobody needs to become a financial analyst. But an engineer who cannot estimate the running cost of their own architecture is making an uninformed decision on the organisation’s behalf, and the organisation usually finds out a quarter later.
It helps to be concrete about where the spending decisions actually get made, because they are rarely where people look for them. They are made when someone chooses to move data between regions rather than process it where it already sits. They are made when a storage class is selected by default rather than by retention requirement. They are made when an environment is provisioned generously to remove a sizing conversation, and then never revisited because nothing is failing. They are made when a test environment stays running through a quarter because no one owns switching it off. None of those are visible in a design review that only asks whether the system works, and all of them are obvious in a review that also asks what the system will cost while it works.
Energy efficiency converges on the same competence from a different direction. The work described under the heading What is Green software? is about writing and running software that consumes less energy for the same result — which is, in practice, the same measurement discipline as cost, with a different unit and increasingly a reporting obligation attached. Organisations that build the two capabilities separately usually discover they have paid twice for the same skill.
The Organisational Shift: Specialists With Business Context, Not Generalists
The fourth change is not technological, and it is the one most likely to be mishandled, because organisations respond to it by buying training when the problem is structural.
The shift is this. Teams are increasingly composed of deep specialists rather than interchangeable engineers, and a team of deep specialists only works if its members can operate across the seams between their specialisms. That requirement is what the T-shaped model describes — depth in one area, sufficient breadth to collaborate outside it — examined for technology careers in T-shaped Learning in IT: Why the Future of Specialists Requires a Broader Perspective. What is newer is that the breadth increasingly has to include the business the software serves.
There is a good reason for that. When an engineering decision is also a spending decision, a security decision and a regulatory decision, an engineer without commercial context is not neutral — they are deciding those things by default, without the information that would let them decide well. The organisations that handle this best treat exposure to the business as part of the engineering job rather than as a reward for seniority, which is a job-design change and not a curriculum.
This is also where the persistent hiring difficulty actually sits. The scarce profile is rarely a technology; it is the combination of technical depth with enough understanding of what the organisation is trying to achieve to make the depth useful. That combination is hard to buy and comparatively easy to build internally, provided the organisation is willing to give people work that develops it. Programmes such as Digital Competencies and IoT in Business Development address exactly that seam from the engineering side: how a connected-technology capability turns into something a business can use, decide about and pay for — which is the translation layer specialists most often lack and most need.
There is a second-order effect worth naming, because individuals feel it before organisations acknowledge it. If the specialisation that makes someone valuable also has a shelf life, then a career in this field is a sequence of partial rebuilds rather than a single accumulation. Periodically an engineer will have to become a beginner again in something adjacent, while continuing to deliver at a senior level in what they already know. That is uncomfortable in a way that has nothing to do with capability — it is uncomfortable because professional identity is invested in competence, and deliberate incompetence is the price of staying current. Organisations make this cheaper or more expensive by what they reward. Where learning happens only in the gaps left by delivery pressure, people do the arithmetic and stop, and the organisation then describes the result as a skills gap it did not cause.
What This Does Not Change
An article about shifts owes the reader an equally clear statement of what is stable, because planning a career around change alone produces someone who is current and shallow.
The fundamentals have not moved. Understanding how systems fail, how data is modelled, how networks behave, how concurrency goes wrong and how to reason about a problem you cannot reproduce — these remain the difference between an engineer who can be trusted with something hard and one who cannot. Every shift described above increases their value rather than reducing it. Verification of generated output requires them. Recognising a security failure class requires them. Predicting the cost behaviour of an architecture requires them.
Certification remains useful within a bounded role: it is an efficient signal for platform-specific and security-specific knowledge, and a poor signal for judgment. Nobody has yet designed an examination that measures whether someone will make a good decision under ambiguity in the middle of the night.
The honest summary for an individual is therefore unglamorous. Keep the fundamentals sharp, add the evaluative competence that generated output now demands, treat security and cost as parts of your own design rather than someone else’s review, and get close enough to the business to know which constraint actually matters. That list has not changed much in substance. What changed is that skipping any part of it is now visible sooner.
Frequently Asked Questions
Which IT competencies are actually in demand now?
Depth in a domain with real difficulty — distributed systems, security engineering, applied machine learning, data platforms — combined with the ability to evaluate output the engineer did not produce, to recognise common security failure classes while designing, and to reason about what an architecture will cost to run. The scarce profile is that combination, not any single technology.
Does using AI assistance make deep technical knowledge less necessary?
The opposite. Accepting generated output means becoming accountable for code you did not write, which requires enough depth to notice a plausible mistake. Assistance is most helpful where an engineer is strongest and most dangerous where they are weakest, because that is exactly where a wrong answer looks convincing.
Do certifications still matter for an IT career?
Within limits. They are an efficient signal for platform-specific and security-specific knowledge and are frequently required for particular roles or contracts. They do not evidence judgment, which is what senior hiring is actually selecting for, so a portfolio of consequential work remains the stronger part of a profile.
How should an organisation build these competencies rather than hire them?
Mostly by changing what work people are given. The scarce combination — technical depth plus business context — develops through exposure to consequential decisions with feedback, which is an assignment decision. Formal training accelerates the technical half; only job design produces the other half.