The Hidden Cost of Moving Fast: Why We Couldn't Onboard Anyone

October 2024. A key engineer gives notice. Two years with us, built critical systems, now moving on. Standard story, right?

February 2025. Another one leaves. Same pattern. Three years. Built core infrastructure. Gone.

Here's what nobody tells you about moving fast: The real debt isn't the code. It's the knowledge that walks out the door with the people who wrote it.

And when you're the only person who worked with both of them (the only bridge between what they built and the new people trying to maintain it), you become a single point of failure you never signed up for.

Important context: Both engineers were incredibly talented and hardworking. This was their first professional job out of university. They did exactly what we asked them to do: move fast and ship features. We didn't have proper engineering leadership to guide them on documentation, knowledge sharing, or maintainable architecture. This isn't a story about individual failure. It's about systemic failure, a startup that prioritized shipping over sustainability, without experienced leadership to balance those tradeoffs.

This is the story of how technical debt became a people problem. And how I learned that onboarding time isn't just a metric. It's a warning signal that your entire system is about to collapse.

The Systems That Left With Their Creators

Let me introduce you to two systems I can barely explain:

System 1: Entity Resolution (The Solo Masterpiece)

One engineer built our entity resolution system. Fresh out of university, learning on the job, and incredibly dedicated. He poured 3-4 months of intense work into it, hard planning, nights and weekends to ship it fast.

The challenge he tackled was genuinely complex: Match companies across 10+ data sources. Same company, different names, different metadata. "Apple Inc.", "Apple Computer", "AAPL", "Apple (Cupertino)" - all the same entity. This is not a trivial problem, even for senior engineers.

What he built was impressive, especially for someone fresh out of university:

5,000+ lines of SQL and Python handling edge cases
Complex matching rules optimized for our specific data sources
Business logic that achieved 95%+ accuracy
A system that processed millions of records reliably

The solution worked brilliantly. The team loved it. He delivered exactly what we asked for under intense pressure, with no senior engineer to mentor him on documentation practices.

He did document the system. He wrote test cases. He followed the practices he'd learned. But we never taught him about granularity, how detailed documentation needs to be for knowledge transfer. Here's what we were missing:

Documentation granular enough to capture all the context and edge cases
Explanation of why certain approaches were chosen over alternatives
Architecture decision records showing the reasoning behind key choices
Any kind of framework, just raw Python and SQL solving the problem directly

When he moved on in October 2024, the entity resolution system was still running perfectly in production. But the deep contextual knowledge, the "why" behind decisions, the edge cases, the tradeoffs, lived primarily in his head. Without senior leadership to model advanced documentation practices, none of us knew what level of detail was needed for smooth knowledge transfer.

System 2: Data Pipelines (The Transformation Black Box)

Another engineer, also fresh from university, led our data transformation pipelines. Raw data → cleaned data → gold standard. Three stages. Dozens of transformations. Critical business logic. I worked alongside him on this, contributing to various parts of the system.

The origin story matters here: This started as his internship project. He built it using what he knew, pure Python with templating SQL on Airflow tasks. No one guided him on data engineering best practices. No one told him about proper data transformation frameworks like DBT, Dataform, or even structured orchestration patterns. He solved the problem with the tools he had, piece by piece, making it work.

Neither of us had a senior data engineer teaching us what "good" looked like. But he owned the full context of how everything fit together, the entire flow from end to end:

Which transformations happened in which order
Why certain data got filtered out
How edge cases were handled
What assumptions were baked into the logic

The code worked. Processed millions of records. But it was tribal knowledge incarnate.

The transformations were documented with comments that said what they did. We did what we'd learned in school: comment your code. But nobody had taught us about architectural documentation. The individual pieces were documented, but how they all fit together? The orchestration logic? The dependencies between transformations? The reasoning behind the order of operations? What happens when external data sources conflict?

We never established a culture of architectural documentation. We never had examples to follow. We never did code reviews that asked "Can someone else understand the full system?"

When he moved on in February 2025, the pipeline still runs perfectly. But even though I worked on it, he held the complete mental model of the entire system. When the team asks "Can we change how we handle X?" I have to spend time reconstructing context: "Let me spend a week figuring out if that's safe."

The Knowledge Trap (The Bridge Problem)

Here's the brutal part: I worked with both of them.

I was the senior full-stack engineer. I built our entire web platform in the first 8 months (frontend, backend, user interfaces). But I also assisted with the data systems. I paired on entity resolution and data pipelines. I fixed pipelines when they broke. I asked questions. I reviewed code.

But I was a senior full-stack consultant, not a data engineer. Data engineering wasn't my specialty. I didn't know the best practices for data architecture documentation. I didn't know what "good" looked like in data systems. We were a team without senior data engineering leadership, junior engineers learning data work, and a senior full-stack consultant helping where I could.

When they moved on to new opportunities (as they should, growth is good!), I became the person who "understood" these systems. Not because I built them. But because I was the last person standing who'd seen them evolve.

Suddenly, I was the bridge. Between:

Code written by people who'd moved on
New engineers trying to maintain it
Systems with documentation that didn't capture the full context

New engineers would join. Smart people. Experienced. And he'd ask me: "How does entity resolution work?"

My answer: "Let me show you the code... it's complicated."

His follow-up: "Why did he do it this way?"

My answer: "I think it was because... actually, I'm not 100% sure. Let me check."

This created a knowledge proxy problem. Someone with partial context teaching code they didn't write. Explaining decisions they didn't make. Maintaining systems they only partially understood.

This wasn't anyone's fault. It was a systemic gap: no senior data engineering leadership, no documentation culture, no knowledge transfer processes.

The Organizational Trap (When Context Doesn't Transfer)

Here's the systemic problem that emerged:

I was a consultant. Not an employee. Not a manager. Not a decision-maker.

But I had context. Years of it. I'd seen how these systems evolved, what decisions were made, what tradeoffs we accepted.

Meanwhile, the organization grew. New engineers joined. Smart people. Talented. They got promoted into decision-making roles. This is normal and good.

But here's what didn't happen: context transfer.

New decision-makers would make reasonable decisions based on what they knew:

"Let's hire someone to rebuild entity resolution" (Makes sense - the code is complex)
"Let's add new transformations to the pipeline" (The business needs it)
"Let's integrate a new data source" (Business value)

All good ideas. The problem wasn't the decisions. The problem was the missing context.

New decision-makers didn't know: Why certain approaches were tried and rejected. What assumptions were baked into the current system. Where the hidden complexity lived. What "simple changes" would actually break.

This wasn't anyone's fault. Nobody had documented this knowledge. We'd never built that muscle as an organization. The knowledge lived in my head and the heads of people who'd moved on.

So the pattern repeated: New feature gets greenlit by someone who doesn't know the debt → New engineer gets assigned → He gets stuck on undocumented complexity → I get pulled in to explain.

I became the bottleneck. Not because I wanted to be. But because organizational context and decision-making authority lived in different people.

The Onboarding Nightmare (Measured in Months, Not Days)

Let me show you what onboarding looked like:

Week 1: Optimism

New engineer joins
"Here's the codebase. Here's the entity resolution module."
He starts reading code
"This is... unconventional. Where's the architecture docs?"
Me: "The code is documented, but let me explain the bigger picture..."

Week 2-3: Confusion

Daily questions
"Why does this query join these three tables?"
"What's the significance of this magic number?"
"Is this a bug or intentional?"
Me: "I think the original author did that because... let me check the git history."

Week 4-6: Frustration

He tries to make a small change
It breaks something unexpected
Spends days debugging
Realizes he doesn't understand the dependencies
Me: "Yeah, that table is used by the matching logic in a non-obvious way."

Week 8+: Resignation (literally or figuratively)

Either he leaves ("This codebase is unmaintainable")
Or he gives up trying to understand and just pattern-matches ("I'll copy what's already there")

Onboarding time: 2-3 months before he could ship a meaningful change

What it should've been: 1-2 weeks

The Hidden Math (Quantifying the Debt)

Let me show you what this actually cost:

Onboarding overhead: New senior engineer salary ~€100K/year. Time to productivity: 3 months. Cost of unproductive time: €25K per hire. Turnover rate (people leave when they can't be productive): 50% within 6 months. Rehiring cost: €50K per role per year.

Knowledge bridge overhead: 20 hours/week of a senior engineer's time answering questions about systems with incomplete context. At €100/hour = €2K/week. Over 6 months: €52K.

Opportunity cost: Features we couldn't build because new people couldn't onboard. Bugs we couldn't fix because nobody understood the root cause. Technical improvements blocked because changes were too risky.

Total hidden debt from knowledge loss: ~€130K+ in 6 months

And that's just the money. The real cost is the organizational drag, talented people spending time on archaeology instead of innovation.

The Hidden Cost to Productivity

Here's what this knowledge gap actually meant in practice:

Engineers who love building spend their time doing archaeology instead. The work shifts from:

Creating new features → Explaining old code
Solving new problems → Debugging edge cases with incomplete context
Building systems → Reconstructing undocumented decisions
Moving forward → Being a human knowledge base for tribal knowledge

Creative work becomes archaeology. Engineers spend time excavating how things work instead of building what's next.

The structural problem compounds this: Context and authority live in different people. The consultant with historical context can't make architectural decisions. The decision-makers don't have the historical context. Nobody can say "Stop. We need to address this debt first."

This creates organizational gridlock where everyone is working hard, but the knowledge debt makes everything slower.

The Speed vs. Debt Tradeoff (What We Got Wrong)

Everyone talks about technical debt as "slowing down later to move fast now."

That's not the real cost.

The real cost: You lock out your future team.

When we asked these talented junior engineers to build systems fast:

We didn't allocate time for documentation
We didn't teach them to write architectural design docs
We didn't establish knowledge sharing rituals
We didn't show them how to make systems maintainable

They did exactly what we asked them to do: ship fast. They worked incredibly hard. They delivered impressive results.

But we didn't give them the tools, time, or guidance to make it sustainable. The knowledge was trapped in people's heads because we never built a culture of externalizing it. When they moved on to bigger opportunities, that knowledge went with them.

What leadership should've asked:

"Can someone else onboard to this system in 2 weeks?"
"If the author leaves tomorrow, can we still maintain this?"
"Is the knowledge explicit or implicit?"
"Are we giving our junior engineers the support they need to build sustainably?"

We didn't ask those questions. We asked: "Does it work? Can we ship it?"

The engineers answered the questions we asked. We should've asked better questions.

When to Move Fast, When to Build Right

I'm not saying never move fast. I'm saying know what you're trading off.

Move fast when: Validating ideas. Testing market fit. Prototyping. You're the only engineer (solo founder). The person who builds it will maintain it.

Slow down when: Building core infrastructure. Multiple people will maintain this. The original author might leave. You're about to hire more people. Onboarding someone new would take >1 week.

That last one is the key metric we missed: Onboarding time is your canary in the coal mine.

If it takes 3 months for a smart engineer to understand your system, you don't have technical debt. You have a knowledge transfer crisis.

You Can Still Move Fast (With Modern Tools)

Here's the pushback I hear: "Documentation takes time. We need to ship fast."

I get it. I felt the same way. But here's what's changed: AI tools make documentation nearly free now.

AI-powered tools like Cursor, GitHub Copilot, or other code assistants can:

Generate documentation from your code in seconds
Create architecture diagrams from your codebase
Write ADRs (Architecture Decision Records) while you explain your thinking
Draft onboarding guides based on your project structure
Document APIs automatically

What used to take hours now takes minutes. You can ship fast and document well.

The workflow that works:

Build your feature (move fast)
Ask your AI assistant: "Document this system for a new engineer"
Review and refine (5 minutes)
Ship with documentation

You don't have to choose between speed and maintainability anymore. The tools exist. Use them.

When our engineers built these systems, they didn't have these tools. And more importantly, they didn't have leadership teaching them that documentation mattered. If we'd had both, AI assistants and a culture that valued knowledge sharing, we wouldn't have had a knowledge crisis.

Documentation is no longer a speed tax. It's a force multiplier.

What I'm Doing Different (Building for Continuity)

For my next projects and teams I build, here's what I'll do differently:

The lesson isn't just "write better docs." It's building systems that can survive key people leaving. When two critical engineers left within months, it exposed how fragile our knowledge structure was.

1. Knowledge redundancy, not hero developers

Critical systems need at least two people who deeply understand them:

Author builds it
Reviewer learns it deeply enough to teach it
Regular knowledge sharing sessions
When one person leaves, continuity remains

The goal: No single person should be irreplaceable.

2. Onboarding time as a quality metric

Every major system must pass this test: "Can a new engineer ship a meaningful change within 1 week?"

If the answer is no, that's a red flag. Either:

The documentation is insufficient
The architecture is too complex
Knowledge transfer processes don't exist

3. Continuous knowledge transfer, not just documentation

Documentation alone isn't enough. Build transfer into daily work:

Pair programming on critical systems
Architecture Decision Records (ADRs) explaining the "why"
Regular knowledge sharing sessions
Code reviews that ask "Can someone else maintain this?"
Onboarding guides that actually get tested with new people

4. Plan for turnover

People will leave. That's normal. Build systems assuming:

Key engineers will move to new opportunities (usually 2-3 years)
Knowledge needs to transfer continuously, not just during offboarding
The team should celebrate departures, not fear them

If your system can't survive someone leaving, you don't have a documentation problem. You have an organizational design problem.

The Lesson (What I Wish We'd Known)

The real lesson isn't about documentation. It's about building systems that can survive people leaving.

Our engineers built amazing systems. Fast. Effective. Impressive. They were talented, hardworking, and did exactly what we asked.

But we set them up to build systems that only they could maintain. We didn't teach them differently. We didn't model differently. We didn't prioritize differently.

When two key engineers moved on within months of each other, the knowledge left with them. What remained was a knowledge gap that slowed down everyone who came after.

This is what happens when you don't have proper engineering leadership. Junior engineers can't be expected to know best practices they've never been taught. The organizational failure created the technical failure.

The hidden cost of moving fast isn't just slow velocity later. It's organizational fragility:

Knowledge locked in people's heads
Onboarding measured in months, not weeks
Single points of failure
System collapse when key people leave
Organizational gridlock

If you're moving fast right now, ask yourself:

"If two key engineers left within 3 months, would the team survive?"

If the answer is no, you're not moving fast. You're building a house of cards.

And when the wind blows (people leave for new opportunities), it will collapse.

A Note of Gratitude

I'm genuinely grateful for this experience.

As a consultant, I typically move between projects every few months. I build, I ship, I move on. I rarely see the long-term consequences of architectural decisions. I rarely experience the full lifecycle of a system, from inception to growth to knowledge crisis.

Working with this team for over three years opened my eyes to what real engineering means. Not just writing code that works today, but building systems that survive turnover. Not just shipping features, but creating organizational resilience. Not just solving technical problems, but understanding the human systems around the code.

These lessons, about knowledge transfer, about planning for people leaving, about building for continuity, are ones I never would have learned from short consulting engagements. I'm thankful to the team, to the engineers who built these systems, and to the organization for giving me the opportunity to see this full story unfold.

The best lessons often come from the hardest experiences. This was one of them.

If you want to chat about building sustainable systems, knowledge transfer, or engineering team dynamics, feel free to reach out. Book a time or email me at supawat@intelek.ai