Every organization runs on dependencies — vendors, handoffs, integrations, approvals, and the one person who knows the workaround. Dependencies aren't the problem. Remy Fandango, founder of the Brightloom Group, argues the problem is that most of them are invisible until the moment they fail, and by then the real breakage happened somewhere upstream weeks earlier.
Remy doesn't just study organizational fragility, he maps it for a living. On this episode of The Focal Point he walks through what he calls the dependency visibility problem: the gap between what a company believes it controls and what it actually relies on. Listen in for how he surfaces those hidden threads before someone resigns, a vendor queue backs up, or a brittle integration takes the quarter with it.
Episode Video
About the Guest
Remy Fandango is the founder and managing partner of the Brightloom Group, a consultancy that specializes in operational resilience, dependency mapping, and the unglamorous work of making organizational risk legible to the people who can actually do something about it. Over twenty years he has run dependency reviews for utilities, hospital networks, payments companies, and public agencies — usually arriving after a failure nobody saw coming and staying to build the practice that would have caught it.
Before founding Brightloom he spent nine years in enterprise operations at Calderfield Systems and led continuity planning for the Marrowgate Utility Authority. He is the author of two books for executive teams — The Wiring Inside the Walls and Quiet Failures: Finding Fragility Before It Finds You — both aimed at giving leadership teams a practical method for auditing what they depend on rather than what they own.
Transcript
Map the work before it breaks
[Music] >> This is the Focal Point Podcast. An ongoing series where we deep dive into the meat of messy management. Whether it's technology, [Music] business, government, or entertainment, we chat about our experiences and perspectives in life [Music] and leadership. Join us as we learn about their latest insights and hopefully inspire you to have some of your own. >> [Music] >> Here's the scary part. Your organization may already be fragile and nothing on the dashboard is flashing red. >> That's the warning sign, right? There may be no warning sign. >> Exactly. The customer experience still works. The release still ships. The vendor still responds. The approval still comes through. The one person who knows the workaround is still around. >> Until they are not. >> Until they are not.
And by the time the dashboard turns red, the real failure already happened somewhere else. In a handoff, in a vendor queue, in a brittle integration, in someone's head. >> Right, because the dashboard only shows the smoke, not the wiring inside the walls. >> That's the whole point of this episode. Organizations rarely fail because they have dependencies. Dependencies are normal. >> [Music] >> They are how modern work gets done. The failure happens when those dependencies are invisible, misunderstood, overloaded, or treated as someone else's concern. >> So, this is not really a dependency problem. >> Not exactly. It is a visibility problem. >> That's a useful distinction. >> It's called the dependency visibility problem. >> [Music] >> The gap between what an organization thinks it controls and what it actually depends on.
>> [Music] >> And that gap can stay hidden for a long time. >> Especially during success. >> Wait, say more about that because most leaders expect fragility to show up when things are going badly. >> Right, but dependency problems often grow while things appear to be working. More customers, more products, more vendors, more tools, more teams, more environments. Everyone celebrates scale, but the operating map gets harder and harder to see. >> So growth adds leverage, but it also adds hidden load-bearing points. >> Exactly, and that is the first big idea. >> [Music] >> Nothing important stands alone. >> Which sounds obvious until you watch organizations behave as if it is false. >> Yes, teams are usually organized into functions.
Engineering owns engineering, procurement owns procurement, security owns security, operations owns operations, finance owns finance. >> And each one can look healthy in isolation. >> [Music] >> But the work does not move through the org chart, it moves through the system. >> That's the part leaders usually miss. >> A product launch might depend on a vendor contract, a security review, a data migration, a platform team, a release environment, customer support training, and one person who knows why the legacy system behaves strangely on Thursdays. >> Please tell me that is hypothetical. >> Emotionally hypothetical, operationally very real. >> Fair. >> The idea here uses a systems lens. >> [Music] >> Dependencies are not bad. In fact, dependencies are how modern work gets done.
Dependencies are the operating plan
>> [Music] >> You depend on vendors so you don't have to build everything yourself. You depend on platforms so teams can move faster. You depend on specialists because [Music] expertise matters. >> So the goal is not independence. >> Correct. [Music] Total independence would be expensive, slow, and probably impossible. The danger is pretending that leverage is independence. >> That line matters. >> It does because when a team doesn't know what it's hitched to, it can't understand its true risk, speed, cost, or resilience. >> So, a team may think we can deliver this in 6 weeks, but the real system says, "Only if legal reviews the vendor agreement, the platform team has capacity, the data team finishes the pipeline, and the staging environment doesn't collapse." >> Exactly. The plan on paper is 6 weeks.
The plan in the real world is the dependency chain. >> And the chain decides. >> That leads to the second idea. The system is the unit of performance. >> Not the department, not the team, not the tool. >> The system. >> This is where a lot of leadership reporting gets misleading because leaders inspect functions one at a time. >> Right. Engineering says they are on track, security says their queue is healthy, procurement says they are following the process, operations says their metrics are green, but the outcome still slips. >> Because the problem is not inside one box. It is between the boxes. >> Yes. Local excellence is not the same as system performance. >> That is painfully true. >> Think of it like a bridge. Every visible section may look stable from a distance.
The road surface looks fine, the guardrails are straight, traffic is moving, but stress fractures can be spreading underneath. >> And if you only inspect the parts people can see, you miss the structure carrying the load. >> Exactly. In organizations, those stress fractures are often handoffs, approvals, queues, hidden knowledge, vendor dependencies, or systems that became critical without anyone formally naming them as critical. >> So, the leadership question changes. >> It does. [Music] The question is not only is each function doing its job, the better question is, can the path across functions actually produce the promised outcome? >> Follow the work, not the org chart. >> That is the practical move. Dependencies become visible when leaders follow the work. >> From idea to value. >> From request to fulfillment.
>> From failure to recovery. >> Exactly. And once you trace those paths, you start finding the things that were quietly controlling performance all along. >> Which brings us back to growth. >> Yes, the third point is that growth hides the map. >> I like that phrase because growth usually feels like proof that the system works. >> And sometimes it is, but growth also changes the system. Early-stage organizations often run on shared context. Everyone knows who to ask. Everyone knows the weird work-around. Everyone knows which customer needs special handling. Everyone knows which system is fragile. >> The map lives in the room. >> Exactly. >> [Music] >> But then the organization scales. New teams join. New tools appear. Vendors multiply. More customers create more edge cases. The product expands. The architecture stretches.
When informal coordination becomes risk
>> And suddenly the map no longer fits in anyone's head. >> Right. What used to be lightweight coordination becomes [Music] informal risk. >> That's a great phrase, informal risk. >> It shows up everywhere. The spreadsheet that governs a critical decision. The one engineer who understands the deployment sequence. The vendor work-around nobody documented. >> [Music] >> The approval path everyone assumes someone else owns. >> And none of those look like emergencies. >> Not at first. They look like normal work. >> Until volume increases. >> Or until someone leaves. >> Or until the vendor misses a deadline. >> Or until two critical initiatives need the same scarce team at the same time. >> So the scaffold that helped the organization grow becomes a ceiling. >> Exactly.
The same informal coordination that created speed early [Music] can limit resilience later. It was useful when the system was small, it becomes dangerous when the system gets too large for memory-based operations. >> That's the part leaders usually miss. They see the old workaround as proof of adaptability. >> And sometimes it is adaptability, but repeated workarounds can also be a sign that the system has never really absorbed the lesson. >> Like pulling people out of the river every day and calling it a rescue culture. >> Instead of going upstream to ask why people keep falling in. >> Exactly. >> That connects to the next point. Familiar risk feels smaller than it is. >> This one is sneaky. >> Very sneaky. Organizations normalize the risks they live with every day. If a dependency has not failed recently, it feels stable.
If a manual workaround always saves the day, it feels acceptable. If only one team understands a system, it feels efficient. >> Until that team is unavailable. >> Right. The absence of recent failure starts to feel like evidence of safety. >> But it may just be luck. >> Or heroism. >> Or hidden overtime. >> Or a single person quietly preventing collapse. >> So, this is not really a metrics problem? >> No. Metrics help, but they often lag reality. A dashboard can show the fever, but not the disease. You may see cycle time increase, incident volume rise, customer response slow down, or delivery confidence drop, but those are symptoms. >> The disease may be an invisible dependency. >> Exactly. A vendor queue, brittle platform, a decision bottleneck, a critical person, a manual process that cannot handle scale.
>> And because it feels familiar, leaders underestimate it. >> Yes. The sharper question is, what is never failed but would be catastrophic if it did? >> [Music] >> That is uncomfortable. >> It should be, because many organizations only discover their true dependencies during disruption. >> A major outage. >> [Music] >> A vendor failure. >> A key employee leaving. >> A regulatory deadline. >> A sudden surge in dem. >> And then everyone says, "How did we not know this was critical?" >> But someone usually did know. >> Yes, the knowledge existed somewhere. It just was not visible to the organization as a system. >> That is an important distinction. The problem is not always ignorance. >> [Music] >> Sometimes the problem is that knowledge is trapped locally. >> Exactly.
Make constraints visible
One team knows, one person knows, one Slack thread knows, one spreadsheet knows. >> But the operating model doesn't know. >> And if the operating model doesn't know, leaders cannot make good trade-offs. >> Which leads to constraints. >> Yes, the next major point is that constraints decide the real plan. >> Not the road map? >> The road map matters, but constraints determine whether the road map is real. >> Give me examples. >> A constrained reviewer, a brittle integration, a manual approval, a vendor queue, an overloaded platform team, a scarce security specialist, a fragile test environment. >> So the organization may have 20 priorities, but one constraint sets the pace. >> Exactly. [Music] Most systems are not limited everywhere, they're limited somewhere important. >> [Music] >> That's the theory of constraints idea.
>> Right, and visibility changes how leaders respond. If you can see the constraint, you can protect it, elevate it, route around it, reduce demand on it, or redesign the system. >> But if you cannot see it? >> Then you keep optimizing everything except the thing that actually controls performance. >> That happens constantly. A team improves planning, another team adds reporting, another team tightens process, but the real bottleneck is still one overloaded review group or one unstable environment. >> And because the constraint is unnamed, people personalize the delay. They blame the team. They blame the process. They blame the tool. They escalate. [Music] They create side channels. >> But when the constraint is visible, it becomes a shared fact. >> Exactly.
Then the conversation changes from why are they slow to how do we manage this constraint as a system? >> That's a much healthier leadership conversation. >> And a much more useful one because the goal is not to shame the constraint team. Often the constraint team is constrained because they are important. >> They became load-bearing. >> Yes, and sometimes no one told them. >> That's such a common pattern. A platform team, a security team, a data team, an operations group. They start as support, then quietly become the bridge everyone drives across. >> And then leaders are surprised when the bridge needs maintenance. >> Or when traffic backs up for miles. >> Exactly. >> So, what do leaders actually do with this? >> The practical challenge is [Music] ask what your organization depends on without seeing it.
>> Which is a better question than where are we behind? >> Much better. Because where are we behind usually finds symptoms. What are we depending on without seeing starts to find structure. >> Let's make that concrete. >> First question. Which workflows depend on a single person? >> And not just officially, unofficially. >> Exactly. Who gets pulled into every incident? Who knows the deployment ritual? Who understands the vendor exception? Who can explain why the report numbers never match? >> Second question. >> [Music] >> Which promises rely on behavior we do not control? >> Vendors, partners, platforms, regulators, customers, external systems. >> Third, which platforms have become load-bearing without explicit ownership? >> That one is big. A tool starts as convenient, then it becomes necessary, then it becomes critical.
Classify strategic dependencies
But ownership, funding, support, and resilience never catch up. >> Fourth. Which decisions require information that lives outside the system of record? >> Yes, if the real answer lives in someone's notes, a private spreadsheet, or a Slack message, the organization has a visibility problem. >> Fifth. Where do we repeatedly use heroics and call it normal? >> That may be the most important [Music] one because heroics can hide broken systems for a long time. >> And they make the dashboard look better than the system really is. >> Exactly. >> [Music] >> The smoke detector stays quiet because someone is standing there with a fan. >> That image hurts. >> It should. >> So, the point is not to eliminate dependencies. >> No, that would eliminate leverage.
The point is to know which dependencies matter, which ones are fragile, which ones are strategic, and which ones are accidental. >> Strategic versus accidental is another useful distinction. >> Strategic dependencies are chosen. They are understood, owned, funded, and managed. Accidental dependencies just accumulate. [Music] They happened because a workaround became permanent, a tool became critical, or a person became the only map. >> So, resilience is not just having backups. >> No, resilience starts with visibility. You cannot strengthen what you cannot see. >> And you cannot prioritize what you have not mapped. >> Exactly. Resilient organizations map the work before it breaks. They trace the path from idea to value, from request to fulfillment, from failure to recovery. >> They do not wait for disruption to reveal the system.
>> Right, because disruption is an expensive teacher. >> And usually a public one. >> Very public. >> So, for leaders listening, the move is not to launch a giant dependency bureaucracy. >> Definitely not. The goal is not more process for its own sake. Start with critical flows. Follow the work. Ask where it waits, who it depends on, what information it needs, which systems it touches, and what would happen if one link failed. >> And look for the quiet constraints. >> Yes, the places where work slows down, but nobody wants to call it a bottleneck. The teams everyone needs, but nobody funds properly. The vendors everyone assumes will keep delivering. The people whose calendars reveal the real architecture of the organization. >> That's a great test. Look at calendars.
>> Calendars, queues, escalation paths, incident retrospectives, approval chains. They all reveal dependencies. >> And once you see them, you have choices. >> That's the hopeful part. Visibility doesn't magically solve the problem, but it gives leaders options. You can simplify. You can document. You can redistribute knowledge. You can invest in the constraint. You can reduce unnecessary dem. You can create redundancy [Music] where it matters. >> You can stop confusing luck with resilience. >> Exactly. >> So, let's bring it back to the opening. The scary part is not that your organization has dependencies. >> [Music] >> No, every organization does. >> The scary part is that the most important ones may be invisible. >> And by the time the dashboard turns red, the real failure may have already happened. >> In the wiring?
>> In the bridge? >> In the handoff? >> In the one person everyone depends on, but nobody names. >> So, map the work before it breaks. >> Because resilience is not built in the moment of disruption. >> It is built earlier. >> When the system is still quiet. >> When the smoke detector is not yet screaming. >> And when leaders still have choices. >> Thank you for tuning in to this episode of The Focal Point. Be sure to subscribe on your favorite platform. I'm your host, Filiberto De La Cruz. Until next time. God bless you and yours and everyone. [Music] >> [Music] [Music]
