If It’s Easy, Is It Worthless? Google Search, the iPhone, and countless other products prove the opposite: the simplest experience often delivers the highest value. So why do our data products still drift toward baroque complexity?

Why complexity creeps in – three patterns

Conway’s Echo

A product’s structure mirrors the org chart. The more hand-offs, the more layers appear in code and data. Even within one team, individual egos want to “leave a trace.”
Example: In many organizations, separate data engineering, analytics, and platform teams each create their own data pipelines and interfaces. This leads to siloed data systems—where the architecture reflects organizational boundaries rather than business needs. The result is fragmented data flows and inconsistent data quality, making collaboration and end-to-end data management difficult.

The Completeness Reflex

“Think of everything for the next 10 years.” Long Excel checklists feel safe, but learning by building is faster than learning by brainstorming. Extra information eventually paralyzes even experts because they see everything that could go wrong.
Example: Over-engineered data pipelines are built to handle every hypothetical edge case and future scenario, resulting in complex, hard-to-maintain systems. This often leads to “analysis paralysis,” where teams spend more time planning and validating than delivering, and the system becomes too unwieldy to use or adapt. Or another example is an Excel sheet for tool selection covering every hypothetical requirement that may come sometime.

The Illusion of “Shouldn’t Be That Hard”

In a VUCA world, clarity is scarce, yet managers still expect linear effort. Creating clarity is hard work—skipping it adds invisible risk.
Example: Stakeholders request a “quick data pull” or a “one-time report,” assuming it’s a simple task. In reality, these requests often require integrating multiple data sources, handling quality issues, and accommodating future changes—turning a supposedly easy job into a recurring, complex maintenance burden.

How to fight back: a balanced & lightweight core

Pure decentralization boosts autonomy and speed—but not clarity. Pure centralization protects consistency—but stifles initiative. The solution lies in a lightweight center that publishes just 3–4 guiding principles—enduring, high-level values such as cost, sovereignty, value creation, portability, or maintainability. These principles are lasting and superordinate: they define the “why” behind your decisions and set the strategic direction for your data ecosystem.

Criteria, on the other hand, are specific, actionable ways to measure or validate whether you are living up to your chosen principles. Criteria may evolve as your context changes or as you discover better ways to assess your progress. If a criterion doesn’t clearly align with one of your selected 3–4 principles, drop it to avoid unnecessary complexity.

Whenever you touch a requirement, use these principles as your rails—and apply the five one-word tests to keep things lean:
Need? · Delete? · Simplify? · Accelerate? · Automate?

As Arnold Schwarzenegger emphasizes in his Seven Pillars of Success, having a clear vision is foundational to achieving meaningful results. In the data world, this translates to defining a small set of enduring principles that guide every decision—ensuring that complexity serves your goals rather than obscuring them

Four data-stack classics—and how to tame them

Here’s how the principles show up in practice. The following table shows complexity patterns in a Lakehouse and how to have just 3-4 principles with specific validation questions / KPIs.

Why These Examples Stick

• Ego & Completeness: Canonical principles force teams to omit dead weight.

• “Shouldn’t be that hard”: Patterns like Medallion architecture reveal hidden dependencies before they explode.

• Central vs. Decentral: A tiny ruleset supports autonomy by making reuse cheaper than reinvention

First Steps against the data complexity trap

• Create & stress-test principles – Are they few, memorable, actionable?

• Audit artefacts – Which tables, features, dashboards, data products, etc. are orphaned? Delete or archive them.

• Wire in automation & metrics – Translate each principle into 1-2 concrete KPIs (e.g. “% dashboards using canonical KPIs”, “€ spend on stale features”) and embed automated tests / cost monitors in your CI-CD and orchestration pipelines. Drift is flagged immediately, so fixes happen before complexity snowballs.

Turning “reduce complexity” from a slogan into a plan is less about heroic refactors and more about deliberate subtraction—one Need • Delete • Simplify • Accelerate • Automate decision at a time.

Feel free to adapt this playbook for your own data ecosystem. Complexity won’t vanish, but with clear principles, ruthless audits and automated guard-rails it will finally work for you, and not become a trap. Creating clarity is hard work—yet its dividends compound every day.