positive and negative freedoms

We want to give our teams freedoms, but taking some things away can also be freedom.

There are two kinds of freedom, positive and negative freedom.

Positive freedom is the traditional freedom, freedom to do something. When your teams have positive freedom they can choose how to build their systems. They can choose what code or tech to use. Positive freedom feels good, it leads to autonomy and mastery (two of the three things that people need from their work, the third is purpose).

Positive freedom is scary though. Positive freedom allows the freedom to choose the right tool for the task, but not all your teams and team members will use the same decision making criteria. Some of your teams might make decisions that have a larger local-benefit rather than a global benefit. An example could be a team adopting a new programming language for their learning and development, but that language isn’t well known or well supported across the organisation.

A manager to want to remove some of the freedoms, to reduce the chance of the organisation being left with a tech they cannot support. This would reduce the teams positive freedom, which feels bad. In the carrot vs. stick analogy, this would be a ‘stick’ (forcing the decision of the team, by limiting their positive freedom).

Negative freedom is the freedom from something. It’s the freedom not to need to worry about it. A platform, or developer tooling team, is an example of a team who is focused on negative freedom. This team reduces the amount that all your other teams need to think about. A platform team abstracts away the specifics of the infrastructure, or cloud provider(s) that you are running on. This is negative freedom.

Your teams probably don’t have a choice of which container orchestrator to run their apps on, or which authentication provider to use, or which logging and tracing tooling to use. Clearly you don’t want all your teams to need to worry about these things, so they are negative freedoms. Freedom from the need to decide. If your platform and tooling teams are successful, there will be a clear benefit to using the tooling provided, and a clear cost to trying to roll your own.

If your making a decision that is about to limit positive freedom (‘stick’) you should find a way to reframe the decision into a negative freedom (‘carrot’). Instead of “you can’t choose that programming language”, make it so that the team has no real incentive to pick another language. The tooling, the growth and development opportunities, the support are all such that there’s a higher cost than there is benefit. This is negative freedom.

Optimise for the largest negative freedom possible, without inhibiting positive freedom. Choose net positive freedom, where the negative freedoms are still a net benefit to your teams.