7 mins read
Description: A practical guide for HR and talent teams in travel — which digital transformation capabilities to hire, which to develop, which to contract in, and how to assess technical candidates when the interview panel is not technical.
Digital transformation in travel is usually described as a technology programme. In HR terms it is a staffing problem. Software can be bought in a quarter; the people who choose it, connect it to the reservation system, and persuade a contact centre to work differently take far longer to find and are much easier to lose.
That is not a travel-specific observation. The World Economic Forum's Future of Jobs Report 2025 found that 63% of employers name skills gaps as the key barrier to transforming their business, and that close to 40% of the skills people use on the job are expected to change by 2030.
Travel agencies meet that challenge from a tight starting position. The World Travel & Tourism Council projects that the sector will add 91 million roles by 2035 while demand outpaces supply by more than 43 million people, leaving labour availability around 16% below what the industry needs. HR teams are being asked to recruit integration engineers and data specialists into an industry already competing hard for staff at every level.
Start with the capability gap, not the job title
The most common hiring mistake here is writing a job description from a vendor's feature list. It produces roles that read well and attract nobody, because the posting describes a technology stack rather than a problem worth solving.
A better starting point is a short conversation with operations about work that currently cannot be done. Nobody can connect the booking platform to the CRM without a manual export. Nobody owns data quality, so every report is argued over before it is used. No one can specify what an AI assistant would need in order to answer a customer accurately.
Complaints like these usually resolve into four capabilities rather than four headcount requests:
- integration and API work, to connect systems that were never designed to talk to each other;
- data engineering and data quality, so reporting and AI have something reliable to run on;
- product ownership, to decide what gets built and in what order;
- security and compliance, because traveller data carries real obligations.
A mid-sized agency rarely needs all four permanently. Separating the capability from the headcount is what makes the next decision possible.
Buy, build or borrow
Each capability can be filled three ways, and the right answer differs by capability rather than by company.
Buy: hire the capability permanently
This is the right call when the work is continuous and the knowledge is worth keeping — product ownership and data quality usually qualify. The trade-off is time and price. Technical hires in travel compete directly with technology employers on salary and flexibility, so a role benchmarked only against internal pay bands tends to stay open far longer than the project plan assumed. HR's contribution here is an honest benchmark and a realistic time-to-fill forecast before the business commits to a delivery date.
Build: develop it internally
Some of the capability already exists in the business. Revenue and operations analysts often understand the data better than any external hire will for the first six months, and some are a reasonable distance from a data engineering role with structured training and a mentor. It is slower than hiring but retains people who already know how the business runs. The Forum's research found 77% of employers plan to upskill their workforce in response to AI — in travel, the candidates for that are often sitting in reservations and revenue management.
Borrow: contract it in
Fixed pieces of work with a clear end — a migration, an integration layer, a rebuilt booking front end — suit contractors or an external engineering partner. Agencies without an internal engineering function frequently contract this out to firms specialising in travel and hospitality software development, which shortens delivery but leaves the knowledge outside the business.
The HR risk in borrowing is not cost, it is capability leaking out at the end of the contract. Handover terms, documentation standards, and a named internal owner belong in the agreement from the start, not in the final month.
| Option | Fits when | HR's main risk |
| Buy (hire) | The capability is needed continuously and the knowledge should stay in the business, as with product ownership and data quality. | Long time to fill, and pay bands that do not compete with technology employers. |
| Build (upskill) | Someone internal already understands the business and is within reach of the role with training and a mentor | Slower than hiring, and it fails if people are given a course but no protected time. |
| Borrow (contract) | Fixed-scope work with a clear end, such as a migration or an integration layer | Capability leaves with the contract unless handover, documentation and an internal owner are agreed upfront. |
Writing a job ad that technical candidates answer
Technical candidates read job ads for scope, not for adjectives. A posting that says "exciting transformation journey" and lists fourteen technologies signals an employer that has not decided what the role does.
Three things raise the response rate more than anything else:
- Name the actual problem. "Connect a 20-year-old reservation system to a modern CRM without downtime" is a more attractive sentence to an engineer than any description of company culture.
- Be honest about the legacy environment. Candidates find out in week two anyway, and the ones who leave over it are the ones who were misled in the ad.
- Separate essential from desirable. Long lists of mandatory requirements narrow the applicant pool without improving the shortlist, and are widely reported to deter otherwise qualified candidates from applying at all.
Assessing technical candidates when the panel is not technical
Many travel agencies have no CTO or senior engineer free to sit on an interview panel, which pushes decisions towards confidence rather than competence. Two practices close most of that gap.
The first is a work sample drawn from the real environment. Give the candidate a sanitised description of the current systems and ask how they would sequence the first ninety days. Strong candidates ask about data ownership, downtime tolerance, and who signs off changes. Weaker ones go straight to naming tools.
The second is a structured scorecard used by every interviewer, with one criterion that matters more than the technical ones: can this person explain a trade-off to a colleague in operations without condescending to them? Transformation work stalls on adoption as often as on architecture, and adoption depends on whether the people running reservations trust the person changing their systems. Where no internal reviewer exists, a few hours of an independent engineer's time to review the shortlist is cheaper than a mis-hire.
The people who stay matter more than the people you hire
Every system that gets replaced changes somebody's job. Reservation agents lose the workarounds they built over a decade. Finance loses a spreadsheet it trusted. If the first time those teams hear about a change is at go-live, adoption suffers regardless of how good the new system is.
Practically, that means L&D planning starts alongside the build rather than after it, supervisors are briefed before their teams are, and at least one respected person from each affected team is involved early enough to influence the design. It is also worth being straightforward about roles that will change substantially — people manage change better with accurate information than with reassurance.
What HR should measure
Transformation hiring is easy to declare successful and hard to prove. A small set of measures keeps it honest:
- time to fill for technical roles, tracked separately from commercial roles, because mixing them hides the problem;
- first-year attrition among transformation hires, which usually exposes an unclear mandate rather than a bad hire;
- internal fill rate, showing whether the build option is being used or only discussed;
- proportion of affected staff trained before go-live, not after;
- system adoption at 30 and 90 days, which is the only number that tells you whether the hiring worked.
Conclusion
Travel agencies modernising their technology are competing for scarce technical people while already short-staffed in their core operation. The agencies that manage it tend to be specific about which capabilities they actually need, deliberate about which to hire, develop or contract, and disciplined about preparing the people whose daily work the new systems will change. None of that is a procurement decision. It is workforce planning, and it belongs to HR.
