teaching-systems-thinking

Problem Framing as Category Act

Also known as:

Recognising that naming and framing the problem is not just a communication choice but the primary act of category creation — whoever defines the problem governs the solution space.

Naming and framing the problem is not a communication choice but the primary act of category creation—whoever defines the problem governs the solution space.

[!NOTE] Confidence Rating: ★★★ (Established) This pattern draws on Rhetoric / Category Design.

Section 1: Context

Teaching systems thinking into organisations, movements, and institutions reveals a recurring stasis: groups spend enormous effort solving problems while the problem itself remains contested, unstable, or defined by the loudest voice in the room. In fragmented systems—corporate silos, multi-stakeholder governance, activist coalitions, product teams crossing disciplinary boundaries—the naming of what’s wrong happens implicitly, often inherited from whoever spoke first or held institutional authority.

The living ecosystem where this pattern emerges is one where energy leaks sideways. A manufacturing team and a design team may agree they have a “quality problem,” but one frames it as speed (throughput), the other as craftsmanship (integrity), and neither frame captures what customers actually experience. A government department names “housing shortage” while activists name “housing injustice”—same symptoms, radically different solution spaces opening. A product team inherits “user engagement is low” when the real category might be “our model breaks trust during onboarding.”

This pattern arises where systems have enough heterogeneity—enough different stakeholders, disciplines, or values—that the act of naming becomes visible. In homogeneous, tightly controlled systems, the problem frame stays hidden because everyone already shares it. The pattern matters most where vitality depends on releasing distributed intelligence: the system cannot flourish if the problem definition is imposed from above or allowed to drift unchallenged.

Section 2: Problem

The core conflict is Problem vs. Act.

The tension runs between two forces:

Problem as descriptive object: The problem is out there—a thing to be accurately represented. This stance assumes the frame is discovering reality. A learning system adopts this when it trusts that with better data, clearer metrics, more rigorous analysis, the “true” problem will emerge. The consequence: teams invest in more studies, more frameworks, more justification—seeking objectivity that never arrives.

Act as constitutive force: The frame creates the problem category and thus determines which solutions become visible or invisible. This stance recognises that language and category are performative—they don’t just describe, they bring forth. A learning system adopts this when it recognises that who names determines what can be solved. The consequence: problem framing becomes contested, political, and requires collective recognition.

When unresolved, the tension produces:

  • Pseudo-consensus: Teams agree on a problem frame without recognising they’ve encoded someone’s interests into the category. The problem stays unstable beneath the surface.
  • Solution theatre: Groups solve the named problem beautifully while the unnamed problem atrophies the system. Quality improves while customers leave. Efficiency rises while trust decays.
  • Ownership paralysis: If the problem isn’t collectively recognised as a naming act, no one feels responsible for whether the frame is wise. It’s just “how we see things.”
  • Autonomy collapse: Stakeholders with different lived experience of the problem feel unheard because their frame was never named, only excluded.

The keywords matter: recognising, not assuming. Naming, not discovering. The pattern asks: who performed this category act, and what became possible—and impossible—because of it?

Section 3: Solution

Therefore, make the problem frame itself a collective, named, revisable category act—treating the naming as the primary work, requiring explicit recognition and stewardship.

The shift this creates is profound: the problem frame becomes alive rather than fixed. Here’s the mechanism:

In living systems language, a category frame is like root structure. The roots you grow determine which nutrients the system can access, which toxins it repels, which neighbours it can symbiose with. A system with shallow roots (poorly recognised frames) is vulnerable: storms of new data, new stakeholders, new constraints can uproot it instantly. A system with contested roots (frame recognised by some, invisible to others) splits energy—some roots pulling toward one nutrient source, others toward another, the system weakened by internal conflict.

Problem Framing as Category Act treats naming as the primary cultivation work. Instead of rushing to solve, the practice asks: What category did we just create by naming this ‘a problem’? What did we include? What did we exclude? Whose lived experience does this frame carry? Whose does it silence?

Rhetorically, this draws on the classical insight that epideictic rhetoric—the rhetoric of recognition—precedes deliberative rhetoric (deciding what to do). You cannot deliberate wisely about a problem category you haven’t collectively recognised. The Stoics understood this: prohairesis (choice) depends on phantasia (what appears to be the case). Change what appears, and choice space transforms.

The pattern works by making the act visible. Once naming is recognised as category creation—as a choice with consequences—the system can:

  • Steward the frame: Treat it as a collective asset requiring tending, not a given.
  • Hold it lightly: Recognise it as one way of seeing, not the only way, creating permission to revise.
  • Distribute ownership: When naming becomes shared work, more stakeholders feel their voice shaped what the system sees.
  • Release autonomy: Each sub-system can recognise the frame and choose to adapt it locally while maintaining coherence.

This is vitality work—the system renews its health by keeping the foundational categories alive, contested, and responsive to what’s actually happening.

Section 4: Implementation

In corporate settings, begin with a framing audit. In your next project kickoff, pause after the problem is named and ask: Who in this room would name this problem differently? Document the alternative frames—genuinely, not as straw men. Then explicitly choose: Are we adopting one frame for now, or holding multiple frames in parallel? Make the choice visible in project charters. For instance, a logistics efficiency initiative might frame the problem as “delivery speed” (operations view), “driver safety” (safety view), or “last-mile economics” (finance view). Name all three. Then decide whether you’re optimising for one, trading them off, or seeking solutions that serve all three. That decision is the actual problem statement. Communicate it downward: “We named the problem this way, knowing we’re excluding that way. Here’s why, here’s what we’re watching for.”

In government and public service, the stakes are higher because the frame becomes policy. Before a public problem enters the solution phase, convene the stakeholders and run a category recognition session. Map who named this problem and when. A “homelessness crisis” carries different genealogy than “affordable housing shortage”—same people, different category, different solution space. Document the frame’s origins. Then ask: What would change in our response if we adopted the frame that most affected people actually use? This isn’t about being politically correct; it’s about epistemic access. People with lived experience of a problem often have cognitive access to it that distant analysts lack. For a welfare system redesign, the “dependency problem” frame (used by efficiency analysts) versus the “dignity problem” frame (used by service users) opens radically different design spaces. Make both frames explicit in your problem statement.

In activist and movement spaces, problem framing is already contested—use that as an asset, not a liability. Create a practice of frame articulation sessions before strategy work. What is the problem we’re naming? Is it “the system is broken” (reform frame) or “the system is working as designed” (abolition frame)? These aren’t trivial differences; they determine tactics, theory of change, and coalition composition. Name the frame. Agree on it or acknowledge the strategic split. For climate justice movements, the difference between framing the problem as “climate change” (technical) versus “climate apartheid” (justice) versus “imperial extraction” (systemic) shapes everything: which experts you invite, which solutions seem viable, which allies you attract. Make the frame choice deliberate.

In tech and product teams, apply frame archaeology to feature specs. When a product manager writes “users are disengaged,” pause and ask: Is the problem attention (engagement metrics), value (users don’t find what they need), trust (users don’t believe the product respects them), or friction (the interaction cost is high)? Each frame opens different solution spaces. A framing toward “trust” might lead to transparency features; a framing toward “friction” leads to UX optimisation; a framing toward “attention” leads to notification design. Run a frame workshop before implementation planning. Document which frame you’re choosing, which you’re excluding, and what risks that creates. Then instrument for the excluded frames—set alerts for signals you might miss because they’re outside your chosen category.

Across all contexts: Create a named, scheduled practice. Monthly or quarterly, revisit the problem frame itself. Is it still alive? Are we seeing symptoms it’s become brittle or invisible? Rotate who gets to propose frame revisions. Make it a governance act, not a soft conversation.

Section 5: Consequences

What flourishes:

This pattern releases distributed intelligence. When the problem frame is recognized as a collective act, stakeholders with different positions in the system contribute their perception of what’s actually happening. A quality problem framed only as “defect rate” misses what frontline workers see about design intent; framing it to include “design-manufacture mismatch” brings that intelligence in. Teams stop defending a frame and start tending it together.

Ownership deepens. When people recognise that their perspective shaped the problem category, they feel agency in the solution. This is not false empowerment—it’s structural. The frame is no longer something done to the system; it’s something the system does together.

Autonomy strengthens at scale. Sub-systems can adapt the problem frame locally—a regional branch recognises the company’s “growth problem” but locally names it as “retention problem” because their context is different. Both frames coexist; the local adaptation is visible and valid.

What risks emerge:

Frame rigidity: Once a problem is named collectively, it can calcify. The group becomes defensive about the frame they chose together, making revision harder, not easier. Watch for language that treats the frame as discovered fact: “The problem is…” instead of “We framed it as…” This is decay—the act has become invisible again.

Paralysis in naming: Some groups spend so long discussing the frame that they never reach solution. Naming is primary work, but it’s not infinite work. Set a bounded time for frame recognition; then commit to a frame and move forward. The frame can be revised, but decisiveness matters.

Stakeholder exhaustion: Continuous frame revision can feel like endless debate to people who want to solve. Communicate clearly: frame recognition happens in dedicated moments, not constantly. This is cultivation work—you don’t tend roots every minute.

Ownership without accountability: Collective naming can diffuse responsibility. “We all named it” becomes “no one’s responsible for whether it’s working.” Pair frame stewardship with clear ownership—someone owns the responsibility to watch whether the frame is staying alive and true.

Resilience risk: This pattern scores 3.0 on resilience—it sustains existing health but doesn’t generate new adaptive capacity on its own. If the system’s context changes rapidly, a well-stewarded frame can become a trap. Pair this with practices that actively scan for frame-breaking signals. If the problem category becomes untrue, the system needs permission to grieve the old frame and name a new one quickly.

Section 6: Known Uses

The rhetoric of defect vs. design flaw in manufacturing: In the 1960s–70s, Japanese manufacturers (particularly Toyota) made a category act that changed global practice. Instead of framing problems as “worker defects” (frame inherited from Taylorist tradition), they named the category as “system design flaws.” This single reframing—collective recognition that the problem was engineering, not labour—opened the entire kaizen practice. Defects stopped being something workers were blamed for; they became signals of system improvement opportunities. The frame act was political: it redistributed who got to speak about the problem (now engineers and workers together, not just quality inspectors). The practice worked precisely because the naming was visible and collectively recognised. When kaizen decayed in some organizations, it was when the frame became invisible again—people forgot they were naming a category and started treating “continuous improvement” as a mechanical process rather than an act of shared recognition.

Climate framings and policy response: The shift from “climate change” to “climate crisis” to “climate emergency” to “climate apartheid” represents competing category acts. Each frame carries a hidden theory of action. “Climate change” (neutral, scientific) frames the solution as technical innovation. “Climate crisis” (urgent, bounded) frames it as mobilisation. “Climate emergency” (declaration of state) opens emergency powers and fast-track policy. “Climate apartheid” (justice frame) opens a solution space where redistributing resources and power becomes primary. The UN’s shift in 2019–2021 to more urgent frames didn’t happen because the science changed—it happened because activists made the frame act visible and contested. Policy followed the frame recognition. Organisations that acknowledge they’re navigating between these frames (rather than defending one as “true”) maintain more adaptive capacity.

The “user experience” reframing in software: In the 1990s–2000s, the problem frame in software shifted from “system functionality” (engineering frame) to “user experience” (design frame). This wasn’t discovery; it was category creation. The same software built to the same specs now had different problems: not “does it compute right?” but “does it make sense to the person using it?” The frame act was institutional—it required elevating designers and user researchers to problem-naming power alongside engineers. Companies that made this frame act visible and kept it alive (treating UX as a governance role, not an afterthought) maintained design coherence. Companies that treated “user experience” as jargon while keeping engineers as the real problem-namers experienced the decay: UX recommendations were advisory, engineering drove the actual category, and the system atrophied in users’ hands.

Section 7: Cognitive Era

In an age of AI-generated insights and networked problem-sensing, this pattern becomes more critical and more dangerous.

Why more critical: AI systems (and the data-driven platforms that feed them) are exceptionally good at finding patterns in the named category but often invisible at recognising what’s been excluded from the category itself. A recommendation algorithm optimises beautifully within the “engagement” frame—but if engagement was named without consulting users about what they actually value, the system will perfect a category that doesn’t matter. AI amplifies the leverage of the original frame act. Bad naming becomes bad at scale, fast.

What shifts: Problem Framing as Category Act now requires explicit AI transparency about the frame. When a platform uses machine learning to identify “users at risk of churn,” the frame is hidden in the training data and the loss function. A practitioner using this pattern in a tech product context must demand: What category did we teach the model to recognise? Who named it? What’s excluded? This becomes non-negotiable governance work. Some forward-looking organisations are building “frame cards” for their AI systems—documenting the problem category the model was trained to recognise, the choices that created it, and the risks of that frame.

New leverage: Distributed intelligence networks can surface competing frames faster than before. Instead of waiting for a human to notice the alternative framing, sensors and edge systems can report the problem as they experience it locally. A manufacturing plant’s IoT data might signal “quality problem,” but a worker’s forum might name it as “design problem,” and a customer’s social media might name it as “trust problem.” The infrastructure to hear all three frames simultaneously now exists. Organisations that build the governance to make these competing frames visible and discussable—not to suppress the noise—will adapt faster.

New risk: Frame capture by algorithm. If problem identification becomes automated (anomaly detection systems flag “problems” in real-time data streams), the frame disappears into mathematical abstraction. The category “anomaly” is performatively powerful but opaque. Practitioners must insist on naming rituals: once the algorithm flags something, humans must still ask, “What problem category does this represent?” and make that choice visible.

Section 8: Vitality

Signs of life:

  • Frame revisability: In governance meetings or project retrospectives, you hear people saying, “We framed this as X, but we’re seeing signs it might be Y—should we revise?” The frame is treated as alive, not fixed. This is the pattern working.
  • Conflict about framing, not righteousness about frames: When stakeholders disagree about the problem, they argue about which frame captures reality better, not about who’s right and who’s wrong. The argument is epistemic, not moral. This means the frame is still open to evidence.
  • Documented frame origins: The problem statement includes a short note on who named it, when, and what alternative frames were considered. This creates memory and intentionality. New team members inherit the recognition, not just the label.
  • Cross-boundary frame adaptation: Sub-systems adopt the parent frame but explicitly adapt it for their context. “Headquarters named this a ‘growth problem,’ and we recognise that locally as a ‘retention problem’ because of our market.” The frame lives across boundaries, not imposed uniformly.

Signs of decay:

  • Frame invisibility: The problem is discussed as a given (“We have a X problem”) without anyone acknowledging that X was a choice. The naming act has become hidden. This signals the pattern is hollow—procedure without vitality.
  • Defensive framing: Stakeholders become protective of the problem frame, treating challenges to it as personal criticism or political attack. Frame revision becomes rare and painful. This signals the frame has become tribal identity, not a working tool.
  • **Solution