Breaking The Bottleneck - Episode 5c: Cure For Established Companies with High Tech - Finding the Hidden Bottlenecks in Your Systems

12 gen

This article is Part 5C of “Breaking the Bottleneck”, an 8-episode series on key person dependency risk and organizational resilience.

If you’re a tech-forward organization (100+ people) with strong tooling (Slack, Jira, Confluence, automations, data stacks) you may assume key person risk is already handled. And yet, when a specific person is unavailable, critical workflows stall.

That’s the high-tech paradox: bottlenecks don’t disappear. They get embedded. The key person isn’t visible in the org chart; they’re buried in the architecture, in integrations, in decision history, in permissions, and in the way work actually routes through systems.

This episode shows you how to audit for hidden Key Person Dependency, make architectural decisions visible, extract knowledge systematically, and redesign workflows so your technology becomes a multiplier, not a camouflage layer for single points of failure.

Previous episodes in this series:

Next episode: “The Three Levels of Organizational Resilience” is coming soon.

You have great technology. You have Slack, Jira, Confluence, Asana. You have APIs and integrations. You have AI tools and automation.

On paper, you should not have key person dependency. Knowledge should be documented. Processes should be clear. Workflows should be streamlined.

But when you actually try to work around one of your key people, things fall apart.

Here's why: your technology has crystallized the bottleneck inside it. The key person is hidden in your systems, not visible in your org chart.

The Hidden Bottleneck Problem

Let me give you examples of what this looks like:

The system integration hub person. Everyone else's work flows through this one person. They're the hub. They know how all the tools talk to each other. They know all the shortcuts. They know how to fix it when something breaks. When they're on vacation, integration is chaotic.
The "only person who knows this Jira setup" person. Your workflow in Jira is complex. Multiple teams. Multiple custom fields. Multiple automation rules. One person set it up. One person understands how it all works together. When they leave, everyone is confused.
The "knows the data pipeline" person. Your data flows from system A to system B to system C. There are transformations at each step. Exceptions that need handling. One person understands the whole flow. Everyone else understands their part.
The "knows the architecture decision history" person. Why did we choose this tech stack? Why did we reject that approach? What have we tried before? One person knows. They're the only one who can contextualize new decisions.
The "API gate keeper" person. To access certain APIs or make changes to the system, you need approval from this person. They know which systems depend on what. They're the single approval point. Everything queues up behind them.
The "communication hub" person. All information flows through this person. They're in every meeting. They know all the context. They know who needs to know what. Without them, communication falls apart.

In all of these cases, the technology should be handling this. But instead, a person has become embedded in the system. The technology didn't solve the problem; it just made the problem invisible..

How This Happens

You didn't do this on purpose. It happens gradually:

The system is complex. You have multiple tools, APIs, integrations, data flows. Someone needs to understand the whole thing.
That someone becomes the person who understands it. They're smart. They're curious. They dig into how things work. They become the expert.
Because they're the expert, decisions route through them. Someone needs to know if a change would break something? Ask the expert. Someone needs approval for an integration? Ask the expert.
Because decisions route through them, they become the gate keeper. Now they're not just the expert; they're the bottleneck. Nothing gets decided until they weigh in.
The organization adapts around them. People know to schedule time with them. People know they're the approval point. The system crystallizes around them.

And now you have a hidden key person dependency, embedded in your technology.

Cure Strategy #1: Audit Your Systems for Hidden Bottlenecks

You can't fix what you can't see.

Start with a systematic audit.

Ask these questions:

For every critical system or process:

Who is the person who would be missed if they left?
Who is the only person who fully understands this system?
Where does all communication about this area flow through?
Who has to approve changes?
Who knows all the integrations and dependencies?
What would break if this person took a week off?

Interview people about their dependencies:

"If you needed to access the API, who would you contact?"
"If something in the data pipeline broke, who would you go to?"
"Who decides which tools we use and why?"
"Who knows the history of why we made this technical decision?"

Look at your communication patterns:

Who is in the most meetings?
Whose calendar is most booked?
Whose Slack messages get the most responses?
Who is looped in on most decisions?
Who has 1-on-1s with most of the team?

From this audit, you'll identify your hidden bottlenecks. They're not hidden anymore.

Cure Strategy #2: Make Architectural Decisions Visible and Documented

Many hidden bottlenecks are rooted in undocumented architectural decisions.

Someone knows why you chose this tech stack. Someone knows why you rejected that approach. Someone knows what problems you tried to solve 3 years ago.

If that's stuck in one person's head, they become the gate keeper for future decisions.

Fix this by documenting architectural decisions.

Create "Architecture Decision Records" (ADRs) for every significant decision:

What was the problem we were trying to solve?
What options did we consider?
What did we choose and why?
What were the trade-offs?
What could change this decision?

Examples:

"Decision: Use microservices architecture instead of monolith. Rationale: Allows independent scaling. Trade-off: Increased operational complexity."
"Decision: Move from on-premise to AWS. Rationale: Reduced infrastructure costs. Trade-off: Dependency on cloud provider."
"Decision: Use PostgreSQL for primary data store. Rationale: Better for relational data. Trade-off: Not ideal for document storage."

Store these in a central location (Confluence, Wiki, or similar). Anyone can read them. Anyone can understand why decisions were made.

This does two things:

It reduces dependency on the one person who knew. Now everyone knows.
It empowers other people to make decisions. They understand the reasoning, so they can make future decisions aligned with it.

Cure Strategy #3: Implement Knowledge Extraction for Complex Systems

For really complex systems, use AI and automation to extract and document knowledge.

Approach:

Interview the expert: Record conversations where they explain how the system works. Use AI to transcribe and summarize.
Create a knowledge graph: AI tools can extract the connections. "System A connects to System B through this API. When System B fails, here's the impact on System C."
Generate documentation: From the knowledge graph, automatically generate documentation. Not perfect, but way better than nothing.
Have the expert review and refine: They correct errors, add context, fill gaps.
Make it searchable: Use AI to make the documentation easily searchable and queryable.

Tools for this:

Mindee, Encord, ForFirm: AI-powered document extraction and workflow automation
Document intelligence tools: Automatically extract data and connections from documents
Confluence AI: Generate documentation from meetings and conversations

The goal: turn the knowledge in one person's head into documented systems that the AI can help surface and explain.

Once it's extracted and documented, the dependency on the person goes down dramatically.

Cure Strategy #4: Redesign Workflows to Eliminate the Bottleneck

Sometimes the hidden bottleneck isn't a person; it's the workflow design that created the person bottleneck.

Example: Everything requires this person's approval because the approval process routes through them. But there's no reason it has to.

Redesign the workflow:

Instead of sequential approval (person A approves, then person B approves), make it parallel
Instead of centralized decision-making, distribute authority with clear guardrails
Instead of manual approvals, use automation for low-risk changes
Instead of one person knowing everything, create clear domains of responsibility

Real example:

Old workflow: Any API change requires the "architecture person" to approve. They're a bottleneck because everything queues behind them.
New workflow: For low-risk changes, teams can make them autonomously (guided by guardrails). For high-risk changes, it goes to a governance committee (not one person). For critical architecture changes, it goes to a broader review.

This distributes the decision-making and eliminates the single bottleneck.

Cure Strategy #5: Create Distributed Ownership with Clear Authority Boundaries

Hidden bottlenecks often emerge when there's ambiguity about who owns what.

Create clear ownership structures:

Domain ownership: "Platform team owns the data infrastructure. They make decisions about databases, schemas, and data pipelines."
Authority boundaries: "Platform team can make changes autonomously if they don't affect other systems. If they do, they need approval from the integration team."
Escalation path: "If there's a disagreement, it escalates to the engineering lead."
Decision rights: "For performance changes, platform team decides. For architectural changes that affect multiple teams, it requires consensus."

When people know who decides what, they don't route everything through one person.

Cure Strategy #6: Implement Redundancy in Critical Technical Roles

For critical technical roles, implement N+1 redundancy.

This means:

For every critical system or decision, at least two people understand it
When someone is on vacation or sick, the other person can cover
When someone leaves, there's a successor ready

Specific practices:

Code review: Every critical piece of code is reviewed by at least two people
On-call rotation: Critical systems have on-call rotations with at least two people trained
Architecture reviews: Major architecture decisions involve multiple architects
Documentation ownership: At least two people maintain critical documentation
Decision authority: For critical decisions, at least two people have the authority

This sounds like inefficiency. It's not. It prevents huge losses when the person is unavailable.

Cure Strategy #7: Use Technology to Automate Decision-Making Where Possible

Some bottlenecks can be eliminated by automating the decision.

Examples:

Automated deployments: Instead of manual approval for every deployment, set up automated deployment pipelines with guardrails. Tests pass? Deploys automatically.
Automated alerts and escalations: Instead of one person monitoring everything, set up automated alerts. When something's wrong, it escalates automatically.
Automated access provisioning: Instead of one person granting access, set up automated provisioning based on rules.
Automated data quality checks: Instead of one person validating data, automated checks flag issues.

The goal: take decisions that can be made by rules/automation and automate them. This frees the person to focus on decisions that actually require human judgment.

Cure Strategy #8: Communicate Architecture and Technical Decisions Company-Wide

One reason hidden bottlenecks form: most people don't understand the architecture or why technical decisions were made.

This keeps them dependent on the expert. If they understood the reasoning, they could make decisions themselves.

Fix this with regular communication:

Monthly architecture talks: Someone from the technical team explains one architectural decision. Why we chose this? What's the impact? What are the trade-offs?
Quarterly technical deep-dives: Go deeper. Explain how different systems interact. Walk through a critical flow end-to-end.
Technical documentation that's accessible: Not just for experts. Written for an intermediate technical person. Anyone on the team can understand it.
Decision history visible: Not locked in one person's head. In a wiki. In ADRs. In a decision log.

When people understand the architecture and reasoning, the bottleneck opens up.

Cure Strategy #9: Create a "Resilience Review" Process

Once a quarter, audit your system for new hidden bottlenecks.

Ask:

Do we have any new single points of failure?
Are there new people who have become indispensable?
Are there new system integration hubs?
Are there new communication bottlenecks?
Are we creating new dependencies?

Design the audit:

Interview people about their dependencies
Review communication patterns
Review decision-making flows
Review system architecture

Fix issues as they emerge before they become entrenched.

The Technology Paradox

Here's the paradox of high-tech organizations: Technology should reduce key person dependency. But often, it increases it.

Why? Because as systems get more complex, the expertise required to navigate them increases. And when that expertise concentrates in one person, they become even more critical.

The solution is intentional system design that distributes knowledge and empowers people to make decisions without the expert.

This is not about eliminating the expert. It's about making the expert a multiplier instead of a bottleneck.

Key Takeaways

✓ Audit your systems for hidden bottlenecks - They're likely in your architecture, workflows, or communication patterns
✓ Document architectural decisions so the reasoning is captured, not stuck in one person's head
✓ Extract and document complex system knowledge using AI and automation tools
✓ Redesign workflows to eliminate bottlenecks - distribute approvals, automate decisions, clarify ownership
✓ Create clear domain ownership and authority boundaries so people know who decides what
✓ Implement N+1 redundancy in critical technical roles
✓ Automate decisions that can be automated - deploy pipelines, access provisioning, alerts
✓ Communicate architecture and technical reasoning company-wide so others understand the "why"
✓ Create a quarterly resilience review to catch new bottlenecks early

You have the technology. Now use it to eliminate hidden bottlenecks, not create them.

Ready to assess your company’s organizational health?

If you want help evaluating how well your company is currently dealing with key person dependency, I offer a free assessment for founders and leadership teams:

About Francesco Malmusi

I’m Francesco Malmusi, founder and C-level operator. I work with CEOs, founders, COOs, and tech leaders to eliminate bottlenecks that hide inside complex systems, where “process maturity” exists on paper, but dependency remains in integrations, architecture knowledge, approvals, and workflow design.

I help organizations audit their hidden single points of failure, operationalize knowledge capture, and redesign decision and delivery systems so execution doesn’t rely on a few people.

Francesco .