I was recently listening to my friends argue about whether to privatize govt banks or not. Some argued that this will improve efficiency, some wondered if private corporations can be trusted with all the banking in the country, some debated socialism and its pros and cons. 

This is a common discussion pattern in both formal and informal settings. A lot of public opinions are framed this way (e.g. rapists should be summarily hung, but what about humanitarian treatment or legal rights) so is a lot of tech hype (e.g. NoSQL should be used for high scalability, but is it too complicated or do we have the tools).

One thing that really struck me is that how this discussion is actually upside down. It assumes that a course of action has been determined, and now all that is left to do is to debate whether it is acceptable to everyone or not. The conversation on privatizing national banks presents an opinion like a strategy to attain an undefined goal. The argument is not about the privatization of banks at all! People talk past each other because each of them is talking about a different thing like corruption, socialism, bad loans, etc. These things just cloud the issue and keep us from the actual discussion.

To actually discuss whether banks should actually be privatized or not, we would have to define the effect we are trying to create. Why have the conversation at all? All the other words are about the side effects and symptoms of an action we have presumably already taken (privatize the banks), not about “why” we took the action. The real question is “what do we want to achieve”. Economics and banks are elements of a system that does something, i.e. has a purpose. We need to define this purpose before we can define if a proposed change serves this purpose. Once we understand the purpose, we can try to navigate the environment and achieve it. Without knowing the purpose, “privatize the bank” means nothing.

This should be familiar from the way a lot of inter-team presentations are done. A decision is presented for discussion and critique, but with the understanding that fundamental questions are not to be raised and any feedback should be given in the context of the conclusion being presented. We look at the proposal, debate whether it is good or bad, and propose changes that may improve the proposal. But for this critique to be useful, the feedback has to consider the purpose of the system and the change first, and that sadly does not happen very often.

Let’s consider some technical examples of this. Decoupling is one of my favourites. The statement “decouple your components” is unlikely to engender debate, or at best engender debate on the mechanism of decoupling. It is a great idea, but the bigger question lies in the effect that we want to create? What exactly is it that I want to get out of this? Do I really want to change one of my components? The principle of decoupling isn’t valuable by itself, it needs the context of motive to become so. Apple, for example, doesn’t decouple. It integrates deeply.

Or take autonomy in teams. At this point, the Twitter-going crowd believes that autonomous teams (two-pizza, problem-driven, etc) are the best way to organize a workforce. But why do I want this? Someone told me that engineers like this because they like “freedom”. Freedom from what? Who knows. If the intended effect is to efficiently use a large, unmotivated workforce, maybe autonomy isn’t the way to go. Old-school command and control might be best.

The words “decouple” and “autonomy” are trying to use the perceived authority of best practices without identifying the context of applying these ideas. The point is not whether they are good or bad, but that we haven’t thought about the objective, and therefore must work backward from solution to the problem and hope they fit each other. We don’t even know what the problem is in the larger context. Starting from the intended effect “I want to reduce the cost of change in my software” might lead us to consider that change is faster without decoupling if deep integrations are required and swapping out components is not necessary. Starting from the effect “I want my teams to create high impact” might leads us to consider that before teams can create impact, they should understand which direction the organization wants to go in and therefore what “impact” looks like. That alignment must come before autonomy can be unleashed.

Applying a strategy by looking at one aspect reverses cause and effect. Decoupling doesn’t axiomatically improve software. Autonomy doesn’t automatically create impact. Without knowing the context and intent, a strategy can only succeed by chance. It is more likely to cause damage via second-order effects. So if you want to take action, first identify the intended effect and the environment in which you are working. All else will follow from that.

Read next: Preventing go-around architecture with platform thinking