58-Day Time-to-Fill: Is Your Talent Strategy Built for 2026's Hiring Reality?

General
1

I have three critical engineering roles that have been open for over two months. Three. And I’m not alone—every engineering leader I talk to is facing the same challenge.

The data tells the uncomfortable truth: engineering roles now take an average of 58 days to fill, and 60% of organizations saw their time-to-hire increase in 2025. For specialized roles like data engineering or ML infrastructure? We’re looking at 60-90 days, sometimes longer. The market has fundamentally shifted, and our talent strategies need to catch up.

The Forced Choice: Build or Buy?

We’re all facing the same question: Should we invest in upskilling our existing teams, or should we source talent globally?

The Upskilling Case

When I think about upskilling, the benefits are clear:

  • Preserves institutional knowledge — your team already understands your architecture, your customers, your culture
  • Builds loyalty and retention — investing in people creates the kind of commitment you can’t buy
  • Aligns with long-term workforce planning — you’re not chasing the market; you’re building capabilities strategically

But here’s the reality check: it’s time-intensive. Mentorship capacity is limited. Most teams are already stretched trying to level up their existing junior hires. And when you have a critical capability gap right now, waiting 6-12 months for someone to skill up feels impossible.

The Global Sourcing Case

Global sourcing has its own compelling logic:

  • Expands your talent pool dramatically — suddenly you’re not competing with every Bay Area company for the same 50 candidates
  • Reduces time-to-hire — when you’re fishing in a bigger pond, you find the right person faster
  • Provides diverse skill sets and perspectives — different markets, different educational backgrounds, different problem-solving approaches

But it’s not without challenges: timezone coordination, cultural integration, and the risk of knowledge silos if you’re not intentional about connection and collaboration.

What’s Actually Working in 2026

I’m scaling our engineering org from 25 to 80+ engineers, and here’s what I’m learning: the either/or framing is wrong.

The companies winning the talent war didn’t wait until 2026 to figure this out. They started building nearshore relationships and distributed team capabilities in 2024-2025. They invested in the infrastructure—the processes, the tools, the culture—to make distributed work actually work.

My current approach:

  • Upskill for core platform and infrastructure roles where institutional knowledge is critical
  • Source globally for specialized capabilities where the market is tight and the learning curve is steep
  • Over-invest in onboarding and culture regardless of where someone sits

The biggest lesson? This isn’t a tactical hiring decision—it’s a strategic organizational design decision. It shapes your culture, your processes, your tooling, your budget.

So Where Are You?

I’m genuinely curious: What’s your 2026 talent strategy?

Are you doubling down on upskilling and accepting the slower pace? Are you building global teams and investing in distributed-first infrastructure? Are you doing both, and if so, how are you deciding which roles go which way?

And here’s the harder question: If you haven’t started building these capabilities yet, how long can you afford to wait?

Looking forward to hearing what’s working (and what’s not) for others navigating this same challenge.

2

This resonates deeply. We’re seeing the same timeline challenges across our org, and I’ve had to accept a hard truth: we can’t upskill our way out of specialized AI/ML talent gaps.

Here’s what I mean: for platform engineering, infrastructure, and core application development—upskilling works. These folks already understand our systems, our customers, our constraints. The learning curve is manageable. Institutional knowledge matters more than cutting-edge technique.

But for specialized capabilities? AI/ML engineering, advanced data engineering, security architecture? The market is moving too fast, and the expertise gap is too wide. We tried upskilling our backend engineers into ML roles. Six months later, they’re productive on basic feature work, but we still need senior ML engineers to architect the hard problems.

Our Hybrid Approach

We’ve settled into a framework with clear criteria:

Upskill for:

  • Platform and infrastructure roles where institutional knowledge is critical
  • Core product engineering where business context drives decision-making
  • Engineering management and leadership roles (culture carriers)

Global source for:

  • Specialized AI/ML and data science capabilities
  • Security and compliance engineering (niche + high demand)
  • Emerging tech adoption (blockchain, quantum, whatever’s next)

Practically, this means we’ve built “talent hubs” in Eastern Europe and Latin America for specialized skills. Time zones align enough for real collaboration. Cost advantage exists but isn’t the primary driver—access to talent pools with different educational backgrounds and problem-solving approaches is the real value.

The Challenge I’m Struggling With

Here’s where I don’t have the answer yet: maintaining engineering culture across distributed teams.

We can hire great engineers globally. We can onboard them on tools and systems. But how do you transfer the intangibles—how we make decisions, how we prioritize, how we give each other feedback, how we balance velocity and quality?

We’re experimenting with:

  • Quarterly all-hands in rotating locations
  • Engineering “cultural ambassadors” on each distributed team
  • Documented decision frameworks (ADRs, RFCs) to make the implicit explicit

But I’m curious: How are others balancing onboarding time investment vs. immediate delivery needs? When you hire a specialized engineer globally, how long before they’re truly productive vs. just completing tickets?

The 58-day time-to-fill is brutal. But the 90-day time-to-productivity might be the real metric we should be watching.

3

Interesting to see the different perspectives here. I want to offer a counterpoint: upskilling has been our primary strategy, and it’s paying off in ways that surprised us.

Let me add context: I lead engineering at a financial services company. We’re in a highly regulated environment where domain knowledge isn’t optional—it’s the difference between shipping features and creating compliance nightmares. A brilliant engineer from outside fintech still needs 6-9 months just to understand our regulatory constraints, payment flows, and risk frameworks.

Our Upskilling Success Story

Two years ago, we launched an internal “Engineering Academy” focused on mid-level → senior transitions. The program:

  • Pairs engineers with staff+ mentors for 6-month rotations
  • Includes structured learning paths (system design, architecture, leadership)
  • Real project ownership with mentorship safety net
  • Clear promotion criteria and timeline

Results:

  • 70% of our senior roles are now filled internally (vs. 35% three years ago)
  • Retention is up 23% among engineers who participate
  • Time-to-senior-productivity dropped from ~9 months to ~4 months

The financial investment is real—we’re talking mentorship time, training budget, reduced velocity during ramps. But the loyalty and retention ROI is undeniable. People who feel invested in stay. And they bring others with them.

Where We Still Source Globally

I’m not dogmatic about this. We absolutely source globally for niche technical capabilities where the learning curve is too steep:

  • Blockchain/crypto engineering (new product line, zero internal expertise)
  • Advanced analytics and ML (specialized skill + tool ecosystem)
  • Cloud security architecture (regulatory complexity + technical depth)

Our framework: “Build the foundation, buy the specialization.”

If it’s core to our competitive advantage and defensible through domain knowledge → upskill. If it’s a specialized technical capability where the market moves faster than we can train → source globally.

The Cultural Advantage

Here’s what I didn’t expect: the mentorship-first approach creates cultural loyalty that offsets the slower hiring timelines.

When senior engineers spend 20% of their time developing the next generation, they become culture carriers. They model the behaviors we want. They reinforce the “why” behind our technical decisions. New hires—whether internal promotions or external—get socialized faster because the cultural infrastructure is strong.

Michelle mentioned the challenge of maintaining culture in distributed teams. We’re seeing the opposite: upskilling creates the cultural foundation that makes distributed hiring sustainable.

A Question for the Group

Has anyone experimented with apprenticeship models for entry-level roles? We’re piloting a program where we hire bootcamp grads or career-switchers, pair them with senior mentors, and give them a 12-month structured learning path.

Early signs are promising: we’re accessing talent pools others ignore, and the apprentices are incredibly motivated. But I’m curious if others have data on retention and long-term productivity for apprentice → mid-level transitions.

@vp_eng_keisha - your point about this being a strategic org design decision really resonates. The upskill-first approach fundamentally shapes how we think about team structure, career ladders, and even our product roadmap (we prioritize features that develop team capabilities, not just user value).

4

Let me bring the finance lens to this, because I think there’s a critical piece missing from the conversation: the hidden costs everyone’s ignoring.

Both strategies have real financial implications beyond “cost per hire,” and most engineering leaders aren’t modeling this rigorously enough.

The True Cost of Upskilling

Direct costs:

  • Training programs and platform subscriptions
  • Conference attendance and certification programs
  • Mentorship opportunity cost (20% of senior engineer time = significant $$$)
  • Reduced productivity during learning curve (3-6 months at 50-70% efficiency)

Indirect costs:

  • Delayed feature delivery while team ramps
  • Potential quality issues during transition period
  • Risk of talent leaving after investment (especially without retention agreements)

When I run the numbers: break-even point is 18-24 months for upskilling investment. If your retention is <2 years, you’re subsidizing your competitors’ talent pipelines.

The True Cost of Global Sourcing

Direct costs:

  • Recruiting agency fees (typically 20-30% of first-year salary)
  • Legal, visa, and compliance costs (varies by country)
  • Relocation assistance or remote work infrastructure
  • Travel budget for quarterly onboarding/alignment

Indirect costs:

  • Coordination overhead for distributed teams (meeting scheduling, async communication)
  • Potential turnover from cultural mismatch
  • Knowledge transfer friction (timezone gaps = slower iteration)

The data Keisha cited is critical here: companies that started building nearshore capabilities in 2024-2025 now have a massive cost advantage. They’ve amortized the upfront infrastructure investment. Those starting today face 12-18 months before they see ROI.

The Strategic Question: What’s the IRR?

Here’s my framework for engineering leaders: Map every role to a “build vs. buy” matrix based on two dimensions:

  1. Strategic value: How core is this capability to competitive advantage?
  2. Market scarcity: How tight is the talent market for this skill?

High strategic value + high scarcity → Upskill and pay premium for external talent to accelerate
High strategic value + low scarcity → Upskill (build moat)
Low strategic value + high scarcity → Global source (access specialized talent)
Low strategic value + low scarcity → Hire locally (simplest path)

Luis’s “build the foundation, buy the specialization” framework aligns perfectly with this. Financial services domain knowledge = high strategic value. ML/blockchain = high scarcity.

The Uncomfortable Truth

Most engineering orgs aren’t tracking talent investment ROI the way they track product development ROI. If you can’t answer these questions, you’re making talent decisions on gut feel:

  • What’s your cost per productive engineer (including ramp time)?
  • What’s your average retention by role and hiring source?
  • What’s your mentorship capacity vs. demand?
  • What’s your time-to-productivity by hiring channel?

If you’re not modeling talent costs like product investments, you’re flying blind.

Michelle’s point about 90-day time-to-productivity is exactly right. We obsess over 58-day time-to-fill but ignore the 6-month onboarding drag on team velocity. The real metric is time-to-full-productivity × fully-loaded cost.

My prediction: companies that treat talent strategy as a financial modeling exercise—with clear ROI targets, break-even timelines, and risk-adjusted returns—will win this war. Everyone else is just reacting to pain.

5

Coming at this from the product side, and I think there’s a dimension we’re all dancing around: this isn’t just engineering’s problem.

The best talent strategies I’ve seen have product and engineering deeply aligned on who to hire and why. The worst disasters I’ve witnessed happened when engineering made hiring decisions in a vacuum.

The Mistake We Made

Two years ago, my company needed to scale fast. Engineering went hard on global sourcing—Eastern Europe, India, Latin America. We hired great engineers. But we didn’t involve product in the process, and we paid the price.

What happened:

  • Offshore team built features based on specs, not customer problems
  • They lacked context about why we were building something, so they couldn’t adapt when requirements shifted
  • Product-engineering iteration loops slowed to a crawl (timezone gaps + context gaps)
  • We shipped features users didn’t need because the team building them had never talked to a customer

The result: 6 months of work, 70% of it shelved or reworked. Fast hiring led to slow impact.

The Lesson: Context Transfer is the Hidden Cost

Luis and Carlos are both right about their frameworks, but I’d add a third dimension: product context.

  • Upskilling creates product-minded engineers who understand the “why” behind features
  • Global sourcing requires deliberate investment in product context transfer—and most teams underestimate this

When we hire globally now, product is involved from the interview stage. We assess:

  • Can they articulate why a feature matters, not just how to build it?
  • Do they ask questions about user behavior and business impact?
  • Can they challenge assumptions constructively?

If the answer is “just tell me the spec,” that’s a red flag—regardless of technical chops.

The Product-Engineering Alignment Strategy

Here’s what works for us now:

For upskilling:

  • Include product in the “Engineering Academy” curriculum (customer empathy, business model, metrics)
  • Rotate engineers through product discovery work (user interviews, data analysis)
  • Make “product thinking” a promotion criterion, not just technical depth

For global sourcing:

  • Product team participates in interviews to assess product mindset
  • First 30 days include customer calls, data deep-dives, competitive analysis
  • Pair new hires with product managers, not just senior engineers
  • Over-invest in documentation of why, not just what

The Real Metric: Time-to-Impact

Michelle mentioned 90-day time-to-productivity. I’d go further: measure time-to-impact, not time-to-first-PR.

  • How long before this engineer ships a feature that moves a business metric?
  • How long before they can independently identify and solve customer problems?
  • How long before they’re contributing to product strategy, not just executing specs?

Speed to hire ≠ speed to impact. An upskilled engineer with deep product context might ship slower initially but deliver higher-quality, better-aligned work. A globally-sourced specialist might close tickets fast but miss the strategic mark.

My Take

I don’t think it’s “upskill vs. global source.” It’s “How do we build teams that understand our customers, our business, and our technical constraints—regardless of where they sit?”

The companies that win treat talent strategy as a product-engineering partnership, not an engineering ops problem. Product defines what success looks like (business outcomes, customer impact). Engineering defines how to build the team to get there.

Carlos is spot-on about modeling ROI. But the ROI calculation should include product-market fit of the team itself—are we hiring people who can build the right things, not just build things right?

@vp_eng_keisha - curious how product is involved in your scaling process. Are they helping define the talent strategy or just receiving the output?