Is Poland Christ of Nations?

Table of Contents

I recently came across a very interesting article about the pitfalls of the Polish style of management and its historical roots. It is more generic than just IT but includes aspects of participatory management, such as Agile practices. If you understand Polish, you can read the article here.

For others, here are the main points from the article:

  • The current Polish mentality stems from historical circumstances. Starting from the 16th century, Poland was mainly a food supplier for countries in Western Europe. This had a significant impact on internal societal relationships, manifesting as a master-slave relationship between “big” landowners and individual farmers.

  • Farm mentality was focused mainly on survival, which wasn’t sufficient when capitalism became mainstream, where profit is the organization’s most crucial goal.

  • The master-slave relationship leads to compliance but sacrifices creativity, which is crucial in capitalism.

  • Most Polish companies, even international ones with local branches, fall into this schema. In Western divisions, vision, mission, people, and values are respected, but in Poland, it often reverts to a master-slave mentality. Top managers are the masters, and subordinates must be obedient or face punishment. There is little room for participatory management, such as Agile. People in such environments don’t take full responsibility for their work, unlike in places like Scandinavia.

I find similarities in this master-slave mentality in other Central European countries (Czech Republic, Hungary, Ukraine, Lithuania, etc.).

I enjoy such articles because they broaden my perspective and understanding of the surrounding reality. However, I am cautious because it is easy to abuse historical narratives and the consequences of different historical circumstances, as they are more complex than simple or complicated issues. Here is my point of view from personal experience dealing with various, mostly Polish companies.

Based on the article, we might conclude that Agile mentality is not very compatible with the Polish master-slave mentality. This is evident in many big companies (corporations) where their version of Agile is not truly Agile. Smaller companies aren’t much better. I’ve seen only a few companies fully embrace the Agile mentality.

On the other hand, I wonder if it is solely a Polish problem. Our industry is international, nearly global, and the master-slave mentality is common in other countries as well, known as command-and-control management. Transforming this mentality to Agile is difficult worldwide, including in the US, UK, and France. These countries might have a slightly easier time due to a bit more openness and trust in people compared to Poland.

What also comes to mind is the Nonviolent Communication movement, which offers an alternative to so-called violent communication, where there is an assumption of rightness and wrongness, linked to master-slave mentality. This methodology was developed in the US, not Poland.

Therefore, I wouldn’t overvalue the hypothesis that the specific Polish historical background is crucial, as the described problems are not uniquely Polish. I believe it had an important influence on the Polish mentality, but many more social, historical, financial, and anthropological processes have shaped the current situation. This may make it slightly more challenging to implement participatory management practices, like Agile, in Poland compared to some Western countries, but it does not make Poland special as described in the article.

I view this differently. The 20th century was when humanism began to flourish (emphasizing the importance of people), and it is one root cause of the shift from command-and-control to self-organizing management. Every country has its history and background that supported command-and-control thinking (force-based). The article tells a Polish story, but other countries have theirs with varying influences, both stronger and weaker.

On the other hand, to employ participatory management (e.g., Agile), a supportive mentality is required (such as the Japanese Samurai mentality or Scandinavian openness and trust) to ease the process.

(Poland As Christ of nations is a Polish cultural concept from the 19th century suggesting Poland is chosen to suffer for other nations; more information can be found here.)

(Text translated and moved from original old blog automatically by AI. May contain inaccuracies.)

Related Posts

The Natural Order of Refactoring Under the Microscope Part 3: Extract Method

Analyzing Class and Method Responsibilities

In the next step, we examine the responsibilities of individual classes and methods, checking if they align with the intended responsibility of the class. It is best to analyze all methods and group them based on performing similar operations. We look for a place for these in other classes or a new class. Remember: if there is a significant private method in a class (longer than 3-4 lines), it should be moved to another class.

Read More

A Few Words About Naming – Methods (In Progress)

Note: This article is a work in progress!

Maybe the topic seems trivial and worn-out, as everyone knows that you need to create clear, unambiguous names. However, it’s still a greatly neglected area. Teams are still far from understanding that the most depends on naming. No refactoring has as much power as changing a name. It is primarily the names, if used correctly, that form what is called self-documenting code, creating a clear language in the source code of the system you are building.

Read More

Natural Order of Refactoring Explored Part 2: Compose Method

Compose Method

Analyzing methods, such as the one presented in Part 1, often leads us to understand the main points of the algorithm contained in them. This insight paves the way for the next step: try to split a large method into smaller steps by extracting them into separate methods (refactoring using the Extract Method). Thus, the original method will consist of a sequence of calls to these new methods. With the right naming conventions, you can achieve code that reads like a book.

Read More