Roles of analysts and engineers. Positions ​

The roles of creators are performed by various agents-organisations: actors/practitioners/agents/engineers/workers. They all change the world for the better, creating and developing various target systems. Practitioners are not observer-witnesses in the everyday sense, like in physics! Even in physics, it has been concluded that there are no observers who do not change the world. In order to "observe" something, that is, to measure, the measuring instrument must interact with the system being measured. In physics, the observer can be not an agent in the narrow sense (a person or AI capable of planning), but in the framework of minimal physicalism - some molecule that is measuring its environment. However, we will discuss situations where "observer" or even "analyst" means an active agent who conducts measurements ("observes") and even makes judgments about the situation but does not take measures to change the situation for the better. Remember that for the observer or analyst, the result of observation (although he himself can be very active, for example, climb a tall pine tree to look at the world through binoculars) will be some description, "analytical report," a month of intensive work by an analyst. This report usually includes an evaluation of the situation but lacks a strategy (a methodology that will help improve the situation) and, more importantly, lacks a constructive plan of action to change the situation (the "recommendations" part is rarely included in the "analytical report," usually "spoken" separately, informally, not included in the analyst's work), and most importantly - apart from the report and optional strategy recommendations, there are no actual active actions by the agent to change the situation (in other words, no physical actions to change the state of systems, possibly following a graph of creation) for the better, everything is restricted to "projects": descriptions of possible futures without active work to bring these descriptions to life, and the descriptions of possible futures may well be utopian, and the responsibility for implementing these utopias seems to lie with the analyst who suggested them.

Observers/analysts usually do not change anything in the world, although they may have a subject of their role interest (a characteristic that they consider important for the objects they observe) at the "curious" level, and may even have preferences in this subject of interest, but the observer-analyst role does not have the intention to be more **than just an observer, but to change something in the situation observed by him for the better. Real intentions of change are not present in mere observers. Observers usually view the activities in projects as "TV shows." Activities in projects do not change when performed by observers specially designated for analytical work so apart from providing understanding, nothing much changes in the project, they risk introducing a distorted version of the thoughts of the real practitioners/actors for the audience. In football, there are many people who watch the game from the stands with curiosity, but the results of the game depend only on the players running on the field and kicking the ball, as well as those who "made" these players (coaches, masseurs, sports doctors). Many of these "armchair analysts" know better what the players should do and how to prepare the team! But their opinion has little influence, although they are the loudest in the stadium, the players usually run across the field quietly and shout at each other very rarely. And no one hears the coach's shouts at all.

In this sense, "analysts" are usually similar to ordinary "fans": they don't need to do anything; they just need to understand something and prepare an "objective report". In rare cases, they may even make a "proposal" for subsequent "approval". These "proposals", which are later "approved" by someone, are a sure sign that we are dealing with an analyst, not an engineer/practitioner. An engineer issues "project documentation"; he does not "propose issuance," which another engineer as a "chief" must later approve! If the matter goes through a designated analyst and not an engineer, then:

• The analyst has nothing at stake, he only "proposes," meaning his suggestions are of lower quality than those of an engineer-practitioner who risks something^[1]. However, the analyst may be called an "engineer" by position, but we look at the working method, "what does he do, what changes states in his work, how this change of states occurs," to determine the role, rather than looking at the job title or the self-designation. The working method alone determines the role! If the method is "making recommendations" and not "issuing accepted engineering decisions," if it is not about "design," then we are dealing with an analyst. Have you made any "proposals" that others had to approve prior to implementation? Then, you are an analyst.
• Analysts often closely study a situation, then provide a highly compressed description (model) of it to the developer-practitioners. Here lies the broken telephone problem: just as the description of a situation can significantly distort it, reading a model of the situation can also be erroneous. Division of labor is important, but "analysts" like "requirements engineers" have disappeared from life because the broken telephone problem turned out to be serious (more about this will be discussed in the "Systems Engineering" course).
• This is extremely slow because of cascading, adding an extra waiting period for communication between superiors and subordinates at multiple levels. "Proposal-approval" instead of independently "releasing a solution" at four levels, with a week allotted for considering proposals - and that's three extra weeks added to the project. If the order is to "make proposals" and it is passed down the line, then add another three weeks for four levels, totaling six weeks. Four levels - general, deputy, department head, and immediate executor. Cascading in large organizations adds even more time, making everything move even slower there.

Sometimes, a lack of preference for certain interests ("objective," research-oriented view) is declared for an Analyst role - the performing role of an analyst typically does not have the intention to change life to realize a preference, nor is there a correlated role synthesizer, at least synthesizing the description of a solution. Synthesis is the reverse of decomposition/analysis operation, usually involving designing affords to be assembled into a system, invention, and then manufacturing of the system "in physics" according to the synthesized project/design. By including both analysis and synthesis, engineering does not exist without synthesis! In our course "Systems Thinking," we do not discuss "system analysis," and this is intentional! The course is not for analysts who describe the world but for practitioners - engineers of various systems (cyber-physical, organisms, personalities, collectives, communities) who change the world for the better!

In a classic case, an "analyst" role of "creator of analytical report" may take time and resources to "observe"; they must conduct "measurements" and interviews. For example, if they have to run from the stands to interview football players on the field. This can sometimes be beneficial: they may inadvertently ask something that didn't occur to the player they are talking to - and incidental benefit may be achieved! However, more often than not, it does not produce benefits if it is not followed by "synthesis." But if there is "synthesis," then it would not be termed an "analyst"; it would have a different name.

If a person playing the role of an analyst suggests, such as a recommendation - they are no longer an "analyst"; they are a "synthesizer," recommending creating solutions, making engineering decisions (not just interpretation), and this is not analytical work but synthetic!

Positions are often derived from typical roles. If the position is "analyst", do not expect individuals in these positions to perform synthetic work. If it is done, it is done against cultural agreements. This does not mean that there is no such method as "system analysis," but the person performing this role of "analyst" would have been better suited to be assigned to the same person who performs system/module synthesis work, and the engineer should have the authority and responsibility for decision-making in synthesis, not just for understanding and verification. Action-oriented approach: "understood/explained- do, in other words, take what has been understood/explained seriously, and change the world based on that!"

If something in a system or project bothers or pleases an actor who is dealing with this system, they start taking proactive steps, "exploring through actions," "actively probing," but they do not "actively observe/measure"; they implement their preferences, attempting to change the situation while following the method of their role. In addition, an actor can switch between different roles, implementing a strategy/activity of realizing their intention^[2]. And if an actor playing a role does not take any action to realize their interest/preference in an important characteristic as a subject of interest - then they are simply not considered in the project. They are a passerby, a casual person in the project, then they have no project role, no actions as per the role, they are not part of any link in the creation chain impacting the target system or the systems in the creation graph. If someone simply walks past the window of a design office, they are clearly not playing any project role in the project that the design office is working on, even though we may see such a person (especially in the absence of focus, and attention wanders around random objects). But if a potential buyer of the system walks past and can contribute to the project's success with their money, we will try to lure them and consider their interests.

Usually, agents (such as people) engage in their routine activities/work in a familiar role, and then a new system appears in their life (or could appear) - for some, this system presents new opportunities (e.g., providing new "features" to users/roles or team developers/roles who are excited about the new project as an opportunity to continue the system's development with endless improved iterations), and for some, it poses a threat (these people will play the roles of competitors or supporters of a particular political or religious idea - do not doubt, they will actively play these roles and resourcefully implement their preferences). Agents whose lives involve a new system-opportunity or system-threat start holding onto this new system in their attention - they take action, change the world to either use the opportunity or eliminate the threat.

Of course, the material about "analysts" vs. "engineers" is more suited for the "Systems Management" course, but it is illustrative enough to show the relationship between working methods, roles, and positions precisely on this example. In any case, whether for positions or roles, the wise words of Kozma Prutkov^[3] should be remembered: "If you read the inscription 'buffalo' on the elephant's cage - don’t believe your eyes." So, what to trust? Learn about the roles from actions/working methods used in those actions; assess the use of terms in the theory/discipline/knowledge methods in speech.

    Now you see the translation of the original text from Russian into English. Let me know if you need any edits or further translations.