Hiring for the Stack, Paying for the Context

TL;DR

Swiss employers are not simply facing a shortage of data engineers or a choice between local and offshore delivery. They are pricing the wrong unit. Tool proficiency is increasingly easy to verify, move, and automate; institutional context is expensive to acquire and difficult to transfer. The durable staffing decision is therefore about where context, specification, and accountability live—not where a laptop is located.

Key takeaways

• Swiss graduate IT vacancies fell 31 percent in the first half of 2025, then returned to 6 percent annual growth by the second quarter of 2026; that is a change in demand, not proof of a return to the old market.
• Swiss postings increasingly weight transversal capability over formal knowledge, while job-specific skill requirements remain comparatively stable.
• Switzerland still faces a large long-term ICT talent requirement, so selective hiring, global capability centres, automation, and immigration constraints must be read together.
• Work that is easy to specify remotely is also the work most exposed to automation; the middle layer of seat-priced ticket execution is under pressure from both directions.
• Forward deployment is proximity to consequence and ownership after go-live, not mandatory office attendance.
• In regulated data estates, specification and context transfer are real delivery costs and governance obligations.
• Employers should hire for domain learning, context acquisition, accountable outcomes, and the ability to explain the system—not only for a named stack.

Two things happened in the Swiss market over the past eighteen months that most hiring committees have not yet reconciled, and the failure to reconcile them is producing a specific and expensive category of mistake.

The first is that the market for graduate IT professionals collapsed and then came back as something else. In the first half of 2025, the Adecco Group Swiss Job Market Index — compiled with the Swiss Job Market Monitor at the University of Zurich — recorded a 31 percent year-on-year fall in vacancies for graduate IT professions, the largest decline of any occupational group it tracked. That category includes software developers, IT architects, database and network specialists, and data analysts. In the annual comparison reported for the second quarter of 2026, IT professions were growing again at 6 percent, even as the overall market remained nearly flat at minus 0.2 percent year on year. Employment demand did not return to where it left. It returned somewhere adjacent, and the difference is the subject of this piece.

The second is that the largest and most consequential technology employer in Swiss financial services announced, in February 2026, that it expects to hire up to three thousand people in India — a new Hyderabad site adding two to three thousand roles in technology and operations — while roughly the same number of positions disappear in Switzerland through attrition and early retirement. UBS declined to say the two were connected, and people close to the bank said they were not. Whether or not one caused the other, the pairing is the clearest available signal on where large regulated institutions currently believe engineering capacity should sit. Anyone writing that the offshore delivery model is finished has to explain that announcement first, and most of them do not try.

I do not think either signal supports the conclusions usually drawn from it. The market did not stop wanting data engineers; it changed what it wants them for. And the offshore model is not dying; it is being hollowed out from the middle in a way that makes both its remaining ends more defensible and the space between them commercially untenable. Employers who read either signal as a simple directional instruction — hire fewer, or send more offshore — are making a category error whose cost often becomes visible only later, when a regulated data estate has to explain, reconcile, or remediate what was delivered.

The posting data says something more useful than the headcount data

Headcount announcements are strategy communications. Job postings are closer to revealed preference, because somebody had to write the specification and somebody else has to be measured on filling it.

The Adecco and University of Zurich analysis published in the first quarter of 2026 drew on more than a million Swiss job advertisements spanning 2015 to 2026, which is a long enough window to distinguish structural drift from one weak quarter. Its finding was not that employers are asking for more, but that they are asking for something of a different kind. Formal knowledge requirements fell from around 25 percent of extracted skill requirements in 2015 to under 23 percent in 2026. Job-specific skills held between 13 and 15 percent, with no discernible trend. Transversal skills — analytical thinking, self-directed work, teamwork, willingness to learn — rose from just under 60 percent to more than 63 percent of extracted requirements and appeared in roughly 85 to 90 percent of postings throughout the period.

The researchers were careful to note that this predates the current AI cycle and is not caused by it. That caveat matters more than the finding. A structural shift that began before generative AI became a board topic and continued through it is not a fashion; it is a change in what employers believe production work requires. The AI cycle has accelerated a curve that was already bending.

Set that against the demand-side arithmetic. The education-needs forecast commissioned by ICT-Berufsbildung Schweiz puts Switzerland's ICT workforce at roughly 266,000 in 2024 and estimates a need for around 128,600 additional specialists by 2033. Even after counting expected graduates and immigration, the study still assumes a shortfall in the region of 54,400 people. Against that, the Federal Council has held third-country work permit quotas unchanged for 2026 at 8,500 — 4,500 B permits and 4,000 L permits — for the entire economy, not for technology. Whatever the shortage is, it will not be closed by importing it, and Swiss employers have known this long enough that the offshore and nearshore build-out was the rational response for two decades.

So the labour market picture, stated plainly, is a persistent structural shortage of qualified people, a cyclically weak year that hit graduate IT harder than anything else, a partial recovery that has changed the composition of what is being asked for, and no meaningful relief available through immigration. Public salary estimates reflect this confusion rather than resolving it: sources disagree materially about both the centre and the senior range. Some of that dispersion is methodological, but some of it is what happens when a single job title covers work with radically different context requirements. The title has stopped carrying enough information on its own.

Hiring for what is cheap to verify

The most common failure in Swiss data engineering recruitment is not a failure of generosity or of process discipline. It is a measurement failure, and it is committed by careful people.

A hiring manager writing a data engineering specification has to describe a role to a recruiter, a screening panel, and eventually a compensation committee, all of whom need something they can check. Tool proficiency is checkable. Spark, dbt, Databricks, Snowflake, Kafka, Airflow, some flavour of infrastructure-as-code, some certification. It can be tested in an hour, ranked across candidates, and defended in a hiring committee without the person defending it needing to understand the domain. Business context cannot be tested in an hour. It can barely be described. The person who has it usually cannot articulate what they know, because the knowledge is procedural and accreted rather than declarative — they know that the settlement date field in one source system is populated by a batch job that runs before the corrections file arrives, and they know it because they were on the call when the reconciliation broke in 2019.

The consequence is a screening rubric that selects hard for the capability which has depreciated fastest and screens softly for the capability that has become scarce. This is not a hypothetical inversion. It is the mechanical consequence of measuring what is easy to measure, and it has been the standard failure mode of technical hiring since long before anyone had an opinion about large language models. What has changed is the cost of the error, because the depreciation rate on tool-specific proficiency has gone from slow to fast.

There is a second-order effect that is worse. Because the rubric selects for tool fluency, the people it hires are strongest at the work that can be specified into a ticket. Because they are strongest at that work, the organisation naturally routes that work to them, which means the organisation's data engineering capacity becomes concentrated in exactly the category of work that is most portable to a lower-cost jurisdiction and most amenable to automation. The team then discovers, usually during a cost review, that it has spent three years building a function whose entire output is substitutable. I have watched a version of this happen and I do not think anybody involved made an individually unreasonable decision.

What the offshore model actually required, and why it worked

It is worth being precise about the offshore model rather than arguing with a caricature of it, because the caricature is what makes the current commentary useless.

The large-scale offshoring of software delivery from Western Europe was not a mistake and was not a fad. It worked, repeatedly, on a specific class of problem. The proof of concept at industrial scale was Y2K remediation, which had the rare property of being enormous, urgent, tedious, and completely specifiable. Every remediation task could be described in advance, executed against a defined acceptance test, and verified without reference to what the system was for. The offshore delivery centres of the late 1990s executed that work well, and the industry drew a conclusion from it that was correct for that class of work and was then over-generalised for the next twenty-five years.

Swiss institutions built on that conclusion carefully and, on the whole, competently. The nearshore build-out into Poland is the clearest local example: by 2017, Credit Suisse had around 4,500 people in Wrocław and UBS around 3,500, and the roster of Swiss captives across Warsaw, Kraków and Wrocław extended well beyond banking into SIX, ABB, Zurich Insurance, Roche and others. Poland offered something genuinely valuable that pure labour arbitrage does not capture: the same time zone, a two-hour flight, complete calendar overlap, and a regulatory environment inside the EU. An architect in Zurich could hold a working session at fourteen hundred and see the result before close of business. That is not arbitrage; that is a functioning distributed team.

The model's precondition, in every one of its successful forms, was the existence of a specification good enough to be executed remotely. That precondition was always expensive to satisfy, and it was almost never priced. Business cases for offshore delivery model the engineer. They do not model the specification. In a regulated data estate, the specification is the expensive artefact and the engineer is the cheap one, and this inversion is the single most consistently mispriced item in sourcing decisions I have seen.

Consider what a genuinely complete specification requires in a bank. It requires someone to state which of four candidate fields constitutes the balance the regulator will accept, and why the other three exist. It requires someone to know that a client relationship can be legally domiciled in one entity and economically attributed to another, that the two views diverge for a defined population, and that the divergence is deliberate rather than a defect. It requires knowing which upstream system is the golden record for a given attribute this quarter, given that it was a different system last year and the migration is only partly done. None of this is documented in a form that survives transmission. It lives in the working memory of people who have been in the estate long enough to have been burned by it, and the act of extracting it into a specification is itself a senior, on-site, high-context engineering task.

When that extraction is done properly, remote delivery performs well. When it is skipped — and it is skipped whenever the business case has been written to a cost target — what arrives back is work that is technically correct and operationally wrong. Practitioners who have run these programmes describe the same shape every time: the ticket closes, the acceptance criteria pass, and the defect surfaces two quarters later in a reconciliation nobody had thought to run. The rework is then attributed to quality, which is the wrong diagnosis. It is a specification failure that was booked as a delivery saving.

What AI changed, stated carefully

This is the section where most articles on this subject fail their reader, and where the evidence deserves more care than it usually gets.

The most rigorous single study of AI's effect on experienced developer productivity remains METR's randomised controlled trial, published in July 2025. Sixteen experienced open-source developers completed 246 real tasks in mature repositories where they averaged five years of prior experience, with each task randomly assigned to permit or forbid AI tooling. The developers forecast a 24 percent speed-up. After completing the work, they estimated they had been sped up by 20 percent. Measured, they were 19 percent slower. The gap between perception and measurement was the finding, more than the slowdown itself.

That result is now widely quoted and it should be quoted with its own authors' caveat attached. METR has explicitly labelled it historical and stated that it no longer necessarily reflects the current impact of AI tools on developer productivity. Their follow-up experiment, begun in August 2025 with a larger cohort, ran into a selection problem they judged fatal to the estimate: developers increasingly declined to participate if they might be assigned to work without AI, and avoided submitting exactly the tasks they most wanted AI for. In February 2026 METR published a note saying it was redesigning the experiment, that the newer data gave an unreliable signal, and that its own judgement is that AI likely provides productivity benefits in early 2026 without a defensible number attached to the magnitude.

That is an honest epistemic position and it is more useful than a confident one. What survives it is a narrower and sturdier claim, and it is visible in the contrast between the METR trial and an earlier controlled study of GitHub Copilot in which participants completed a standardised, self-contained programming task substantially faster, with the largest benefit accruing to less experienced developers. The difference between the two results is not the tooling. It is task context. On constrained, well-defined, low-context problems, these tools deliver large gains, and they deliver the largest gains to the least experienced people. On high-context work inside a mature estate that the engineer already understands deeply, the gains compress and can invert, because the binding constraint was never typing speed.

That distinction is the whole argument, and it maps with uncomfortable precision onto the offshore delivery boundary. The work that is portable to a remote delivery centre is portable precisely because it is well-specified, self-contained and low-context. That is the same property that makes it the most automatable work in the estate. The qualities that made a task easy to offshore are the qualities that make it easy to absorb.

The market has begun to price this. Harvard Business Review has argued that generative AI is eroding the labour-arbitrage model underpinning decades of outsourcing, with the effect clearest where work is digital, rules-based, and measurable. The important conclusion is not that outsourcing disappears, but that headcount-based rate cards face pressure from outcome- and capability-based models.

I want to be careful not to overstate this, because the counter-evidence is substantial and points the other way. UBS is expanding in Hyderabad, not contracting. The evolution of offshore centres into global capability centres owning product lifecycles rather than executing tickets is a real and well-capitalised trend, and it is an intelligent response to precisely the dynamic described here. A GCC that has institutionalised domain knowledge over a decade is not a ticket queue; it is a distributed part of the firm with genuine context, and it will outperform an under-informed on-site team every time. The argument is not that distance is bad. It is that the middle tier — remote execution of work someone else specified, priced per seat, measured on delivery — has lost its economic rationale from both directions at once.

Forward deployment, and what it is not

The term "forward deployed engineer" has been in circulation long enough to have been diluted, and it is worth recovering the original meaning before the Swiss market adopts the label without the substance.

Palantir made the forward-deployed role central to a delivery model for customer problems that could not be solved through a conventional handover. The distinguishing feature was never the travel or the client site. It was the accountability boundary. A product engineer is measured on whether what they built works as specified. A forward deployed engineer is measured on whether the customer got the outcome, after delivery, in their actual environment, against their actual data. The role was built to refuse the systems-integrator posture — to write production code against the customer's real systems and own the result rather than the handover. What flows back from that engagement into the platform is the second half of the model and the reason it compounds.

Variants of the pattern now appear across the AI industry under several labels. The reason for its adoption is not mysterious, and it is the same reason that matters to a Swiss bank: the constraint on enterprise AI value is often deployment into a specific environment rather than model capability.

Which brings us to the misreading I would most like Swiss employers to avoid. The MIT NANDA report from July 2025 — the source of the ubiquitous claim that 95 percent of enterprise AI pilots deliver no measurable profit-and-loss impact — is preliminary, not peer-reviewed, built on 52 organisational interviews, roughly 150 survey responses and analysis of around 300 public deployments, and has been criticised on sample and measurement window. It is at best a rough indicator, and it is quoted far more often than it is read. Read, it says something inconvenient for the in-housing argument: in its own sample, externally partnered deployments reached production roughly twice as often as internally built ones. Separately, S&P Global found the share of firms abandoning most of their AI initiatives rising to 42 percent from 17 percent a year earlier, with the average organisation scrapping close to half its proofs of concept.

None of that supports "hire AI engineers internally and the problem resolves." What it supports is narrower and more defensible: the scarce function is deployment into context, and the sourcing question is secondary to whether that function exists at all and whether anyone is accountable for it. An organisation can buy that capability, build it, or borrow it. What it cannot do is skip it and expect the model to bridge the gap.

Forward deployment, in the sense worth adopting, is therefore an architecture decision rather than a real-estate policy. Mandating attendance in a Zurich office four days a week does not create a forward-deployed function. Embedding an engineer inside the business unit that owns the data, with accountability for the outcome after go-live and a direct path for what they learn to change the platform, does. The distinction is between physical proximity and proximity to consequence, and only the second one produces the knowledge that cannot be transmitted through a specification.

The constraint that makes this a governance question rather than a preference

For regulated institutions, and particularly for Swiss financial services, this stops being a talent-strategy discussion and becomes a supervisory one, which is where I expect most disagreement with this piece to be resolved in practice.

FINMA Circular 2018/3 permits outsourcing outside Switzerland, and does so on a principle-based, technology-neutral footing that deliberately avoids prescribing arrangements. What it requires is that the institution, its regulatory audit firm and FINMA can duly exercise and enforce their inspection and audit rights, that the institution maintains an inventory of outsourced functions naming service providers including subcontractors, and — the provision most often underweighted in sourcing business cases — that outsourcing must not hinder restructuring or resolution in Switzerland, with access from Switzerland to data held abroad guaranteed at all times. The 2018 revision moved data protection and banking secrecy out of FINMA's circular, which did not remove those obligations but relocated where a bank must go for comfort on them, toward the FDPIC and the criminal law. Circular 2023/1 on operational risks and resilience then introduced the concept of critical data requiring enhanced protection. Data protection, professional secrecy, operational resilience, and sector guidance remain additional parts of the control environment rather than disappearing from it.

Read together, these do not prohibit distance. They price it. Every boundary between the accountable institution and the engineering work can add an evidentiary burden: demonstrable audit reach, demonstrable data access under resolution, demonstrable lineage from the regulatory report back to the source system, and a named accountable owner who can answer for all of it. The BCBS 239 and RDARR expectations that G-SIBs have lived with for a decade are, at bottom, expectations about whether an institution can explain its own numbers — and the ability to explain a number is a function of who understands what the number means, not of where the pipeline runs.

This is why I think the sourcing question is misframed as a cost question. The genuine question is where the trust boundary sits. Work that crosses a jurisdictional boundary crosses a governance boundary at the same time, and the operational friction that creates is real, recurring, and almost never modelled. It shows up as slower incident resolution because the person who understands the semantics is asleep. It shows up as lineage documentation that satisfies a control tester and not an examiner. It shows up, eventually, as a finding.

The regulatory trajectory reinforces rather than relieves this. The Federal Council decided in February 2025 against a horizontal AI act, opting instead to ratify the Council of Europe Framework Convention on AI and to legislate sector-specifically, with a consultation draft due by the end of 2026. For financial institutions this is the harder path, not the easier one, because obligations will surface through the supervisory regime they already sit inside rather than arriving as a single labelled rulebook. Accountability for an AI-assisted data pipeline will be assessed under operational risk, data protection and outsourcing rules that already exist and already assume a named accountable person within reach of the supervisor.

What this implies for how the work is specified and staffed

Some of what follows is uncomfortable for an organisation optimising a cost line, and I want to be clear that I do not think there is a version of this that is both cheap and defensible.

The first implication is that the data engineering job specification needs to be rewritten around context acquisition rather than tool inventory. That means describing the domain the person will own, the systems whose semantics they will be expected to understand, and the business counterparts they will sit with — and being willing to trade two named technologies for demonstrated depth in an adjacent regulated domain. This is harder to defend in a hiring committee, which is exactly why it is not being done. The Adecco and University of Zurich finding that Swiss employers are already reducing formal knowledge requirements while raising transversal ones suggests the market is drifting this way ahead of the average job advertisement.

The second is that specification production has to be recognised as a distinct, senior, high-context function with a name, an owner and a budget line, rather than as unpriced overhead absorbed by whoever is nearest. In estates where this has been done properly, the effect on remote delivery quality is larger than any change to the delivery arrangement itself. The corollary is that an organisation without this function should not be making sourcing comparisons at all, because it is comparing a known rate against an unknown and unbounded translation cost.

The third is that accountability for outcome after go-live has to sit with someone who was present during the design. This is the only part of the forward-deployed model that is genuinely non-negotiable, and it is the part most commonly discarded when the pattern is adopted by name. If the engineer who built it is measured on delivery and someone else is measured on whether it works, the feedback loop that makes the model valuable does not exist, and what has been bought is a job title.

The fourth is that the work should be segmented deliberately rather than by default. Well-specified, self-contained, low-context work should be assumed to be automatable within the planning horizon, and staffed accordingly — which for most institutions means neither hiring for it locally nor building a large remote team around it. High-context work should not be treated as portable until the organisation can show how the context travels, because the cost of transporting it is a specification cost that will be paid whether or not it appears in the business case. The middle, where most institutions currently have the largest headcount, is the part that needs an explicit decision rather than an inherited arrangement.

What would falsify this

I hold this argument with less confidence than the preceding sections suggest, and a reader is entitled to know what would change it.

If the AI productivity gains on high-context work converge with the gains on constrained tasks — if the tools become genuinely capable of acquiring an estate's undocumented semantics from its code, logs and lineage rather than requiring a human to supply them — then the specification cost collapses and the offshore model's central precondition becomes cheap to satisfy. That would restore the arbitrage rather than eroding it, and it would make most of this piece wrong. There is nothing structural preventing it and the trend line in agentic tooling points that way.

If global capability centres continue maturing at their current rate, the distinction between on-site and remote may cease to track the distinction between high-context and low-context. A GCC that has held the same domain for fifteen years has context. The argument here is about context, not geography, and I have used geography as a proxy throughout because it is currently a good one. It may not remain one.

And if the Swiss vacancy recovery in graduate IT professions turns out to be cyclical rather than compositional — if the roles coming back are the same roles that left — then the posting-data argument weakens considerably. One year of index data supporting a structural reading is thin, and I would want to see the composition hold through 2027 before treating it as settled.

What I do not expect to change is the underlying asymmetry, because it is not a technology claim. In a regulated data estate, the expensive artefact is the shared understanding of what the data means, and that understanding is produced by proximity to consequence over time. It has never been cheap, it has never appeared on a rate card, and every sourcing model that has treated it as free has eventually paid for it at a premium, usually in a remediation programme named after the control that failed. That has been true through the mainframe consolidations, through the core banking platform migrations, through the outsourcing mega-deals and the repatriations that followed them, and I see no reason to expect this cycle to be the one that breaks the pattern.