Upstream...

Seeing Structure, Sitting Alone

When new projects came in with messy requirements, vague ambitions, half-formed ideas - my mind would automatically start pulling them apart. Not aggressively, not to simplify them away, but to understand what actually needed to exist for the thing to work.

I never named this process. I never formalised it. It wasn’t something I learned from a book or a framework. It was just how I learned to survive delivery.

Only much later did I realise that this way of thinking was not as common as I assumed.

In meetings, people would debate features, timelines, UI choices, priorities. I would find myself thinking at a different layer entirely - about the underlying work, the logical units hiding beneath the surface, the invisible constraints that would shape everything downstream. When I tried to explain my reasoning, it often sounded abstract or overthought. When I didn’t, I carried the responsibility quietly.

That’s where the loneliness crept in.It didn’t come from being “smarter” or “more technical”. It came from seeing a different layer of reality and having very few people to share it with.

Abstraction Is a Quiet Craft

Abstraction is a strange skill.

If you do it badly, you create elegant nonsense.

If you do it well, very little seems to happen - except that fewer things break later.

Most teams live quite comfortably at the level of execution artifacts:

• user stories

• epics

• designs

• architecture

• tickets

• sprints

• releases

These are necessary. They are how work moves.

But they are not where truth only lives.

Truth also lives one layer upstream, where requirements are still ambiguous, where scope is still negotiable, and where the cost of misunderstanding is invisible but compounding. Over the years, I found myself spending more and more time in that layer, often without shared language, often without company.

What I eventually noticed was this: Despite wildly different domains, technologies, and clients, the work itself kept repeating.

Not the UI.

Not the features.

The fundamental work.

The Work Beneath the Work

At some point, a pattern became hard to ignore.

Most requirements, if stripped of presentation and narrative, could be decomposed into a small number of fundamental logical components. These components weren’t tasks. They weren’t features in the marketing sense. They were the smallest meaningful units of work that could be reasoned about independently.

They could be: estimated/ planned/ delivered/ validated/ and, in a services context, billed.

I started thinking of these as atoms - not because they were universally small, but because breaking them down further often destroyed their meaning.

Alongside these, there were always other forces at play. Business rules. Integrations. Constraints. Dependencies that cut across multiple atoms and made otherwise simple things complex. I began thinking of these as strings - invisible tensions that distorted effort and risk across the system.

There were also smaller building blocks - elements, logic, controls, variations - that mattered for execution but not for reasoning. I thought of these as particles.

None of this was formal. It lived mostly in my head, sometimes in spreadsheets, sometimes in documents, rarely named explicitly.

But it worked - across middleware, blockchain, platform migrations. Different domains, same underlying structure.

Why This Is Hard to Talk About

Part of the reason I never articulated this clearly is that abstraction doesn’t reward visibility.

People praise speed, decisiveness, delivery. They rarely praise the person who prevented a bad decision before it was made. When abstraction works, it leaves very little evidence behind.

Another reason is that abstraction is hard to pass on without damaging it.

The moment you try to standardise it too aggressively, it turns into a checklist.The moment you pretend it’s universal, it becomes brittle.The moment you oversell it, it becomes dogma.

So for years, this remained a personal discipline - something I practiced, refined, and carried silently through projects.

Why This Matters More Than It Sounds

Most delivery problems don’t happen because teams can’t execute.

They happen because the scope was never properly understood.

When requirements are treated as narratives instead of logical structures, teams argue about the wrong things. Complexity hides. Risk gets discovered late. Effort feels unpredictable. Estimation becomes a political exercise instead of a technical one.

What I eventually realized is that stories and epics are excellent tools for execution, but suboptimal instruments for understanding work.

They are downstream artifacts. They assume clarity that often doesn’t exist yet.

Atomic decomposition, as I now think of it, lives upstream of all that. It is not a methodology, and it is not a direct replacement for Agile or design or architecture. Currently, it is simply a way of asking better questions earlier.

- What actually needs to exist?

- What is fundamental, and what is incidental?

- What can stand alone, and what is tied invisibly to everything else?

- What looks small but carries poison?

- What exists only because “we always do it this way”?

These questions don’t make execution faster immediately.

They make mistakes rarer.

What Can and Cannot Be Captured

I’m increasingly clear about the boundary.

You cannot capture (yet):

• the generative capacity to look at novel chaos and see latent structure

• the compressed experience of years of delivery

• the pre-conscious pattern recognition built over time

That stays embodied.

But you can capture:

• the method - the sequence of questions asked when decomposing something

• the ontology - the distinctions that matter (atoms, particles, strings)

• the heuristics - rules of thumb that prevent common failures

• the artifacts - worked examples showing how thinking evolves over time

These don’t replace intuition. They shorten the distance to it.

This is what I’ve been trying to pass on to my team - not answers, not templates, but a way of seeing. Sometimes it lands. Sometimes it doesn’t. That’s the nature of it.

Closing Reflection

I didn’t invent “The Physics of Delivery: Atomic Decomposition of Requirement & Scoping” last weekend.

I noticed it. It had been forming slowly across years of work, failure, pattern recognition, and responsibility. Naming it doesn’t make it more powerful. It just makes it possible to talk about - and perhaps to feel a little less alone in seeing structure where others see chaos.

I don’t know where this goes.

• It could evolve into a methodology if it hardens enough.

• It could become a decomposition model embedded in software.

• It could remain an internal discipline, researched, refined, and practiced quietly.

• It could fragment into something else entirely.

I’m comfortable with that uncertainty.

What matters more to me is preserving the integrity of the thinking and resisting the urge to over-define, over-sell, or prematurely productise something that is still alive.

This isn’t an attempt to bottle intuition.

It’s an attempt to leave traces.

If this becomes something more one day, it will only be because it stayed true long enough to deserve it.

p.s. This is not a methodology, a taxonomy, or a blueprint. It is a working discipline, intentionally incomplete and deliberately porous. Its purpose is not to replace judgment, but to shorten the distance to it.

Art: SamB, 2021