Why This Had To Become A System

When I first looked at what Andrew had been doing, the thing that stood out wasn’t the output.

It was that it worked more than once.

Different companies, different levels of chaos, different starting points, and you could run the same approach and land in roughly the same place. Not identical, but consistent enough that it clearly wasn’t down to who happened to be in the room or whether everyone had a good night’s sleep.

That’s unusual.

Most frameworks don’t behave like that. Change the people, the context, or the time pressure, and the quality moves around quite a bit. You get a great result one week and something that needs “another pass” the next.

This didn’t move as much.

Where it actually breaks

The obvious next step would be to do more of it. More workshops, more teams, more documentation. Scale the thing that seems to be working.

That wasn’t the problem.

The work held up inside the workshop. You could get to a clear view of value, align a group of people around it, and make it make sense without too much hand-waving.

The problem showed up afterwards.

Once that output left the room, it started to degrade. Not immediately, and not in a way that triggers alarm bells. No one raises a ticket saying “value integrity issue detected.”

It just stops being one coherent thing.

Sales adapts it so it works in a live conversation. Marketing reshapes it so it fits a campaign. Finance pulls the numbers apart because that’s their job. Procurement introduces timing and process constraints that weren’t in the original discussion and don’t really care that they weren’t.

None of that is wrong. It’s just how organisations behave.

But every one of those steps introduces small changes. Different emphasis, different language, different assumptions.

Those changes stack up.

What that looks like in practice

You start with something that is internally consistent.

A few weeks later, there are three slightly different versions of it doing the rounds. A few months later, it depends who you ask and how much time they have before their next meeting.

No one is deliberately changing it. They’re just making it usable for what’s in front of them. That’s the job.

By the time it gets anywhere near a decision, it’s no longer the same thing that was defined at the start.

Some parts are still there. Some aren’t. Some have been simplified to the point where they’ve lost most of their original meaning. The sharper edges tend to be the first to go because they’re the hardest to explain.

That’s usually when things slow down.

Not because the value disappeared, but because it’s no longer clear enough, or stable enough, for someone to stick their name against it and move it forward.

Why frameworks don’t fix this

Most companies already have frameworks.

Strategy frameworks, sales processes, messaging structures. There’s no shortage of diagrams.

They’re not the issue.

The problem is that frameworks don’t carry themselves. They describe how something should be thought about, but they don’t control what happens once it’s in motion.

From that point on, it relies on people to keep it intact. In a real organisation, with competing priorities and limited time, that doesn’t happen consistently.

You don’t get one clean version moving through the system. You get variations, each one slightly adapted for purpose.

Once that starts, pulling it back into a single, consistent structure is a lot harder than people expect. Usually it involves a meeting, which turns into two meetings, and then someone suggests “we should revisit the original assumptions.”

What the problem actually is

This isn’t about writing better messaging or running better workshops.

It’s about control.

If you want a piece of thinking to produce consistent outcomes, you need a way to keep it consistent as it moves. Not perfectly, but within a range that still makes it usable.

That means being able to see when it starts to drift, and do something about it before it shows up as a problem somewhere else.

Most setups don’t give you that.

They assume that once something is defined, it will hold. In practice, it doesn’t. It just changes slowly enough that no one owns the change.

Why this turns into a system problem

The methodology itself already worked. It gave you a way to define value properly and test it in a way that made sense to the people in the room.

But it didn’t persist on its own.

To make it reliable, you need something that doesn’t depend on everyone remembering exactly how it was meant to be applied every time they touch it.

You need something that applies the same logic consistently, even when the context changes, and even when people are under pressure to just get something out the door.

You also need it to run over time. Not just once at the start, but as things evolve, new people get involved, and the original context fades a bit.

At that point, you’re not dealing with a framework anymore.

You’re dealing with a system.

What changes when you treat it that way

You stop relying on alignment to magically survive contact with the rest of the business.

You stop assuming that everyone will interpret things the same way.

And you stop being surprised when things drift, because you can actually see it happening.

Instead, you have something that applies the same logic each time, shows you when the output starts to change, and gives you a way to correct it before it turns into rework somewhere else.

It doesn’t remove variation completely. Nothing does.

But it stops the quiet accumulation of small changes that eventually turn into a large problem no one can quite trace back.

Why it matters

Most of the machinery inside a business is built to keep things moving.

More pipeline, more activity, more output. Everyone is busy, which is usually taken as a good sign.

Very little of it is built to keep things consistent as they move.

If what you’re moving degrades along the way, everything downstream gets harder. More explanation, more rework, more conversations that start with “just to clarify.”

It’s not always obvious why, and it rarely shows up as a single issue you can fix.

It just shows up in slower decisions, longer cycles, and a general sense that everything takes more effort than it should.

Closing

The methodology was already doing its job.

The issue was that it didn’t survive contact with the rest of the organisation, which is where most things tend to come undone.

Turning it into a system was the only way to deal with that properly.

That’s what led to StorylineOS.

Angus Gregory | Co-Founder of StorylineOS