Talent Shortages Will Double Hiring Timelines in 2026 — Upskill or Outsource?

[product_david]

This Is Not an HR Problem — It’s a Business Strategy Decision

Let me lay out the situation as plainly as I can from a VP of Product perspective: the engineering talent market in 2026 is not going to save us. The numbers are stark. According to DAVRON’s 2026 engineering hiring market analysis, there are currently three engineering jobs for every one qualified candidate. Demand for engineering talent continues to rise faster than supply, with competition for specialized skills — AI/ML, data engineering, cybersecurity — remaining brutally intense even as general availability has slightly improved.

A McKinsey survey found that 77% of companies report they lack the necessary talent and skill sets for mission-critical areas including cybersecurity and data management. That’s not a hiring problem. That’s a strategic crisis.

For product leaders, this means a fundamental question: when you can’t hire fast enough, what do you do? Because the roadmap doesn’t pause while recruiting figures it out. Customers don’t care that your time-to-fill has doubled. Competitors aren’t waiting.

The Three Options (and Their Real Trade-offs)

Option 1: Upskill Your Existing Team

DAVRON’s 2026 workforce trends data shows that companies placing greater emphasis on upskilling and reskilling are seeing measurable benefits within 6-12 months. Training internal employees is more cost-effective than external hiring and dramatically reduces onboarding time because they already know the codebase, the culture, and the customers.

The upside: Deep loyalty, retained institutional knowledge, lower recruiting costs. An engineer you reskill from backend to full-stack already understands your domain, your deployment pipeline, your on-call rotation. They’re productive in weeks, not months.

The downside: Opportunity cost. While your engineers are learning new skills, they’re not shipping features. For a product leader with quarterly targets, that 20% productivity dip during training feels like bleeding out. And not every engineer wants to be reskilled — some will leave rather than pivot.

Option 2: Outsource to Agencies and Contractors

The 2026 trend data shows organizations increasingly turning to nearshore staff augmentation, particularly in Latin America, where senior developers operate within 1-4 hours of US time zones. This is a legitimate option that has matured significantly.

The upside: Speed. You can spin up a team of 5 engineers in weeks, not months. No benefits costs, no long-term commitments, and you can scale down just as quickly.

The downside: Knowledge silos, communication overhead, IP risk, and the insidious problem of context-switching. Every question an outsourced engineer asks your senior team is a context switch that costs 20+ minutes of recovery time. At scale, this hidden tax is enormous. And when the contract ends, the knowledge walks out the door.

Option 3: Accept Slower Growth

Nobody wants to say this out loud, but it’s the honest third option. If you can’t hire fast enough and won’t outsource, your growth is constrained by your current team’s capacity. Period.

The upside: Quality stays high. Culture stays intact. Tech debt stays manageable. Your existing team isn’t burned out covering for gaps.

The downside: Your board, your investors, and your competitors won’t accept this framing. In a market where speed matters, deliberate slowness can be fatal.

The Real Answer: A Strategic Framework

Here’s what I’ve come to believe after watching three companies struggle with this exact dilemma: the mistake is treating all engineering work as equally strategic.

Not every feature on your roadmap requires deep domain knowledge. Not every system needs to be maintained by in-house engineers who understand the full context. The right approach is a framework:

1. Core domain logic, data pipelines, and customer-facing systems — these must be built and maintained by in-house engineers who understand the business deeply. Upskill for these roles.
2. Infrastructure, tooling, and well-defined integration work — these are strong candidates for outsourcing, especially when the requirements are clear and the interfaces are well-defined.
3. Experimental features and proof-of-concepts — contractors can move fast here because the cost of getting it wrong is low.

According to DAVRON’s engineering leadership data, companies in 2026 are also shifting away from traditional degree requirements toward skills-based evaluation, which widens the talent pool significantly. The firms that succeed will build long-term talent pipelines rather than relying on last-minute hiring.

The Speed Factor

One more critical data point: DAVRON reports that speed has become one of the clearest signals of organizational competence in 2026 hiring. Candidates expect prompt outreach, clearly defined interview stages, and timely decisions. Companies that can move from initial screen to offer within a few weeks are viewed as organized and confident. Those with drawn-out processes lose candidates to faster-moving competitors.

So even as hiring timelines stretch due to talent scarcity, the companies that win are the ones who make their internal hiring process faster, not slower.

---

I’d like to hear from engineering leaders, finance, and anyone who’s made this decision recently: What’s your split between upskilling, outsourcing, and new hires? What surprised you about the trade-offs? And for those who tried outsourcing — did the knowledge silo problem kill you, or did you find ways to manage it?

[eng_director_luis]

David, I’m going to make the strongest possible case for upskilling because I’ve lived it, measured it, and have the receipts.

The Experiment: QA to Full-Stack in 12 Months

Eighteen months ago, I had three QA engineers on my team who were sharp, deeply familiar with our product, and frankly underutilized. They were writing sophisticated test automation — essentially programming — but we were treating them as a separate tier. Meanwhile, I had three open full-stack positions that had been posted for four months with zero acceptable candidates.

So I made a bet. I proposed a structured 12-month upskilling program to convert those three QA engineers into full-stack developers. Here’s exactly what it cost and what happened:

The Investment:

• $15K per person in training resources (online courses, conference attendance, a part-time mentor from outside the company)
• Approximately 20% productivity reduction from each engineer for the first 6 months as they split time between their QA role and learning
• My own time: roughly 4 hours/week mentoring and reviewing their progress
• Total loaded cost: approximately $120K across all three engineers for the full program

The Timeline:

• Months 1-3: Foundations. They paired with senior devs on small features while maintaining their QA responsibilities. Output dropped, but they were contributing real code by month 2.
• Months 4-6: The inflection point. They started taking on independent features. Code quality was decent but required more review cycles than experienced devs. QA responsibilities transitioned to a new junior hire.
• Months 7-12: Full contributors. By month 9, two of the three were operating at the level of a mid-level developer. The third took the full 12 months but eventually got there.

The Result:

• Three engineers who know our codebase inside and out — not just the happy path, but every edge case they’d spent years testing.
• Retention: all three are still on the team 18 months later. One has told me directly that the investment in their growth is why they stayed when a competitor offered 20% more.
• Time-to-productivity was weeks, not the 3-6 months we’d expect from an external hire.

Why Outsourcing Scares Me

I’ve also tried the outsourcing path at a previous company, and the knowledge silo problem David mentioned is real and severe. We brought in a team of 4 contractors to build a microservice. They delivered it on time, technically competent. Then the contract ended.

Six months later, when we needed to modify that service, nobody on the internal team understood it. The documentation was thin. The architectural decisions were made with different assumptions than our other services. We essentially had to reverse-engineer our own system. The cost of that rework exceeded what we’d have spent hiring one senior engineer and waiting the extra months.

Outsourcing doesn’t create knowledge — it rents it. And when you stop paying rent, the knowledge evaporates.

The Framework I’d Propose

I strongly agree with David that not all work is equally strategic, but I’d push the boundary further toward in-house than most leaders are comfortable with:

• Core and adjacent systems: In-house only. Upskill aggressively for these.
• Infrastructure and DevOps tooling: This is where I’d consider outsourcing, but only with strict handoff requirements — documentation reviews, knowledge transfer sessions, paired implementation with an in-house engineer.
• Throwaway prototypes: Fine for contractors, but be honest that it’s throwaway. Don’t let prototype code become production code just because it “works.”

The talent shortage is real. The answer isn’t to chase scarce external talent harder. It’s to grow the talent you already have. Those engineers already chose your company once. Give them a reason to keep choosing it.

[finance_carlos]

Alright, let me bring the spreadsheet perspective to this conversation. I’ve modeled upskill vs. outsource vs. hire for three different companies now, and the numbers tell a more nuanced story than “just upskill” or “just outsource.”

Running the Numbers: A Side-by-Side Comparison

Let me use a concrete scenario: you need the equivalent of 5 mid-senior full-stack engineers for 12 months. Here’s how the three approaches compare financially:

Option A: Hire Externally

• Recruiting costs: $25K-$40K per hire (recruiter fees, job postings, interview time)
• Salary + benefits: $180K-$220K per engineer fully loaded
• Time to fill: 3-6 months in the current market (DAVRON data confirms this)
• Time to productivity: Additional 3-6 months for onboarding
• 12-month loaded cost for 5 engineers: ~$1.1M-$1.3M
• Effective productive months in year one: 3-6 months per engineer
• Risk: 20-30% chance of a bad hire (per SHRM data), which compounds costs dramatically

Option B: Outsource (Nearshore)

• Agency/contractor rate: $80-$120/hour for mid-senior talent (nearshore LatAm rates)
• 12-month cost for 5 engineers: ~$800K-$1.2M
• Time to productive: 2-4 weeks (major advantage)
• Hidden costs I always flag:
  • Internal engineer time spent on context transfer: ~15% productivity tax on your existing senior team
  • Communication overhead: estimate 5-10 hours/week across the team in sync meetings, Slack threads, and documentation that wouldn’t otherwise exist
  • Knowledge loss at contract end: hard to quantify, but Luis’s story about reverse-engineering your own system is typical. Budget 2-3 months of internal engineering time for knowledge recovery.
• Adjusted 12-month cost: ~$1.0M-$1.5M when you include the hidden costs
• IP risk: Real but manageable with proper contracts. Still, it’s a line item your legal team will flag.

Option C: Upskill Internal Team

• Training budget: $10K-$20K per engineer
• Productivity dip: ~20% for 6 months (Luis’s data aligns with what I’ve seen)
• Opportunity cost of reduced output: This is the big one. If each engineer generates $50K/month in feature value, a 20% dip across 5 engineers for 6 months = $300K in deferred value.
• Total investment: ~$350K-$400K
• Long-term savings: No recruiting costs, higher retention (lower turnover costs), compounding productivity gains as engineers become more versatile
• Risk: Some engineers may not successfully transition. Budget for a ~70% success rate.

The Uncomfortable Truth

Here’s what the numbers actually show: upskilling is the cheapest option on paper, but it has the highest opportunity cost. Those engineers aren’t shipping features while they’re learning. For a company with aggressive growth targets, that deferred revenue can be existential.

Outsourcing looks cheap on the surface but gets expensive when you honestly account for the coordination tax and knowledge loss. The companies I’ve seen do outsourcing well are the ones that treat the coordination cost as a real budget line item, not an afterthought.

External hiring is the most expensive per-unit option but gives you the most flexibility and potential upside — if you hire well. That’s a big “if” given the data Keisha shared in the other thread about bad hire rates.

My Recommendation to CFOs

Don’t optimize for the cheapest option. Optimize for the option with the most predictable cost. In my experience:

• Upskilling costs are highly predictable once you’ve done it once
• Outsourcing costs are moderately predictable but have fat-tail risks (the contract that goes sideways, the knowledge loss that’s worse than expected)
• External hiring costs are the least predictable because one bad hire can blow up your entire budget model

If I’m advising a CFO, I say: upskill as your base strategy, outsource tactically for well-scoped projects, and only hire externally when you’ve exhausted the first two options. The math supports this ordering in most scenarios I’ve modeled.

[vp_eng_keisha]

Luis and Carlos, both excellent posts. I want to synthesize what I’m hearing and add the framework my team actually uses, because I think the answer is — as with most things in engineering leadership — “it depends, but here’s how to decide.”

The Answer Is “Both, Strategically”

I’ve been on both sides of this debate. I’ve championed upskilling programs that transformed teams, and I’ve managed outsourced engagements that delivered real value. The companies that get this wrong are the ones that pick a single strategy and apply it uniformly. Not all engineering work is equally strategic, and your talent approach should reflect that.

Here’s the framework we use on my team. We call it the “Core / Context / Commodity” model:

Core Work (In-House Only, Upskill Aggressively)

This is your competitive advantage — the domain-specific logic, the proprietary algorithms, the customer-facing features that differentiate you in the market. This work requires deep understanding of your business, your customers, and your technical architecture.

Our rule: Core work is never outsourced. Period. If we don’t have the skills in-house, we upskill. If upskilling will take too long, we slow down the roadmap rather than hand our competitive advantage to a contractor.

Examples on my team: recommendation engine, billing logic, data pipeline that feeds our ML models.

Context Work (Hybrid — In-House Lead, Outsource Execution)

This is work that’s important but not differentiating. Internal tooling, CI/CD improvements, migration projects, integration with third-party services. It requires technical competence but not deep domain knowledge.

Our rule: An in-house engineer owns the architecture and reviews all code. Contractors or outsourced teams do the implementation. This gives you speed without creating the knowledge silo problem Luis described, because the in-house engineer maintains the mental model.

Examples: migrating from one cloud provider to another, building internal admin dashboards, implementing standard API integrations.

Commodity Work (Outsource Freely)

This is well-understood, well-documented work where the requirements are clear and the interfaces are standard. Static site builds, boilerplate CRUD apps, data entry tools, proof-of-concept prototypes.

Our rule: Outsource this aggressively. Don’t waste your senior engineers’ time on commodity work when they could be focused on core or context.

How We Decide in Practice

Every quarter, my engineering managers and I review the upcoming roadmap and categorize every major initiative into Core, Context, or Commodity. The categorization drives our staffing model:

• Core initiatives with skill gaps go into the upskilling pipeline. We identify which engineers are closest to the needed skills and build a training plan. Luis’s model of pairing with senior devs and gradual responsibility transfer is exactly what we do.
• Context initiatives get scoped for hybrid teams. We write detailed architectural docs and interface specs before engaging contractors.
• Commodity initiatives get outsourced with clear acceptance criteria and timelines.

The Results So Far

Over the past 18 months:

• We’ve upskilled 7 engineers into new specializations (cloud infrastructure, data engineering, ML ops)
• We’ve run 4 outsourced engagements for context/commodity work
• Our effective capacity increased by ~40% without adding headcount proportionally
• Retention is at 92%, which I attribute partly to engineers seeing genuine growth opportunities

Carlos’s point about optimizing for predictability over cheapness is the right lens. The Core/Context/Commodity framework gives you that predictability because you’re matching the risk profile of the work to the risk profile of the talent strategy.

One Last Thought

The talent shortage is real, and DAVRON’s data about 3 engineering jobs per qualified candidate isn’t going to improve anytime soon. But I think the companies that will win in 2026 aren’t the ones with the biggest recruiting budgets. They’re the ones that stop treating all engineering work the same and build a portfolio approach to talent that’s as sophisticated as their approach to technology.