Software has a tech bias. Our culture emphasizes technology while ignoring social dynamics. We choose to lose ourselves in technological details. This gives us the option to ignore the social dynamics. Some of us do it more than others. Our current culture pushes us in that direction.
This bias creates a problem for development teams. It distorts our perceptions of reality. Because of this distortion, teams will often talk about cultural issues as technical problems. Ironically, it often leads to making the wrong technical decisions, because we are addressing the wrong thing.
Let me illustrate with an example. A new CTO joins a company. The company is currently using Ruby on Rails to develop the main product. The CTO believes that Java is a superior technology. He can point out at benchmark tests matching Ruby vs Java, showing that Java is faster. He can point out that Java has true threads, unlike Ruby, who has a workaround to simulates threads. He also says that it is easier to hire Java developers than Ruby developers.
Within the context of this discussion, Java is the superior technology. It follows that transitioning to Java is the best decision.
I would wager to say that, in most cases, this is a bad technology and business decision. A top-down change of languages implies a rewrite. Rewrites are notorious for being expensive, take longer than expected, and for failing. Your team goes from having 100 years of experience as Ruby developers to go down to 0 years of experience as Java ones. Everyone has to be trained into the new language, which requires training expenses, either explicitly by sending people to seminars and courses, or implicitly, via slower development cycles.
The team also loses its programming language dialect. A dialect is a social variation of a language. Natural languages, like English, Spanish, Korean, have regional dialects. As anyone who has studied Spanish knows, the accent, the grammar, and the vocabulary used in Spain, is different from the one spoken in Mexico or Bolivia. Most language learners are aware of the existence of dialects.
Computer languages also have dialects, yet we don't fully acknowledge them. We are aware of them, yet the technical bias tends to push our discussions of dialects as style or correctness discussions. Another way to talk about it is when we say that we need some time to ramp up on the codebase, even when we already know the language.
There is no such thing as readable code. There is only readable code in the context of a specific team. What is readable an understandable in one team can be this weird, unintelligable mess for someone else.
This also shows what the problem of "best practices" entails. It needs the social context for us to decide whether the practice makes sense in a team. The Toyota method works well in Japan. It famously fails in most implementations in the U.S. There are many reasons for this, but let me share two cultural reasons for why it fails. The first one is that high quality is a value that only some American managers hold. It is just as common to run into business leaders that prefer cheaper prices for their products. Or the ones that demand planned obsolescent. The second reason is that the Toyota executies trust front-line workers to stop the production line. American manager usually don't trust their employees to that extent. On the contrary, stories about front-line employees bringing up problems, only to be ignored by management are quite common.
I have gone this far giving examples without a definition for social context. Now that you have seen examples, I am ready to offer one. The social context includes the cultural backgrond of the founders, the personality of the leadership, the amount of money the company has, how many employees there are, and the personalities of the individuals involved. All of these should be consciously taken into consideration when making technical decisions, like adopting kanban, building a QA team, using kubernetes, or picking Erlang to build the product.
At the same time, I understand that this is too much to think about at once. So I offer a shortcut that can help us to bring the social context into technical decisions.
The next time someone suggests to adopt the next shiny process, ask "would it make sense to do it here right now?"