Systems & decisions

Simplicity is surface area, not minimalism

Yopla4 min read

Simplicity doesn't mean fewer features. It means features that are coherent, clear, and connected. A system with ten well-integrated tools can be simpler than a system with three that don't talk to each other.

Less surface, clearer ownership

Illustrative concept: Simplify / Connect / Maintain. Not a measured result.

The difference is surface area.

What surface area actually means

Think of surface area as an analogy for the places where an operational system is exposed to confusion or error.

In this analogy, Every manual handoff between teams is surface area. Every field in a form that requires interpretation is surface area. Every place where two systems might disagree about the same fact is surface area.

Surface area is where confusion enters. Where errors occur. Where the system meets human behaviour and the two don't quite agree.

Apply it to your work

Find the surface area people have to manage

  1. Handoffs

    Where does work move between people or systems?

  2. Translations

    Where does information need to be reinterpreted?

  3. Knowledge

    Where does the system rely on one person's understanding?

  4. Reconciliation

    Where must someone repeatedly make records agree?

Illustrative inspection prompts; fewer visible tools do not automatically mean less complexity.

The minimalism mistake

The instinct when things get complicated is to simplify by removing. Fewer tools. Fewer steps. Fewer features. This feels decisive and clean.

But removing things only helps if you're removing the right things. Cutting a tool that handles a critical workflow doesn't simplify - it just moves that workflow into email and spreadsheets, where the audit trail, automation and visibility may be weaker unless they are deliberately maintained.

True simplicity isn't about having less. It's about having less that can go wrong.

A system with ten tools where data flows automatically between them, definitions are consistent, and each tool does one thing well is simpler to operate than a system with three tools that require manual transfers, conflicting data models, and a person who 'knows how it all connects'.

How to measure surface area

You can't reduce what you can't see. Here's how to make surface area visible:

Count the handoffs

Every time data moves from one system to another via a person, that's a handoff. Every handoff is a place where data can be delayed, mistyped, reinterpreted, or forgotten. Map your core workflows and count the manual handoffs. That number is your baseline.

Count the translations

Every time someone has to explain what a field means, what a status represents, or why two numbers don't match, that's a translation. Translations mean your systems aren't speaking the same language. The more translations required, the more surface area exists.

Count the single points of knowledge

Every time the answer to 'how does this work?' is a person's name rather than a document or a system, that's surface area. It means the process depends on institutional knowledge that can walk out the door.

Count the reconciliation effort

Every time someone spends time making two data sources agree, that's surface area being managed rather than eliminated. The time spent reconciling is a direct tax on the complexity of your architecture.

Reducing surface area

Once you can see it, you can reduce it. The principles are straightforward:

Automate handoffs

When a deal closes in the CRM, the invoice should generate automatically. When a project is approved, the resource allocation should update. When an employee is onboarded, access can be provisioned through an approved role-based process, with least-privilege permissions, reviews and prompt revocation when access is no longer needed. Automation can remove manual handling, but the integration still needs validation, monitoring and a way to recover when it fails.

Unify definitions

A 'customer' should mean the same thing in every system. A 'project' should have the same boundaries everywhere. Revenue measures should make their definitions and timing clear. Bookings, invoiced revenue and recognised revenue can legitimately differ. Consistent labels and documented relationships reduce confusion without pretending those measures are identical.

Document the system

Not in a manual that nobody reads. In the system itself - clear naming conventions, consistent categorisation, obvious workflows. The system should teach its users how it works, not rely on tribal knowledge.

Accept appropriate complexity

Some complexity is necessary. A business with multiple revenue streams, international operations, and regulatory requirements will have a complex system. The goal isn't to pretend that complexity doesn't exist - it's to manage it structurally rather than heroically.

Structural management means the complexity is handled by the system. Heroic management means the complexity is handled by specific people working very hard. The first can reduce dependence on individual memory. Both still need appropriate ownership, skills and review.

The test

Here's the simplicity test: can a competent new hire understand your core systems in their first week?

Not master them. Understand them. See how data flows. Grasp why things are structured the way they are. Know where to find what they need.

If the answer is yes, your surface area is manageable. If the answer is no - if understanding the system requires weeks of shadowing, informal mentoring, and discovering undocumented workarounds - then your surface area is the thing holding you back.

Simplicity isn't a feature. It's a structural property. And like all structural properties, it's built deliberately or it isn't built at all.

From the Yopla source archive dated 2025-09-01. Refreshed for this edition.

All insights

We use analytics cookies to improve this site. Cookie policy