Talent Shortages Will Double Hiring Timelines in 2026—Should We Invest in Upskilling Over Hiring?

General
1

We’ve had two senior engineering positions open for over four months now. Not because we’re being picky—because the market has fundamentally changed. The engineering talent shortage in 2026 isn’t about “not enough engineers.” It’s about finding the RIGHT engineers with the RIGHT specialization in the RIGHT location at the RIGHT time.

The Specialization Gap Is Real

When I started recruiting at Intel 15 years ago, we could post a “Senior Software Engineer” role and get 200 qualified applicants. Today, I’m looking for someone with fintech compliance experience, distributed systems expertise, and security clearance eligibility. The talent pool isn’t just small—it’s microscopic.

Deloitte estimates the U.S. manufacturing and tech sectors could face millions of unfilled jobs by 2030 without accelerated upskilling efforts. We’re already seeing this play out: companies are choosing to leave positions open longer rather than compromise on critical skills. The “hire fast” mentality has been replaced with “wait for the right fit.”

But here’s my dilemma: waiting isn’t a strategy when product roadmaps are measured in quarters, not years.

The Build vs. Buy Dilemma

I’m caught between two approaches:

External Hiring (Buy):

  • :white_check_mark: Solves immediate gaps
  • :white_check_mark: Brings fresh perspectives and proven expertise
  • :cross_mark: Fierce competition (everyone’s chasing the same 50 candidates)
  • :cross_mark: Extended timelines (4-6 months to close senior roles)
  • :cross_mark: Premium compensation expectations

Internal Upskilling (Build):

  • :white_check_mark: Long-term sustainable talent pipeline
  • :white_check_mark: Improved retention (people see growth paths)
  • :white_check_mark: Domain knowledge retention
  • :cross_mark: Requires significant mentorship capacity
  • :cross_mark: 6-12 month ramp time to full productivity
  • :cross_mark: Risk of attrition after investment

What We’re Actually Doing (Hybrid Approach)

I couldn’t choose, so we’re running both strategies in parallel:

External hiring focus: Critical specialized roles we can’t afford to wait on (our security architect hire, for example—we needed NIST framework expertise yesterday).

Internal upskilling focus: Building our leadership pipeline. We promoted two strong mid-level engineers to senior roles with explicit 6-month development plans:

  • Dedicated architecture mentorship from our principal engineers
  • $5K training budget each for certifications and conferences
  • Ownership of cross-team technical initiatives
  • Monthly 1:1s focused on gap analysis and growth

Early results are promising—both engineers are operating at senior level faster than we expected. But I’m constantly worried about mentorship burnout. My principal engineers are already stretched thin, and asking them to coach two promotees while shipping critical features feels unsustainable.

Questions for the Community

For those of you facing similar hiring challenges:

  1. What’s your build vs. buy ratio? Are you investing more in external hiring or internal development?

  2. How are you managing mentorship capacity? Do you have formal programs or is it ad-hoc?

  3. What’s actually working? I’d love to hear specific tactics that have shortened time-to-fill or accelerated internal development.

  4. How do you protect against “upskill and leave”? Are there retention strategies that make internal investment less risky?

The talent shortage is forcing us all to rethink talent strategy. I’m curious what’s working for others—because right now, I feel like we’re building the plane while flying it.

2

Luis, this resonates deeply. We faced the exact same challenge scaling our EdTech startup from 25 to 80+ engineers over the past 18 months. Here’s what I learned: external hiring simply cannot keep pace with hypergrowth.

The Market Reality Check

When you’re trying to hire 5-10 senior engineers per quarter, you’re competing with every other growth-stage company for the same limited pool. We had roles open for 6+ months because we kept losing candidates in final rounds to Big Tech counter-offers. The market moves too slowly for our velocity.

So we pivoted hard toward internal development.

Our Talent Pipeline Program

We stopped hiring exclusively for “senior” and started hiring promising mid-level engineers with clear growth potential. Then we invested heavily:

The 6-Month Leadership Track:

  • Dedicated executive coach (yes, for ICs aspiring to senior roles)
  • Real ownership of cross-functional initiatives (not side projects—actual roadmap items)
  • Monthly skip-level 1:1s with me to remove blockers and provide visibility
  • $7,500 professional development budget (conferences, certifications, courses)
  • Peer learning cohorts (groups of 4-6 going through the program together)

Results After Year 1:

  • 40% of our senior engineering roles filled internally
  • Retention improved from 82% to 91% (people see clear growth paths)
  • Time-to-fill for senior roles dropped from 5 months to 3 months (because we had internal candidates ready)

Addressing Your Attrition Concern

You mentioned “upskill and leave” risk. Our data shows the opposite: retention actually improved after launching the program. Here’s why:

  1. Visibility creates loyalty: When people see they can reach senior/staff/principal levels at your company, they stop job-hopping to find growth
  2. Investment signals value: Engineers talk about how much we invest in them—it’s a cultural differentiator
  3. Community effect: The cohort model creates peer bonds that make people less likely to leave

We’ve had 2 people leave after completing the program (out of 24 participants), and both stayed 18+ months post-graduation. That’s acceptable attrition.

The Hard Part: Executive Buy-In

I won’t sugarcoat it—getting leadership to approve a $200K annual program budget before seeing ROI was tough. CFO wanted guarantees I couldn’t give. What worked:

  • Framed it as “build or buy” cost comparison: External senior hires cost $180K+ in comp + $30K recruiting fees. Internal development costs $15K per person.
  • Piloted with 6 people before scaling
  • Tracked leading indicators (promotion readiness scores, 360 feedback) not just lagging ones (actual promotions)

@luis, your mentorship burnout concern is real. We solved it by:

  • Making mentorship an explicit part of senior/principal engineer job expectations (20% of their role)
  • Rotating mentors every quarter to prevent burnout
  • Recognizing mentorship in performance reviews and compensation

Happy to share more details if this approach sounds promising. The short answer to your question: Our build/buy ratio is now 70/30 (build/buy), and it’s working far better than the 20/80 we started with.

3

Keisha’s program is impressive, but I want to offer a counterpoint: it’s not always binary. At our scale (120 engineers across product, platform, and data teams), we run BOTH strategies in parallel with explicit decision criteria.

The Build vs. Buy Decision Matrix

Here’s the framework I use to decide whether to hire externally or develop internally:

Factor External Hire Internal Development
Time Criticality Launch deadline <3 months Ongoing capability building
Skill Complexity Requires 5+ years specialization Can teach in 6-12 months
Market Availability 10+ qualified candidates exist Scarce or impossible to hire
Strategic Value Commodity skill Competitive differentiator

When We Buy (External Hiring)

Critical specialized roles where time-to-competency is too long:

  • Security architect: We needed someone who’d implemented zero-trust architecture at scale. Teaching this from scratch would take 2+ years and the stakes were too high (compliance deadlines, customer contracts).

  • Data infrastructure lead: Hired someone from Netflix with experience handling 10TB+ daily ingestion. Our internal team was brilliant but hadn’t operated at that scale.

  • Compliance engineer (fintech): Regulatory expertise isn’t something you can learn from Coursera—you need battle scars from audits and regulatory filings.

For these roles, external hiring was faster AND lower risk than internal development.

When We Build (Internal Development)

Leadership pipeline and domain knowledge:

  • Engineering managers: We promote from within almost exclusively. External management hires often struggle with context and team dynamics.

  • Full-stack generalists: We hire mid-level engineers with strong fundamentals and upskill them on our specific stack. Turns out Rails + React can be taught faster than domain knowledge about our business.

  • Technical leads for core product areas: Our best technical leads are engineers who’ve been here 3+ years and understand every customer workflow and edge case.

Real Example: Security Strategy (Hybrid)

We hired the security architect externally, but upskilled our internal team on secure coding practices:

  • External hire designed the zero-trust architecture and compliance framework
  • Internal team (6 engineers) completed security certifications (CISSP prep courses, company-sponsored)
  • External architect ran weekly “security office hours” to teach the team
  • After 9 months, we had 1 external expert + 6 internal engineers with strong security foundations

Result: We didn’t need to hire 7 security engineers. We built security capability across the entire engineering org.

The Mentorship Capacity Problem

Luis, you mentioned mentorship burnout. Here’s what worked for us:

  1. Mentorship is a job expectation, not volunteer work: Senior and principal engineers have “technical leadership” in their job descriptions with specific mentorship deliverables (2 direct mentees, lead 1 learning initiative per quarter).

  2. We compensate for it: Mentorship impact is 25% of senior+ performance reviews. Strong mentors get bigger raises and faster promotions.

  3. Rotating mentorship models: 6-month mentor assignments, then rotate. Prevents burnout and exposes mentees to different perspectives.

The real challenge is getting your principals to see mentorship as leverage, not distraction. When they realize developing 2 senior engineers creates 2x their impact, the mindset shifts.

Bottom Line

Our build/buy ratio varies by function:

  • Product engineering: 60/40 (build/buy)
  • Platform/infrastructure: 40/60 (more external hires for specialized skills)
  • Data engineering: 30/70 (hire external for scale expertise)

The key is having explicit criteria so you’re not making emotional decisions in the heat of “we need this role filled NOW.”

4

I’m going to challenge the premise here: Are we hiring for the wrong things?

As a non-technical product leader watching these discussions, I keep seeing engineering teams optimize for technical depth when the actual bottlenecks are completely different.

The Bottleneck Isn’t Technical Skill

In my experience scaling product teams (and working with engineering teams at Google and Airbnb), the real constraints are:

  • Communication: Can this person explain complex technical trade-offs to non-technical stakeholders?
  • Judgment: Do they know when to cut scope vs. gold-plate solutions?
  • Cross-functional collaboration: Can they work with design, product, and data without needing a translator?
  • Learning velocity: How fast do they pick up new concepts, tools, and domains?

Yet job descriptions focus almost exclusively on years of experience with specific technologies.

What If We Hired Differently?

Hire for learning velocity and adaptability, not narrow specialization.

My best PM hire was a former high school teacher with zero tech background. Why did she succeed?

  • Fastest learner I’ve ever seen (went from “what’s an API?” to shipping integrations in 4 months)
  • Exceptional at breaking down complex concepts for diverse audiences
  • Natural curiosity and comfort with ambiguity
  • Strong emotional intelligence and stakeholder management

She outperformed PMs with 5+ years of B2B SaaS experience because she had the right meta-skills.

Applying This to Engineering

Luis, you’re looking for someone with “fintech compliance experience, distributed systems expertise, and security clearance eligibility.” Fair question:

How many of those requirements are actually must-haves vs. nice-to-haves?

Could you hire a strong generalist engineer with 5 years of solid backend experience and 6 months to ramp on fintech/compliance specifics? The market for that profile is 10x larger.

My hypothesis: Most “senior security engineer” roles don’t actually need 10 years of security experience. They need 5 years of strong engineering fundamentals + 6 months of security training + excellent judgment.

The Risk of Over-Indexing on Specialization

I’ve seen teams wait 6+ months for the “perfect candidate” with the exact niche skill stack. Meanwhile:

  • Product roadmap slips
  • Team morale suffers (everyone’s doing extra work to cover the gap)
  • You lose the market window

The opportunity cost of waiting for perfection is massive.

My Suggestion

Bias toward hiring for potential over pedigree:

  1. Identify the 2-3 truly non-negotiable skills (probably fundamentals like “strong backend engineering”)
  2. Make everything else trainable (fintech domain knowledge, specific frameworks, compliance details)
  3. Hire someone who’s 70% qualified with exceptional learning velocity
  4. Invest in closing the 30% gap with targeted training

You’ll fill roles faster, access a much larger talent pool, and likely build a more adaptable team.

Just my $0.02 from the product side. Curious if engineering leaders see this differently.

5

David’s comment just hit me hard because I’ve lived this exact problem on the design side.

Finding Design Systems Engineers Is Impossible

For the past year, I’ve been trying to hire a “senior design systems engineer.” The unicorn spec:

  • Expert in Figma (design tool knowledge)
  • Strong in React + TypeScript (frontend engineering)
  • Deep accessibility expertise (WCAG, ARIA, screen readers)
  • Design token architecture experience
  • Component API design skills

Spoiler: This person doesn’t exist. Or if they do, they’re already working at Figma, GitHub, or Stripe making $300K+.

My Pivot: Stop Looking for Unicorns

After 5 months with zero qualified applicants, I completely changed strategy:

Stopped hiring for complete skill sets. Started hiring for foundational skills + learning mindset.

I hired two people:

  1. Strong frontend engineer (React expert, zero design background) → taught her design systems thinking, Figma, design principles
  2. Designer with coding interest (knew HTML/CSS, wanted to learn React) → taught her component architecture, TypeScript basics

Both were “70% qualified” on paper. But both were:

  • Intensely curious about the craft
  • Comfortable with ambiguity and learning publicly
  • Collaborative and open to feedback
  • Had evidence of rapid skill acquisition in past roles

Skills Are More Teachable Than Mindset

Here’s what I learned from my failed startup: You can teach Figma, React, and accessibility patterns. You cannot teach curiosity, grit, or collaboration.

My biggest hiring mistake at the startup was waiting 6 months for someone with “5 years of B2B SaaS design experience.” We burned through runway while perfect candidates ghosted us for better-funded companies.

The opportunity cost was brutal: 6 months of product development time lost because I insisted on hiring perfection instead of potential.

Bias Toward Action: 70% Qualified Is Good Enough

Now my hiring philosophy:

If someone is 70% qualified with:

  • :white_check_mark: Strong foundational skills (for engineering: CS fundamentals; for design: visual craft + user research)
  • :white_check_mark: Proven learning velocity (evidence they’ve learned hard things before)
  • :white_check_mark: Cultural alignment (curiosity, collaboration, craft-focused)

I hire them and invest in closing the 30% gap.

Real results:

  • The frontend engineer I hired is now leading our design token migration (something she’d never done before)
  • The designer is shipping accessible React components and mentoring junior engineers on semantic HTML

Both became productive in ~3 months instead of the 6+ months I would’ve waited for “perfect” candidates.

Totally Agree with David

@product_david nailed it: Learning velocity beats current skill set.

The engineers and designers who’ve had the most impact on my teams are the ones who:

  • Ask great questions
  • Ship iteratively rather than waiting for perfection
  • Proactively fill their own knowledge gaps (don’t wait for formal training)
  • Adapt quickly when priorities shift

These traits matter way more than whether they’ve used our exact tech stack before.

Luis, I know you’re in fintech with compliance constraints—so maybe you genuinely need that 10-year security expert. But for most roles? I bet you could hire someone 70% qualified with strong fundamentals and upskill them faster than waiting 6 more months for the mythical perfect candidate.

Just my $0.02 from someone who learned this lesson the expensive way.