How governance emerges naturally as projects grow
The previous chapter ended with a question that stayed with me long after I had finished writing it.
Who should be responsible for what?
At first, I assumed it was a question about people. Looking back over the projects I've worked on, I don't think it is.
I used to believe governance was something organizations introduced as they became larger. The word itself sounded formal, almost corporate. It belonged to policies, approval chains, and management meetings. It certainly didn't feel relevant to the kind of websites I was building.
Experience slowly changed that view.
Years ago, while running my own agency, every client conversation passed through me. It wasn't something I had carefully designed. It simply happened that way. Whenever a question appeared, I answered it. Whenever a decision was needed, I connected the right people. At the time, it felt responsible.
As the agency grew, however, I noticed something I hadn't expected.
Developers naturally began speaking with clients. New conversations happened while I was working somewhere else. Important decisions were still being made, but they no longer travelled through the same path they once had. I found myself spending more time reconnecting pieces of information than helping projects move forward.
That was the first time I realised growth had quietly changed my role.
I thought I was managing projects. But in reality, I had become the connection between them.
For a while, I tried to keep up. Eventually, it became obvious that the problem wasn't my workload. The organization had simply reached a point where one person's memory could no longer carry the understanding of an entire project.
That was when we introduced a project management system.
What changed afterwards wasn't the software itself. Ownership became clearer. Reviews became easier because everyone knew what belonged to them. Accountability stopped depending on whoever remembered the last conversation. The project felt calmer, not because there was more control, but because there was less uncertainty.
For a long time, I thought that was a lesson about managing teams.
Years later, Plugiva quietly challenged that assumption. This time there was no growing agency, no employees, and no project managers. There was only me. Yet the project itself kept evolving.
New content types appeared. Different parts of the application gradually found their own responsibilities. Repositories became separate. Helpers became separate. Public routes, administration, media handling, authentication, settings, and none of these were planned from the beginning. They emerged as the website itself became more capable.
The interesting part was that nobody asked me to organize the project that way.
But complexity did.
I began separating responsibilities for exactly the same reason I had introduced clearer ownership years earlier. Not because another developer needed it.
Because I did.
Or perhaps more accurately, because the person who would return to this project months later would need it. That was an unexpected realization.
Sometimes your future self becomes another collaborator.
The code I write today eventually becomes someone else's work to understand, even if that someone is still me.
Looking back, I no longer think governance begins when an organization hires more people.
It begins whenever complexity starts challenging clarity.
In some organizations that complexity comes from a growing team. Sometimes it comes from a growing website. There are also moments when it arrives so gradually that we don't notice it until yesterday's understanding no longer feels reliable.
That's why governance has never felt like bureaucracy to me.
It feels more like preserving understanding.
Our previous essay (When workflows stop matching reality) taught me that a workflow isn't just how work moves. It's how understanding moves.
Perhaps governance answers the question that naturally follows.
How does that understanding continue to endure as everything else keeps evolving?
Maybe that's why governance seems to emerge instead of being introduced.
By the time we give it a name, we've often been practicing it for quite some time already. And once understanding has somewhere reliable to endure, another question quietly begins to emerge.
If responsibilities evolve over time, shouldn't permissions evolve too?
Has your project reached a point where clearer ownership became necessary?