Cultural conditioning of project roles ​

Our main interest is in thinking techniques, especially in preserving experience - transferring experience from one situation to another, from one project to another. Thinking is not so much about facts as it is about knowledge: abstracted from facts about specific physical objects, knowledge about what is most important. "The physical body" abstracts a vast number of situations in which the laws of mechanics operate: from the flight of a spaceship to the Moon to throwing a ball into a basketball hoop. "The target system" abstracts a vast number of situations in which systems are created and developed - from the project to release a smartphone to the construction of a city block.

When intelligence encounters a situation it has not encountered before, it needs to identify some focal points in this situation that would allow it to anchor and try some familiar thinking moves that provide maximum expected performance, rather than just random moves with inherently low performance. These modes of thinking should help find explanations for what is happening in the situation until new information can be obtained and adjustments can be made. Systems thinking is part of this common knowledge of the methods of the intellect stack.

Knowledge of work methods and the roles that activate them (methodology), normative division of labor, i.e. normative division of engineering into separate engineering methods and assigning them to different agents in different roles in the course of creating and developing systems (system engineering) - is also part of this common knowledge. This knowledge is significantly enhanced by work experience - an understanding of how project division of labor can be organized for different types of systems being created (dividing the engineering of certain types of systems into types of methods of that engineering and further appointing roles that perform these methods to different agents). For "hardware" and software engineering, roles such as visionary, developer, architect, and internal plant engineer are identified. For learning (personal engineering), similar roles may exist, but they work with slightly different methods, characteristic of creating and developing expertise as a target system. These are roles such as cultural bearer, course material author, educational program architect, and dean. For management (organizational engineering), roles such as businessman, organizer, org architect, administrator, who use methods with the organization as a target system, work with it. Of course, all these roles, along with the methods of their work through the division of labor, are further divided into more specialized roles and methods.

Knowledge of effective and efficient work methods and the proper execution of this method in a professional/work/project role, successfully tested by a variety of agents in many projects - is culturally conditioned, that is, it is not reinvented in each specific situation. The systemic approach directly turns to the knowledge of civilization, that is, to the culture accumulated by humanity. The term "culture" has two main meanings:

• The method of work, "culture as cultural behavior" in a long synonymous range "method/way of working/culture/style/practice/activity/work".
• a set of human (and now more than human) knowledge about the world and material/constructive objects ("material culture") with artificial (that is, created by people, and now by robots) origin.

Here we are talking about how the systemic approach uses the accumulated knowledge of humanity about methods of work and the roles that implement them, without reinventing everything from scratch in each project. If you do not know which methods are needed to achieve certain results and therefore the agents you will need in which roles - you can google it or ask an AI assistant. So, if you need to feed someone not at a restaurant, but right on the spot - that's catering, and if you need to organize a festival - that's event management, and they even teach this in universities. Of course, you can figure something out on your own, but it will be amateurish feeding, an amateur festival. The difference will be that professional performance of a role is stable and under different inevitable surprises it will produce results, whereas amateur performance is not very stable, sometimes achieving the same level of results as professional performance, and sometimes completely failing with minor changes in the environment. Professionals do not make rookie mistakes.

The use of a systemic approach implies some work/applied work/traditional work perspective: if you are not familiar with the culture, you will not see what roles people play in relation to the project - their important characteristics will seem unimportant to you, and preferences will seem to you as whims, the personal characteristics of the agent, and will not be recognized as civilizational, culturally conditioned, role-related subjects of interest and the preferences associated with them. If you do not know from the textbook that the roles of developer and architect usually conflict, you will be surprised why there are "production conflicts" around some agents performing these roles for very different systems (and their positions will be called by completely different names), depending on the communication style these conflicts may turn into personal ones or not, but for those unfamiliar with modern systems engineering and management, these conflicts will be inexplicable. And if you are familiar with the explanations of modern development methods and the roles in them, then you will know what to do. If you know how to turn almost any customizable software into a universal modeler - you will know how to easily and quickly perform organizational modeling in an organization. If you don't know - success will be purely accidental.

If you encounter Vasya::agent, who is interested in the strength of the system::characteristic (structural strength::"important characteristic"/"subject of interest"), this is unlikely to be Vasya performing management::method/practice in the role of manager::role. Talking to Vasya about deadlines::"subject of interest" and budgets::"subject of interest" may be unproductive, not the project role and its working method. Conversely, if someone refuses to discuss the specifics of the structure but is willing to talk for hours about the resources for work, the cost of those resources, the approximate completion times of the work - that is a manager.

You should have a work/applied perspective, you should be familiar with a variety of work methods, recognize many roles in your projects, which go through these methods/protocols/scenarios, and know their subjects of interest/important characteristics of systems and projects and the preferences/interests they will carry out in the project regarding these subjects of interest. These courses will help you achieve it: systems engineering, personality engineering, systems management (organizational engineering), but of course, these courses are not enough. At the same time, "work experience" might not help if "twenty years of experience is a one-year experience repeated twenty times." In terms of perspective, diversity is important in understanding the roles in your project.

Recognition of these roles in work projects should be detailed! Not confusing a gynecologist and a dentist, considering them "just doctors," you should not confuse different types of roles, not only in medicine but in all other methods/practices/"work cultures"/"engineering types"/activities. If you lack a methodological/work/practical/cultural/stylistic perspective, you will have significant difficulties in systemic thinking: you will not be able to adjust the roles in your project.

Professional (methodologically, i.e. by work methods in the project, not by positions!) roles are not made up. They are culturally conditioned. If you are not familiar with the work/production culture, it will be difficult for you: agents' actions in the project may seem unpredictable and random. But this is not the case. People's actions (i.e., work by some methods) take place "in roles" - they are absolutely not random, easy to predict. If you know Shakespeare's play, you will not be surprised by the fact that a Moor strangles someone there after being asked to pray for the night - a Moor is not a person, a person-in-role acts in the role, not composing actions "instinctively and situationally."** There is a pattern in their actions, and it will manifest. If you do not know Shakespeare's plays, you will be surprised by the appearance of the Moor itself and each subsequent phrase.

Activity/practice/work/engineering/method is distinguished from random individual operations and actions with the objects at hand - to bring certain random characteristics of them to randomly selected preferred states. Activity/practice/work/engineering/method - is deliberate, in some way analogous/repetitive/patterned actions/works of agents of diverse backgrounds, which we consider as actors with role-based (i.e., standard, per role) deliberate behavior in accordance with their preferences in the subjects of their role/functional interest.

Engineering is in a general synonymous range because it is associated with changing the world, that is, creating new or developing/examining existing systems. Also, take note that we intentionally did not include the word "work" here, as the synonym for "work" is not "activity" but "actions". This difference between the methods/practices/ways/workings/patterns of these practices and the works themselves (the actual instance of work with their resources, in isolation from the "how") was briefly discussed in our Systems Thinking course, but it will be further elucidated in the Methodology course. Work/practice/work/engineering - these are synonyms for the method, the way of performing work; these terms do not refer to the use of resources at the moment of work, but rather refer to behavioral patterns, "how different types of objects interact to achieve the intended states of specific objects in the end." Works are associated with "operational management" as "the operational engineering of the enterprise", and for inanimate systems - operational engineering, where it doesn't matter how the system operates specifically, but the specific time of its operation, the system's instance (if the system can be replaced during repair), and other asset management aspects, which is also a management method. Work is logistics and resources (to ensure everything is timely and not lost), work methods - to do everything right, substantive engineering consideration.

Furthermore, when discussing methods/practices/workflows, we are actually talking about creators in the creation graphs of target systems, often these are people, and people are complex in conversation. When it comes to inanimate target systems, the conversation becomes simpler, and instead of lengthy synonymous series, we often talk about functions and functional objects. Sometimes functional objects are also called "tags", as in hardware engineering, tags with function codes are often attached to structural objects (for example, these codes are taken from ISO 81346).

The discussion on agents as actors who follow a method (or perform practical/work/engineering roles - just different lexical ways of saying the same thing) is very similar to role-playing games that are popular among specific hobbyist communities of "role-players". Although the first association is a play in theatrical plays. The main difference is that in theatrical plays, all characters/roles/performers speak the author-written lines at specified moments (they follow the play/script), and in role-playing games, the characters/roles/performers define their actions and lines, based on the current situation and some principles (the same script