Structure information around the system

2026-04-28T08:30:00.000Z

If your project information is organised around releases and teams, you’ve already lost control of it.

Over the years I’ve seen the same pattern across multiple projects.

• It’s not a tooling issue.
• It’s not even really a people issue.

It’s what happens when project information is left to organise itself.

You join a project and ask: “Where does everything live?”

What you find is familiar:

• Some content in Confluence
• Some in shared drives
• Some in people’s heads
• Some in one tool or another

And even when it’s centralised, the structure looks like this:

• Release X docs
• Sprint notes
• Team A designs

Everything made sense at the time it was created. Six months later, it’s noise.

I’ve seen the same thing in test systems like TestRail. Teams create:

• Release-based test suites
• Team-based groupings
• Versions of regression packs

It reflects how they’re working in the moment — but it hides the only thing that really matters:

What parts of the system are actually covered?

The root issue is simple:

We organise information around activity instead of the system.

But activity is transient:

• Releases come and go
• Teams change
• Sprints are forgotten

The system is the only thing that endures. A small shift makes a big difference:

This isn’t about perfect structure or heavy process. It’s about having just enough shape that the system — and our understanding of it — doesn’t fragment over time.

Structure information around the system itself. For example:

Feature / Subsystem A

• Design
• Technical Notes
• Tests Feature / Subsystem B
• Design
• Technical Notes
• Tests Safety … Standards …

Now you can answer real questions:

• Where is the design for this feature?
• What tests verify it?
• What decisions were made?

What’s interesting is that even experienced teams often don’t enforce this. Not because they disagree - but because:

• It feels like “process”
• The benefit isn’t immediate
• Ownership is unclear

So structure is left to emerge organically. And “organic” quickly becomes chaotic.

The cost shows up later:

• Information becomes hard to find
• Duplication increases
• Onboarding slows
• Decisions get re-made
• Test coverage becomes unclear

But the biggest loss is this:

The team loses a shared understanding of the system. Without intentional structure, teams lose their ability to reason about the system they’re building.

This is why I’ve learned to put a lightweight structure in place early.

Not heavy process. Not bureaucracy.

Just enough shape so that what gets created can still be understood months later.

If your project information is organised around releases, teams or sprints, it will decay.

If it’s organised around the system, it has a chance to endure.

This is the same principle we apply in good system design - structure matters. It turns out it matters just as much for the information about the system.