Simple Work is not always Simple Work...

For a long time, I assumed that certain pieces of enterprise work were hard because they were conceptually complex.

You know the sort of thing:

• “That profile will take weeks”
• “We’ll need days of effort to configure that”
• “Only a few people really understand how this works”

It turns out, at least in this case, that assumption was wrong.

What I’ve recently learned is that some work isn’t slow because it’s difficult — it’s slow because it’s bitty.

When the mystique evaporates

I recently got access to a development environment and the internal documentation used to build document check-in profiles in a legacy content management system.

I’ll be honest: part of me was bracing for disappointment — the “oh, this is actually far more complicated than you realise” moment.

Instead, what I found was this:

• The individual steps are straightforward
• The rules are understandable
• The logic is not especially deep

If you’ve ever built forms, defined metadata, or worked with relational tables, there’s nothing here that should feel alien.

And yet… this work regularly attracts estimates measured in days or weeks.

So where does the time go?

The real problem: fragmentation, not difficulty

The process looks roughly like this:

• Go to one place to define fields
• Go somewhere else to define values
• Somewhere else again to define relationships
• Back to views to expose those relationships
• Over to profiles to assemble everything
• Then to rules to tweak behaviour
• Then back again to reorder, re-label, and re-check

None of these steps is hard on its own.

What is hard is:

• Context switching constantly
• Remembering which screen affects which behaviour
• Re-expressing the same intent in multiple places
• Avoiding small mistakes that only surface much later

It’s not complexity — it’s orchestration debt.

Why spreadsheets appear (and never really leave)

In this environment, Business Analysts do what they can.

They produce spreadsheets:

• Mapping fields
• Defining dependencies
• Explaining intent in a human-readable way

Those spreadsheets aren’t authoritative. They’re not executable. They’re not validated.

But they are the only place where the whole picture exists at once.

Which tells you something important.

The missing piece isn’t capability — it’s flow

What struck me most wasn’t that the tooling was inadequate.

It was that there is no single, coherent design surface.

No place where you can:

• See all the fields together
• Understand their relationships visually
• Validate assumptions early
• Walk a stakeholder through the design without hand-waving

Instead, knowledge lives:

• Partly in tools
• Partly in documents
• Partly in people’s heads

That’s not a skills problem. It’s a design problem.

Why this matters (even if nothing changes)

This experience changed how I think about “large” pieces of work.

Sometimes, when something is described as complex, what’s really being described is:

• High fragility
• High error cost
• Poor feedback loops

People pad estimates not because the task is hard — but because breaking things is easy and recovery is painful.

That’s rational behaviour.

A quiet conclusion

I went into this thinking I might build a clever tool. What I came away with was something more useful:

• A clearer mental model
• A lot less mystique
• A better understanding of where time actually goes

Not every problem needs a new system. But many problems benefit from being made visible.

And sometimes, the most valuable thing you can do is simply notice that the emperor isn’t wearing anything particularly complicated — just a lot of poorly stitched layers.