--- title: "Doctrine 13: Problem Solving Requires Finding the Real Deviation and the Relevant Change" description: "# *Why teams fix the wrong thing and how architects identify the signal hidden inside the noise* This guide explains why solving a problem is linked to being able to define the problem in the first place. This page is…" url: "https://anthonyveltri.com/guide/problem-solving-requires-finding-the-real-deviation-and-the-relevant-change/" updated: "2026-02-22" category: "Resilience & Operations" tags: - leadership - resilience --- # Doctrine 13: Problem Solving Requires Finding the Real Deviation and the Relevant Change # *Why teams fix the wrong thing and how architects identify the signal hidden inside the noise* This guide explains why solving a problem is linked to being able to define the problem in the first place. This page is a **Doctrine Guide**. It shows how to apply one principle from the [Doctrine](/doctrine/) in real systems and real constraints. Use it as a reference when you are making decisions, designing workflows, or repairing things that broke under pressure. --- # **Most problems are not problems. They are symptoms.** [![A line graph shows performance over time. At one point, actual performance drops below the standard of performance, creating a gap labeled "Gap to be restored by problem solving.](https://anthonyveltri.com/wp-content/uploads/2025/12/problem-solving-deviation-01-1024x572.jpg)](https://anthonyveltri.com/wp-content/uploads/2025/12/problem-solving-deviation-01.jpg) The Reality Gap & The Deviation Gap. A problem is not just "something bad." It is a measurable divergence (Green Line) from an expected standard (Blue Line). If you cannot draw this gap, you do not have a problem statement. When teams encounter friction, they tend to: - fix the visible symptom - debate the surface behavior - respond to the immediate failure - treat noise as signal - try to optimize before understanding This is how organizations end up: - solving the wrong problem - escalating needlessly - creating rework - introducing new inconsistencies - burning time The architect’s job is to identify two things: **1. What is the real deviation?** **2. What is the relevant change?** Almost every real problem is a mismatch between those two. --- # **Lived Example: The feed that “broke” when the real problem was a timestamp drift** During an activation, a partner feed appeared to break: - polygons rendered incorrectly - features disappeared - some features doubled - analysts sounded the alarm - leadership asked for immediate fixes Everyone focused on geometry. That was the symptom. The real deviation was a silent timestamp drift that: - moved the time window forward - invalidated the last known good data - triggered a fallback mode incorrectly - created phantom gaps The relevant change was not geometry. It was the partner’s time source drifting by several minutes due to a misconfigured upstream server. Once we corrected the drift, all symptoms vanished. Problem solving begins with identifying the deviation. Then mapping it to the relevant change. --- # **Business Terms: How organizations solve the wrong problem** [![An infographic titled "Is this really a problem, or just work?" lists three points: 1. Off standard, 2. Cause unclear, and 3. It matters, each with icons and brief explanations; a note below stresses honest problem identification.](https://anthonyveltri.com/wp-content/uploads/2025/12/problem-is-it-a-problem-01-1024x572.jpg)](https://anthonyveltri.com/wp-content/uploads/2025/12/problem-is-it-a-problem-01.jpg) The Gatekeeper. Before investigating, ask three questions: Is it off standard? Is the cause unclear? Does it matter? If the answer to "Is the cause unclear?" is No, then it's a Decision, not a Problem. Organizations misdiagnose because: - they react to noise - they respond emotionally - they escalate quickly - they follow political pressure - they trust the first complaint - they do not verify assumptions - they confuse correlation with causation - they skip the deviation check This creates: - false fixes - unnecessary meetings - rework - blame cycles - slowdowns - decision drag Solving the wrong problem is worse than solving nothing. --- # **System Terms: Deviation and change as analytical primitives** In systems language: - **Deviation** is the measurable divergence from expected behavior. - **Change** is the event inside the system that explains the deviation. - **Signal** is the specific relationship between deviation and change. - **Noise** is everything else. Good problem solving requires: - identifying the deviation precisely - identifying the change accurately - testing the relationship - ignoring everything that does not matter Bad problem solving tries to fix every deviation without understanding the underlying change. --- # **Why Teams Miss the Real Deviation** [![A diagram shows a timeline split by "Deviation shows up." Left side ("Causality window") lists Changes A, B, C, D as possible causes; right side ("Background noise") lists Changes E, F, G as unrelated changes.](https://anthonyveltri.com/wp-content/uploads/2025/12/problem-solving-causality-deviations-03-1024x572.jpg)](https://anthonyveltri.com/wp-content/uploads/2025/12/problem-solving-causality-deviations-03.jpg) The Causality Window. The relevant change must happen before the deviation appears. Everything after the deviation is just scenery. Teams misinterpret deviation because: - alerts are noisy - monitoring is inconsistent - partners report symptoms poorly - metrics do not match intent - expectations differ - assumptions are wrong - the first theory becomes the dominant theory - small practical clues are ignored Most early assumptions are wrong. Architecture helps teams reject the first assumption faster. --- # **Why Teams Miss the Relevant Change** Teams fail to identify the relevant change because: - changes overlap - logs are noisy - deployments are staggered - partners alter behavior without warning - data formats drift - timestamps degrade - security tokens rotate - updates collide with activations - environmental conditions shift unpredictably The real change is often subtle. You must look for it with discipline. --- # **Why Deviations Multiply When Misdiagnosed** Misdiagnosis generates more problems: - fixes introduce new drift - workarounds increase complexity - teams override safeguards - partners adjust incorrectly - escalations pull in more stakeholders - a simple deviation becomes a full system disturbance Every incorrect fix becomes a new change. Every new change creates new deviations. Real problem solving stops the multiplication. --- # **How Architects Solve Problems Correctly** [![A flowchart showing a problem-solving cycle: Confirm the gap, Find the causality window, Test likely causes, Act and recheck, all revolving around restoring performance to standard. Text at bottom emphasizes disciplined curiosity.](https://anthonyveltri.com/wp-content/uploads/2025/12/problem-solving-resolution-04-1024x572.jpg)](https://anthonyveltri.com/wp-content/uploads/2025/12/problem-solving-resolution-04.jpg) The Resolution Loop. Disciplined problem-solving moves in a cycle: Confirm the Gap --> Find the Causality Window --> Test Likely Causes --> Act and Recheck. As with an OODA loop, interruptions of the cycle can be disorienting and costly. Architects approach problems with a clean four-step method: ### **1. Define the expected state** Without a baseline, you cannot identify deviation. ### **2. Identify the real deviation** Not the noisy symptom. The actual measurable divergence. ### **3. Identify the relevant change** What changed in the system that explains the deviation? Ignore all unrelated changes. ### **4. Map deviation to change** If the change explains the deviation, you have the problem. If not, keep searching. This approach removes emotion and politics from diagnosis. --- # **Business Example: The conflict that evaporated once the deviation was clarified** Two partner agencies blamed each other for a data quality issue. Both were wrong. The deviation was not: - missing attributes - incorrect geometry - stale data The deviation was: - inconsistent publishing cadence The relevant change: - a partner scheduled a new automated process that shifted their publishing window by two hours. Once identified: - nobody was at fault - no meeting was needed - no escalation was required The issue resolved immediately. The conflict evaporated. Deviation before blame. Change before solution. --- # **System Example: The ingest pipeline error that wasn’t an error** [![A flowchart guiding problem-solving: If something feels off, check performance against standards. If no, investigate the problem. If yes, determine if the cause is known. If yes, make a decision; if no, investigate further.](https://anthonyveltri.com/wp-content/uploads/2025/12/problem-solving-flow-chart-02-1024x572.jpg)](https://anthonyveltri.com/wp-content/uploads/2025/12/problem-solving-flow-chart-02.jpg) Problem vs. Decision. If you know the cause, stop troubleshooting. You are now in Decision mode (Green Box). Troubleshooting (Blue Box) is only for unknown causes. An ingest connector threw a high volume of warning messages. Engineers assumed: - schema mismatch - malformed inputs - undefined attributes - logic failure The deviation: - a rise in warnings, not errors The relevant change: - a partner feed began including optional fields due to an upgrade The fallback behavior was doing exactly what it should do. There was no problem. The deviation was benign. The change was legitimate. No action needed. Accurate diagnosis saves enormous time. --- # **Architect-Level Principle** **As an architect, I solve problems by finding the real deviation and the relevant change. Symptoms are noise. Deviations are signal. Changes are causes. When these are aligned, solutions become obvious.** --- # **Twenty-Second Takeaway:** “Most problems teams chase are symptoms, not causes. I look for the real deviation and the relevant change. When you connect those two, the true problem becomes clear and the solution becomes simple.” --- # **Cross Links to Other Principles** This principle strengthens: - Decision drag - Useful interoperability - Interfaces and contracts - Portfolio thinking - Degraded operations - Emergent resilience - Architecture accelerates - Innovation at the edge Problem-solving is a skill reinforced by the entire doctrine. --- # ****Doctrine Diagnostic - For Reflection:**** Ask yourself: Are you solving the surface problem, or the real problem? Find the deviation. Find the change. Ignore the noise. ### Narrated Video Walkthrough [Gumlet video player](https://play.gumlet.io/embed/699b695b71f7bf393a4470e1?background=false&autoplay=false&loop=false&disable_player_controls=false) Audio narration available for this document | Browse full [library](https://anthonyveltri.com/audio/) ### Field notes and examples - [When the Ground Moves: Why Institutions Misread Their Own Sensor Metrics](https://anthonyveltri.com/when-the-ground-moves-why-institutions-misread-their-own-sensor-metrics/) - [Recognizing the Operating Regime: Why Asymmetric Errors Change the Decision](https://anthonyveltri.com/regime-recognition-and-the-cost-of-asymmetric-errors-when-post-hoc-learning-beats-theory-first/) - [Field Note: The Symbol Is Not the Signal](https://anthonyveltri.com/field-note-the-symbol-is-not-the-signal/) - [Guardrails, Not Gates: Designing Systems That Bend Without Breaking](https://anthonyveltri.com/guardrails-not-gates-designing-systems-that-bend-without-breaking/) Last Updated on February 22, 2026 ### Related Posts [![Thinking in Probabilities featured title card](https://anthonyveltri.com/wp-content/uploads/2025/11/doctrine-22-thinking-in-probabilities.jpg) #### Doctrine 22: When "It Depends" Is the Right Answer: How to Think in Probabilities Under Uncertainty](https://anthonyveltri.com/guide/doctrine-22-when-it-depends-is-the-right-answer-how-to-think-in-probabilities-under-uncertainty/) [![A graphic with an abstract, circuit-like pattern in orange and beige tones. A dark box contains the text “ITIL 4 Foundation: A Practitioner Crosswalk.” In the top right, a gray label reads “Doctrine 03 Companion.”.](https://anthonyveltri.com/wp-content/uploads/2026/03/Doctrine-03-Companion-ITIL-4-Foundation-A-Practitioner-Crosswalk.jpg) #### Doctrine 03 Companion: ITIL 4 Foundation: A Practitioner Crosswalk](https://anthonyveltri.com/guide/doctrine-03-companion-itil-4-foundation-a-practitioner-crosswalk/) [![This diagram illustrates increasing salary capacities, with larger houses on higher blocks representing $6k, $24k (median), and $80k per year.](https://anthonyveltri.com/wp-content/uploads/2025/12/field-reports-5-year3.jpg) #### Field Report: College Financing and the 5-Year Home Runway](https://anthonyveltri.com/guide/field-report-college-financing-and-the-5-year-home-runway/) [![A graphic with the title "ANNEX K System and Workflow Profiles" in bold text on a dark overlay, set against a background of abstract blue and black circuit and network diagrams.](https://anthonyveltri.com/wp-content/uploads/2025/11/annex-k-system-and-workflow-profiles.jpg) #### ANNEX K. System and Workflow Profiles (Case Studies)](https://anthonyveltri.com/guide/annex-k-system-and-workflow-profiles-case-studies/) [![A diagram shows a translucent seated person labeled "Previous State: Unstructured Memory," a backpack labeled "Operational Assets: Field Repository," and five labeled cubes connected by arrows, representing stages of knowledge processing and organization.](https://anthonyveltri.com/wp-content/uploads/2025/12/the-backpack-featured-image-finally.jpeg) #### Field Note: Sorting the 20-Year Backpack](https://anthonyveltri.com/field-note-sorting-the-20-year-backpack/) [![Brass plaque reading "Proudly Maintained By Mike E." mounted below the manufacturer nameplate on a station-service alternator at Hoover Dam, flanked by two red Pelton pressure-regulator cylinders.](https://anthonyveltri.com/wp-content/uploads/2026/09/bams-article-featured-image.jpeg) #### Anthony Veltri Explains why Federation Cannot Replace Stewardship](https://anthonyveltri.com/federation-cannot-replace-stewardship-bams-2026/)