Unfilled engineering roles don't just slow you down. They compound.
A Series B company in Munich has six open engineering roles. Three have been open for four months. The CTO knows exactly what they need: two senior Python engineers and a React lead. The recruiter pipeline is active. The salary is competitive. And still, nothing.
This is not unusual. Across DACH in 2026, $1.27 billion was raised in Q1 alone. Companies are funded, product roadmaps are ambitious, and engineering backlogs are growing. But the engineering headcount that should follow funding typically lags by three to six months, if it catches up at all.
That lag is not just an inconvenience. It is a structural problem that gets more expensive the longer it persists.
An open role costs more than a salary
When a senior engineering role sits unfilled for three months, the salary budget is intact. But the cost is already accruing elsewhere.
Your existing engineers cover the gap. A backend team now carries tickets scoped for a larger team. The slowdown is not linear, it is multiplicative. According to the DORA research program, teams working at or above capacity show measurable drops in deployment frequency and change failure rate. Cognitive load drives mistakes. Mistakes drive unplanned work. Unplanned work crowds out new features.
There is also the coordination tax. A senior engineer who would have owned a module becomes a bottleneck for others. Architecture decisions that could have been distributed now queue up. Sprint velocity drops, and the engineering lead spends more time in tickets than in design.
Multiply this across three open roles for four months, and the true cost is not the missing salary. It is the roadmap features that did not ship, the technical debt taken on under pressure, and the engineers who considered leaving because the team felt stretched.
The false choice between hiring and outsourcing
Most CTOs frame this as a binary decision: hire in-house and wait, or bring in a contractor and accept the quality tradeoff.
Neither framing is quite right.
Traditional in-house hiring in Berlin and Munich takes four to six months for a senior role when you include sourcing, pipeline management, multiple interview rounds, offer negotiation, and notice period. For companies that raised nine months ago and are already behind on their roadmap, that timeline is not compatible with momentum.
Contractor and project-based outsourcing has a different problem. You get speed, but the developer is optimized for delivery on a scoped project, not integration into your engineering culture. They are in your codebase but not your standups. When the engagement ends, the context leaves with them.
The question is not "hire or outsource." It is: how do you get an engineer who thinks and behaves like a member of this team, without the four-month lag?
A framework for the build-in-house vs. augment decision
Not every role should be augmented. Some capabilities are core to your product and should stay in-house. Others are capacity constraints on known problems with known stacks. Those are the ones worth augmenting.
Consider two categories:
Core capabilities require deep context about your product direction, customer architecture, and long-term technical decisions. Principal engineers, tech leads, and architects who set direction typically belong here. These are worth the four-to-six month in-house hiring cycle.
Execution capacity is everything else. A senior React engineer implementing a component library against an existing design system. A Python engineer extending a Django API with known endpoints. A Node.js developer joining a team that already has architectural clarity. These roles can be filled faster, and the cost of delay is measurable in features not shipped.
The augment-first approach works when: the stack is defined, the team structure is stable, the problem is a capacity constraint rather than a direction problem, and the company can invest in a proper onboarding process to integrate the developer into daily workflows.
If any of those conditions is missing, fill the role in-house and accept the timeline.
The 3-week window
For execution-capacity roles on defined stacks, the practical timeline from "we need an engineer" to "engineer is in your standup" is three weeks, not three months.
The key is that hiring is decoupled from sourcing. Instead of starting a search from scratch when a role opens, the preparation happens before: building a pipeline of pre-screened engineers for specific stacks, with verified references and technical assessments already complete. When the role is defined, the match happens in days rather than weeks.
This requires the role to be defined clearly. Stack, team context, ticket scope, working hours, and communication expectations should be written down before the first candidate is considered. Vague briefs produce mismatched hires and reset the clock.
The onboarding investment is also non-negotiable. An embedded engineer who does not understand your PR review culture, your documentation standards, or your escalation paths will underperform regardless of technical ability. The fastest teams treat onboarding as a product: a checklist, a buddy, a defined week-one scope, and a first PR within five days.
What the best-run engineering teams have in common
The companies that manage engineering velocity well in DACH have one thing in common: they treat capacity planning as a continuous activity, not a reactive one.
They know three months in advance which roles will be needed and why. They plan hiring around the product roadmap, not around the moment a backlog becomes painful. When the need becomes urgent, they can act because the groundwork is done.
The teams that struggle decide to hire after the pain is already visible. By then, they have already absorbed months of reduced velocity, taken on technical debt under pressure, and stretched engineers who would rather be building.
We started with one client at a single embedded engineer. Over time, that grew to a complete cross-functional team, fully integrated into their engineering org. The foundation for that scale was not a fast first hire. It was a clear definition of what the team needed to build, and a commitment to onboarding each person as if they were a permanent team member.
That is the only model that works at speed.
Key Takeaways
- An unfilled senior engineering role does not cost one salary. It costs deployment frequency, sprint velocity, and roadmap throughput for the whole team.
- The in-house vs. outsource binary is the wrong frame. The question is: does this role require deep product context, or is it execution capacity on a defined stack?
- Execution-capacity roles on defined stacks can be filled in three weeks when the sourcing pipeline is built before the need arises.
- Onboarding is not optional. Integration into team culture determines time-to-contribution more than technical ability.
- The best-run engineering teams plan hiring three months ahead. The ones that struggle react.
SifrVentures builds dedicated engineering teams for tech companies. Based in Berlin. Learn how we work | Read more on our blog
Top comments (0)