Symptoms vs. Root Causes

1.1 Why distinguish between symptoms and root causes?

In mature organizations, frustrations with CRM systems and tech stacks are common. Teams might complain about unreliable data, inefficient workflows, or cumbersome tools. The immediate response is often to fix what appears visibly broken:

• “There are too many fields, and it takes too long to fill out a profile.” → Remove fields.
• “Our data is inaccurate.” → Fix the numbers so the math checks out.
• “Pipeline numbers are down this month.” → Assume something is broken with the lead ingestion form.
• “Our ads are converting less.” → Conclude something is off with attribution.
• “We’re missing a field a rep wants on a contact.” → Add it immediately without considering consequences.
• “Because a system went down, we missed some data on an object.” → Run a backfill. [Check out Austin’s Backfill philosophy here: Backfill Philosophy Doc]

These actions may address symptoms but rarely tackle underlying root causes. How can you build a more robust system, one that doesn’t need frequent backfills? And how can you train your team to properly investigate issues so they’re resolved effectively without draining resources, time, or morale?

A key theme that organizations often face is the tendency to blame tools as a first resort without investigating the underlying issue. For example, at Ramp, Austin built an Investigation Guide to standardize the approach to problem-solving. Instead of defaulting to “the tool is broken,” the guide encouraged team members to follow a few steps before placing blame on the tech stack, walking them through the debugging and documentation process.

A Structured Investigation Process

When a system issue arises, it’s essential to identify obvious causes first and then work backward through dependencies. For example, if ad attribution seems “wrong” or “down,” instead of jumping immediately to high-level systems, ask:

1. What creates this data point? Begin by checking the source that directly outputs this information.
2. Is the data object accurate and functional? Validate that the immediate source is accurate and working as expected.
3. Move upward only once each dependency is verified.

In complex systems, jumping straight to upstream sources or randomly troubleshooting without a structured approach often fails. A methodical investigation process teaches teams to work through each layer of dependencies, ensuring a more thorough diagnosis.

We’re going to walk through a detailed framework to think about the differences between symptoms and root causes, to avoid quick fixes that don’t last and instead implement solutions that address the fundamental issues. This approach saves time, reduces operational disruptions, and ensures that your CRM and tech stack can scale effectively with your business.

Want to see the artifact that started it all? Here’s a link to Austin’s Investigation Guide artifact: Investigation Guide

1.2 The Two-Level Framework Explained

Our framework consists of two levels:

• Symptoms: The visible problems indicating that something isn't working as it should. Common symptoms include bad data hygiene, inefficient workflows, clunky reporting, siloed data, and user frustration.
• Root Causes: The underlying factors that lead to these symptoms. The primary root causes are:
  • Rituals: The processes, behaviors, and practices of your teams.
  • Connections: The integrations and data flows between your systems.
  • Tools: The software and platforms in your tech stack, including choosing the right CRM and deciding whether a change in provider is beneficial.

Understanding this framework helps you systematically diagnose issues:

• Identify Symptoms: Observe and document the problems affecting your operations.
• Trace Back to Root Causes: Analyze each symptom to determine which root cause is contributing to it. Start by examining the site of impact, then trace backward through the system step-by-step. This is why a systems or architecture diagram is essential—everyone needs a shared understanding of tool connections and directional flow within the system.
• Implement Targeted Solutions: Address the root causes to resolve symptoms effectively.

1.3 Common Mistakes in Diagnosing CRM and Tech Stack Issues

Companies often make the mistake of treating symptoms as root causes. Here are some common missteps:

• Jumping to Tool Replacement: Assuming that the technology is the problem and switching to a new CRM without assessing whether the issue lies elsewhere.
  • Example: A sales team struggles with duplicate records and blames the CRM. They switch to a new system, but duplicates persist because the underlying issue was a lack of data entry standards (a rituals problem).
  • Example 2: A common complaint is, “I can’t do XYZ in a tool,” but it’s often disguised as, “This tool won’t grow with us.” We’ve seen companies switch repeatedly between Salesforce and HubSpot—sometimes multiple times—driven more by seller preferences or platform bias than by actual technical requirements.
• Overlooking Rituals and Processes: Ignoring how team behaviors contribute to problems.Example: Marketing and sales teams have different definitions of a qualified lead, leading to inefficiencies. Finance, Product, and Sales teams often have different definitions of an Account or a Closed/Won Opportunity too. The problem isn't the CRM but inconsistent processes between teams because these definitions aren’t often written down.

Creating and executing a defined qualified lead involves multiple systems. Marketers have a text-based definition, while systems people rely on a tool-based definition. The two aren’t aligned.

Creating metrics should start with the person who owns the metric. Define it in common language first, then map it to specific tool definitions.

For instance: A Marketing Qualified Lead (MQL) might be defined as any lead who signs up on the website, represents a company with more than 10 employees, has under $100M ARR, and holds certain LinkedIn titles.

In systems terms:

• Segment: Triggers Email Form Submitted event
• Clearbit: employee_size > 10
• Clearbit: company_arr < 100,000,000
• Internal system: user.titles includes {qualifying titles}

Metrics like an MQL often involve data points from multiple tools, unified in a CRM or data platform. This is why it’s essential to have both a human-readable definition and a systems-readable definition documented side by side to ensure alignment.

• Neglecting System Integrations: Failing to recognize that poor connections between systems cause data silos and inefficiencies.Example: The CRM isn't properly integrated with the marketing automation platform, leading to incomplete customer profiles and ineffective campaigns.

1.4 The Importance of Addressing Root Causes

Addressing only the symptoms may provide temporary relief but doesn't solve the underlying issues. By identifying and fixing the root causes, you create lasting solutions that improve efficiency, data quality, and user satisfaction.

In the next lesson, we'll focus on identifying the symptoms in your organization, setting the stage for diagnosing the root causes.