Governance versus Stewardship

In the enterprises I've recently been a part of, there's been lots of discussion about "governance". Governance is a process where you ask other people for permission to do things. The governing body serves to enforce consistency in things like API design or to ensure adequate testing on deploys to production.

One of the biggest problems with governance is that the beaurecratic process can be quite slow. Relying on an outside authority to manually approve your deploys to production introduces latency which is likely to cause your deploys to accumulate. The subsequent deploys are larger, which means that both their blast radius is bigger and, when things do go wrong, it's difficult to isolate which change in the batch caused the issue. In this paradigm, introducing this strong-handed governance is actually counter to their own goals.

There are similar issues with beauracracy around API design. Relying on external parties reduces your overall velocity by being blocked on a third party. This results in delays to release as coordination costs go up.

Instead, I've been thinking about stewardship as an alternative view. Stewardship is much more collaborative of a process and involves tending to what exists, more than planning what will be. In my work (ironically as a software architect), I tell my colleagues that we should think less like architects and more like gardeners. We aren't out to design grand cities with heavy, immovable stone or paved interstates. Instead, we're doing some edging of our plots to ensure the plants don't go too far astray, removing any weeds that pop up, and generally providing a great environment for good things to happen.

In my work, we're working on federated graphql where we have multiple autonomous teams collaborating around a shared conceptual model of our company's data graph.

In a governance model, we would have alterations to the graph go through a committee structure to ensure that the changes are consistent with other applications. This suffers from the problems mentioned earlier.

In the stewardship model, we closely collaborate with the teams building their initial subgraph, collaborating with them and offering reviews. After they've successfully onboarded into the graph, teams are welcome to evolve their graph over time as they see fit. There is a common resource (a slack group called the "gql-schema-gardeners" which they can tag) folks can reach out to when they want to consult about their schema designs.

To keep with the metaphor of gardening terms, we help our seeds germinate and when they're established leave them be to flourish. If weeds pop up, we do what's necessary to ensure the health of the plants.