What’s Slowing Your Engineering Organization Down

You ship your org chart

Engineering leaders often say: You ship your org chart.

It’s another way of describing Conway’s Law—the idea that system architecture tends to mirror organizational structure. But there’s another implication that gets discussed much less: you also ship the debt inside that orgnization chart. It’s the hidden cost of decisions made in org charts instead of code.

Every engineering leader understands technical debt. The shortcuts in code, the migrations that stalled, the tests that never got written. We have frameworks for it, we budget for it, and we talk about it in every planning cycle.

But there’s a twin that lives in the org chart, and it’s at least as dangerous. I call it organizational debt.

Organizational debt accumulates when the people side of an engineering organization evolves through expedience rather than design. It’s the structural compromises you make, reasonable in the moment, that quietly compound until they constrain everything you’re trying to do.

If technical debt is the mismatched LEGO pieces in your castle, organizational debt is something else entirely. It’s building that castle with a crew where only one person understands how the drawbridge works, half the team is on loan, and the blueprints exist only in someone’s head.

Why organizational debt matters now

In an era of doing more with less, with tighter headcounts, acquired teams to integrate, distributed workforces spanning multiple countries, organizational debt accumulates faster than ever. And unlike technical debt, there's no linter for it. No static analysis. No automated scan that tells you your team structure is fragile.

You feel organizational debt in slower delivery, in the meetings that shouldn't be necessary, in the single person everyone has to wait for, and in the integration that takes twice as long because nobody documented how the acquired system works.

It's the reason a reorg that looks clean on paper still doesn't fix velocity. You rearranged the boxes, but the underlying debt remained.

The categories of organizational debt

After years of managing engineering organizations through growth, contractions, acquisitions, and restructuring, I've seen five common forms of organizational debt:

• Single points of failure

• Team structure debt

• Vendor dependency debt

• Knowledge concentration

• Acquisition integration debt

They parallel technical debt categories, and like technical debt, they compound.

1. Single points of failure (SPOF) engineers

When a SPOF joins the circus, gets sick, burns out, or simply takes PTO, the team doesn't slow down—it stops.

This is the most common and most dangerous form of organizational debt.

A single point of failure (SPOF) engineer is someone who is the only person who can do a critical thing. They're the only one who can run the release process. The only one who understands the billing pipeline. The only one who knows how the legacy authentication system actually works.

These people are usually your best engineers. They're high performers. They're reliable. And that's exactly the problem—their competence masks the organizational fragility they represent.

I've seen this pattern repeatedly across engineering organizations. In many organizations, it's not hard to identify several engineers where a two-week absence would stall a critical function. Some of these SPOFs persist for years despite being identified, because the urgency of delivery always outweighs the investment in redundancy.

SPOF debt isn't the engineer's fault. It's a structural failure. When the same person keeps getting assigned to the critical path because they're the fastest, you're optimizing for today while borrowing against tomorrow.

The interest payment: When a SPOF joins the circus, gets sick, burns out, or simply takes PTO, the team doesn't slow down—it stops. Knowledge walks out the door. And you can't hire your way out of it quickly, because the knowledge was never transferred to begin with.

2. Team structure debt

Every time you say "we'll restructure later" or "let's not disrupt things right now," you're taking on structural debt. Sometimes that's the right call. But like all debt, it accrues interest.

Team structure debt accumulates when your org chart reflects historical decisions rather than current reality.

It shows up as teams that report to the wrong leader because of when they were hired, not what they do. A technology team distributed across four different cost centers with four different managers, none of whom own the technology strategy. A team that should be integrated with another group but isn't, because they came from different acquisitions and nobody has done the work of merging them.

Structure debt also shows up in role misalignment. A senior engineer playing the role of a manager but without the title, authority, or support. A manager who is also acting as an IC, splitting attention between

Every time you say "we'll restructure later" or "let's not disrupt things right now," you're taking on structural debt. Sometimes that's the right call. But like all debt, it accrues interest.

The interest payment: Unclear ownership, duplicated effort, decisions that take three meetings instead of one, and talented people leaving because that reporting structure doesn’t give them the growth path they need.

3. Contractor and vendor dependencies

You're paying a premium for capability you don't own. The knowledge stays with the vendor. If the contract ends, you inherit a system with no internal expertise.

Contractors and outsourced teams are a legitimate tool. But when they become structural rather than supplemental, you're accumulating organizational debt.

I've seen this pattern repeatedly: a contractor is brought in for a specific project, becomes essential to operations, and then the engagement becomes permanent-but-not-quite. Contractors often have limited incentive—or limited time—to fully transfer knowledge back into the organization. The organization has no plan to internalize the capability. Years pass.

The debt is especially severe when the contractor structure is unusual: When they operate outside your normal engineering practices, don't participate in your code reviews, aren't on your communication channels, or use different tools and workflows.

The interest payment: You're paying a premium for capability you don't own. The knowledge stays with the vendor. If the contract ends, you inherit a system with no internal expertise. And contractors are naturally aligned to the scope of their engagement, which may not always prioritize your long-term architecture.

4. Knowledge concentration

“I've seen teams where the onboarding time for a new engineer was measured in months because the only way to learn was to interrupt someone who already had the knowledge. This creates a silent tax on everyone's productivity.”

Knowledge concentration shows up when critical understanding of systems, processes, or business logic exists only in the minds of a small group.

This is related to SPOFs, but broader. Knowledge concentration debt occurs when critical understanding of systems, processes, or business logic exists only in the minds of a small group.

Documentation gaps are the most obvious symptom. But knowledge concentration also manifests as tribal knowledge about how customers actually use the product, unwritten rules about deployment sequences, or institutional memory about why a particular architectural decision was made five years ago.

I've seen teams where the onboarding time for a new engineer was measured in months, not because the technology was complex, but because the documentation didn't exist. The only way to learn was to interrupt someone who already had the knowledge. This creates a silent tax on everyone's productivity.

When you layer AI tools on top of this problem, it gets worse. AI coding assistants consume documentation and context to generate useful suggestions. If the knowledge isn't written down, your AI tools are operating with one hand tied behind their back.

The interest payment: Slower onboarding, constant interruptions, higher risk during transitions, and diminishing returns on tools that depend on documented knowledge.

5. Acquisition integration debt

In some cases, two years later, the acquired team is still operating as an island. Their systems aren't integrated. Their practices haven't aligned.

Every acquisition creates organizational debt. You inherit teams with different engineering practices, different tools, different cultures, and often minimal documentation.

The pressure after an acquisition is to keep the acquired team running and productive. Don't disrupt. Don't reorganize too quickly. Let them keep their processes for now.

This is often the right short-term call. But "for now" has a way of becoming "forever." In some cases, two years later, the acquired team is still operating as an island. Their systems aren't integrated. Their practices haven't aligned. Their engineers can begin to feel disconnected from the broader organization or, worse, like they're in a completely separate company.

The interest payment: Duplicated infrastructure, inconsistent quality standards, integration projects that balloon in scope because nobody planned for the cultural and process alignment work, and attrition from engineers who feel disconnected from the broader organization.

Why organization debt is harder to manage

Technical debt has one significant advantage: the code is the artifact. You can read it, measure it, and at least attempt to quantify it.

Organizational debt is harder because the artifacts are people, relationships, and tacit knowledge rather than code. You can't run a scan on your org chart and get a debt score.

But you can assess it. Here are the signals I watch for:

• Vacation test: If a specific person can't take two weeks off without a critical function being at risk, you have SPOF debt.

• Meeting load: If cross-team decisions require more than two meetings, you likely have structure debt.

• Onboarding time: Lots of teams try to have new members ship on the first day. Onboarding to other teams might take longer, but if it takes a new engineer more than 30 days to make meaningful contributions, you have knowledge debt.

• Contractor tenure: If a contractor has been in the same role for more than a year, you may be building vendor dependency debt.

• Acquisition timeline: If an acquired team hasn't been integrated into your practices within 12-18 months, integration debt is compounding

Paying down the debt

Like technical debt, not all organizational debt needs to be addressed immediately. Some of it is acceptable. The key is making it visible and intentional.

Name it

The first step is calling it what it is. When you identify a SPOF, document it. When you see structural misalignment, note it. Organizational debt thrives in the dark. Making it explicit makes it manageable.

Budget for it

Just as you allocate capacity for technical debt reduction, allocate time for organizational debt. Cross-training a SPOF engineer takes real investment—pairing sessions, documentation sprints, deliberate rotation. It doesn't happen unless you plan for it.

Make it part of your resilience planning

We treat platform resilience as a first-class concern. Server redundancy, disaster recovery, multi-region failover. Organizational resilience deserves the same treatment. Your people architecture should be as fault-tolerant as your infrastructure.

Resist the urgency trap

The reason organizational debt persists is that fixing it rarely feels urgent. The SPOF engineer is delivering. The contractor is keeping things running. The acquired team is shipping. Everything looks fine—until it doesn't. Paying down organizational debt is a proactive investment, and proactive investments are the first things to get cut when the quarter gets tight.

The parallel

Technical debt and organizational debt are not just analogous—they're interconnected. 

Technical debt often causes organizational debt. When a system is poorly documented, whoever understands it becomes a SPOF. When a migration stalls, the team structure built around the old system persists. When contractors are brought in to handle a backlog of technical debt, they become a dependency.

And organizational debt causes technical debt. When knowledge is concentrated, code reviews suffer. When team structures don't align with system boundaries, ownership gets muddy and quality degrades. When acquired teams aren't integrated, architectural standards diverge.

The most effective engineering leaders I know manage both simultaneously. They see the org chart and the architecture diagram as two views of the same system.

Join the conversation

If you look at your own organization, where is the technical debt concentrated?

Technical debt has become a widely understood concept. I think organizational debt deserves the same treatment. It's not a people problem — it's a systems problem that happens to involve people.

If you look at your own organization, where is the debt concentrated? Is it in key-person dependencies that have persisted for years? In team structures that reflect history rather than strategy? In vendor relationships that were supposed to be temporary?

I'd love to hear how you think about it. Which form of organizational debt have you seen most often?

Join the conversation on the original LinkedIn article.

Mathew Spolin leads global engineering at AppDirect, where managing organizational debt across multiple countries, acquisitions, and restructurings has been as critical as managing our technical debt. If this framework resonates, I'd love to hear your examples.