When workflows stop matching reality

The previous essay ended with a question.

How do all of those specialised responsibilities continue working together as one website?

For a long time, I assumed the answer was simple.

People would continue working the way they always had.

After all, if a workflow had served a project well from the beginning, why would it need to change?

Over time, I realised that websites aren't the only things that evolve.

The way people build them has to evolve too.

I once worked on a large project where budget was never the problem. New ideas were welcomed. Designs evolved. Features were added, refined, and sometimes completely rethought as the project progressed.

At first, those changes felt like progress.

Then something more subtle began to happen.

A feature would finally be completed, only for new requests to emerge from it. Each request seemed reasonable on its own, but together they began reshaping the foundations we had just finished building.

Conversations became longer.

Decisions became harder to follow.

It became increasingly difficult to know whether we were extending the project or rebuilding it.

The amount of work wasn't what concerned me most.

What concerned me was the growing feeling that the project was changing faster than the way we were working together.

Eventually, the project failed.

For a long time, I believed the lesson was about changing requirements.

And It wasn't so.

Projects are supposed to change. As people learn more, they naturally discover better questions, better ideas, and sometimes better directions.

Looking back, I realised something else had fallen behind.

The project had continued evolving.

Our workflow hadn't really.

Years later, I experienced the opposite.

While working on a university project, our team began facing a different kind of challenge. The project itself was moving forward, but our shared understanding wasn't keeping pace.

Important decisions disappeared into chat conversations.

The same questions returned again and again.

People weren't disagreeing because they lacked ability. They were simply working from different versions of the same project.

Nobody gathered the team to introduce a new methodology.

Nobody announced that we needed a better workflow.

We simply recognised the same frustration.

Almost naturally, we changed the way we worked.

GitHub became the home for development, while a shared document became the single place where features, decisions, and reviews could be followed by everyone.

The tools themselves weren't the important part.

What mattered was what changed afterwards.

Discussions became shorter.

Misunderstandings became less frequent.

The same questions stopped appearing.

Important decisions were no longer lost inside conversations.

Everyone knew where to look because everyone was following the same understanding.

The project hadn't become less complex.

Our understanding had finally caught up with it.

That experience changed the way I think about workflows.

A workflow isn't just how work moves.

It's how understanding moves.

As websites grow, the people behind them naturally become more specialised. Designers, developers, writers, marketers, clients, and stakeholders all begin looking at the same website from different perspectives.

Those perspectives aren't a problem.

They're a sign of growth.

The challenge is helping understanding move between them.

When that stops happening, yesterday's workflow quietly stops matching today's reality.

And it is not because people become less capable, or the project becomes too ambitious.

But because the way the team shares understanding no longer reflects the website they're building together.

Just as websites evolve, organisations adapt, and specialised responsibilities emerge, the way people work together has to evolve alongside them.

Otherwise, the website continues growing while the team slowly stop growing together.

And once a team begins sharing understanding more deliberately, another question naturally follows.

Who should be responsible for what?