What does a brittle strategic or operational dependency look like? It looks like one load-bearing link -- one vendor, one analyst, one manual spreadsheet, one reviewer -- holding up an entire plan or control, so that removing that single link would collapse the whole thing.
The shape: a chain with one weak link
This single-point-of-failure shape recurs across the profile's operational and strategic examples: a plan that depends on one vendor has a hidden breaking point, and a compliance control that depends on one analyst and a manual spreadsheet has the same shape. A chain-with-one-weak-link visual makes the abstract idea instantly legible without needing technical jargon, and it directly supports the diagnose-then-fix pattern -- add a second link, reviewer, or vendor.
A launch plan depends on one vendor delivering a custom part with no backup supplier -- if that vendor fails, the plan may collapse. This is a clearer example of brittleness than an unpopular coffee machine or a rescheduled meeting: it's about the dependency structure, not a surface-level annoyance.
A compliance control requires one senior analyst to manually update a spreadsheet every Friday -- the precise risk is the combination of single-person dependency and a manual tool, not the analyst's seniority and not that the task repeats weekly.
The common mistake: misdiagnosing what the actual dependency is
The mistake is misdiagnosing the fix -- attributing the risk to the analyst's seniority instead of the single-person, manual-tool dependency. The real remedy is a backup reviewer and a less manual process, not replacing the analyst. A related mistake is calling the weekly repetition itself the problem ("volatile because it happens every Friday") -- repetition is not fluctuation, and it's not the dependency either.
Want to learn "Brittle" in depth?
Lyra Practice teaches advanced non-native professionals the nuance of high-value expressions like this one, then has you practice using them in realistic work scenarios.
Start learning for free →Before proposing a fix, it helps to name the exact single link precisely: is it one person, one vendor, one tool, or some combination? The fix (a backup vendor, cross-training a second reviewer, replacing a manual step) follows directly from naming that link correctly.
Practice scenarios
Practice using brittle in situations like:
- spotting a single-vendor or single-analyst dependency behind a plan or control that looks fine day to day
- naming the exact link (person, vendor, or manual step) rather than a vague sense of risk
- proposing a backup vendor, reviewer, or process instead of a fix aimed at the wrong cause
Useful practice phrases:
- "This plan depends on one [vendor/analyst/reviewer] with no backup."
- "The risk isn't seniority or frequency -- it's the single-person, manual-tool dependency."
- "We should add a second [vendor/reviewer] so one link failing doesn't collapse the whole thing."