Mastery as a System ​

In order for a client to be able to obtain the result of an organizational process performed by some organizational unit in their organizational role (for example, an internal client will be able to receive salary::money::system accrued::organizational process::behavior and issued::organizational process::behavior by the accounting department::organizational unit as the treasury::organizational role), the application/program/software::system needs to be configured, the necessary data needs to be obtained for it, employees need to be trained to work with this software as a tool (similarly to how a child is taught to drive nails with a hammer - nails not off the mark and the hammer not hitting the fingers, that's how the software is taught to be used), and then the system should be checked not just the software, but the operation of the entire organizational unit/service/provider as a whole, including the software provided to this organizational unit. The software seems to be part of the department like a hammer is part of some roofers' organizational unit, which will use it to build the roof of a building.

In the modern world, it may be the other way around, where the software acts as the organizational unit, and there will be some people included in its composition (operators, development team), but the work of not only the software will be required, but also the people included in its composition.**

Let’s repeat: no one is interested in the excellent performance of the payroll calculation program; what matters is the payroll calculation itself (it can be compared to dividing a certain lump of physical gold into parts designated for distribution to employees) - and if the payroll is not calculated, it will be difficult for the software development team to explain to the employees who have not received their salaries that everything is fine with their program, and that it is the other employees in the accounting department who are wrong, incorrectly filling in the fields of the program and pressing the wrong buttons. Employees don't care whether the software is inside the accounting department or the accounting department is inside the software - what matters to them is the end result of the software's operation!

If you invite an excavator to dig a trench, are you also inviting the excavator operator (the person playing the role of the excavator operator with his excavator)? Or are you inviting the excavator operator as a department consisting of one person, which includes the excavator together with him? I think it's easier for you to consider the excavator as a department, with an operator added to it, "software for excavator control, performed by a living computer." What matters is not the excavator operator himself, but the excavator, the expected result of the excavator! In an operating room, we usually care about the surgeon and the anesthesiologist, but in a computer tomography room, it's primarily about the tomograph; what about the rotating operator teams beside it - inside the tomograph subsystem, mainly consisting of the tomograph and a few people operating it.

If your company has AI agents or powerful server software that provides key results, it is usually unclear whether you attribute this software (including AI agents) to people, or vice versa - people to the software. In this sense, people are also "universal robots with specialized software inside to work with other software or equipment."

In projects for the development of programs/software/applications/digital twins, there is often a need to develop not only the software (traditional or neural network AI software) that exists in computers but also the neural network software that exists in the minds of people as information processors. This software/program, implementing an algorithm/theory/discipline of a working method as a physical object, would be called mastery of performing some "behavior/working method." "Behavior/working method" is the behavior of an agent (which consists of an organism and/or apparatus in the case of living human agents or somewhat living AI agents, as well as personality and/or software/programming tools as the sum of all software/programs working on this organism/apparatus), taken in terms of the behavior part of one's mastery of the personality, which helps the individual play a certain role. Roughly speaking:

• Human::agent = organism + personality (personality as a set of various kinds of skills, "all software, all programs for the brain")
• AI agent = apparatus + personality (personality as a set of various kinds of skills)
• Mastery::system = ordinary or neural network program::system, which operates based on the apparatus of an AI agent or a human organism, implementing the algorithm/theory of a method/way of operating.
• Method::behavior - a generalized algorithm/theory according to which the mastery operates, as well as the tools needed for the method to be performed (for example, for the method of digging trenches, in addition to the skill of digging trenches, you need to have a shovel or an excavator - tools that make the application of the skill possible).

In a corporate software development project, there will certainly be:

• consideration of the apparatus for this software ("hardware" or "virtual machine" - software containerization, considering that part of the software is executed on a server in a data center, while another part may be on a phone with a tiny screen, and so on - everywhere has its own, but the hardware must be considered!). The program works as part of the software-hardware complex, not on its own!
• the actual development of the target software, which everyone sees and recognizes.
• "making mastery in people's minds" (training to work with the program: you need to "make" those parts of various people in various roles who can do something useful with the program - manufacture the mastery of working with the program). Note that the bodies of these people, the "brains of people" must also be taken into account - if you were not given people, you will not be able to develop their mastery, just as you cannot with the hardware for "software-hardware complexes."
• Making mastery in AI agents (this is just emerging, but there will be its own specifics: you can't program present-day AI agents like software, and you can't train them like people, but you will need the mastery of working with your program from them)
• Making initial data (data engineering) and distributing them to different storage devices with which the program will work. The program itself will generate output data, and you also need to know where and how to place them.

Don't skip these parts! They are physical, they also need to be "engineered" and then "manufactured":

• the software itself is "developed" during software engineering,
• to make the mastery part of people's personality and AI agents, they must be taught (and develop ways in which this will happen, as well as methods for verifying the learning - details are covered in the "Personality Engineering" course),
• the additional classic software needs to be configured in terms of using its interfaces (and ensure that everything has been configured).

And what about the people who work with programs? Very often, the embodiment of the target system of the project will be some part of the organization that must perform some task - give credit, calculate wages, manufacture a part. And if it turns out that the program works according to its developers' view, but people in the organization cannot work with it for any reason, then the work of the program will not be counted as correct. What use is a payroll calculation program if people cannot use it? If programmers want to be paid for their work, they must be sure that someone is working with people, and surrendering to the customer will be a joint system of trained people and configured programs (as well as data for this program, which can be a separate issue and may require separate performers). Surrendering will be the calculated salary, the quality-manufactured part - and further down the chain, the work of the organizational unit leading to these important target results, and within this work of the organizational unit (department, project group), the software will be surrendered.

When educating people, consider similar reasoning to computer programs. Educational books, videos, computer courses (for example, our "Systems Engineering" course) are just documented descriptions of what you would like to get after learning. The goal of education is a piece of an educated brain, let's call it mastery::software::system, and it works (a system is always active when operational!). Mastery as a system is activated as part of an analogy with a computer program that gets activated when its call is made on the computer and produces the computations/thinking that were targeted during training. The brain is a computer, the mastery functions as a part of the processor. It doesn't matter which specific areas of the brain implement the mastery. What matters is that mastery is implemented by the brain, not the cosmos, extraterrestrial forces, spirits, or other less plausible reasons. Read books, watch videos just outline what is expected from the brain later, in the mastery utilization situation. Read books, watch videos, and complete exercises only educate the neural network, increasing the likelihood of a change in the state of thinking in the brain (with state changes!) according to the learning outcomes in the mastery utilization situation.

The only thing is that it is not necessary to talk about neurons and their learning; that is clearly not the level of detail (not the same system level, not the same system size) discussed in training. But the view of the learning outcome as educated for work in the operational conditions of the brain piece, called mastery, forces you to think through how this learning looks in the physical world (the brain location during education must be determined, data must be supplied, and thinking::computation results must be derived), as well as how the operation of the learning outcome as a system looks in the physical world (there must be an appropriate physical environment for mastery to be appropriate. The ability to perform a somersault in place is inappropriate underwater but is appropriate at the circus).

For example, at the moment of mastery utilization, a person may be in a machine shop, among the deafening noise of the surrounding machines. Will mastery activate (software/neural network program/educated brain part) without additional reminders? Will it deliver flawless and gap-free thinking in this environment, the type that they were taught? How much time will it take? What happens before that moment, what will happen after that moment? Transition to the physical system (the area of the brain that is ready to act/think) turns out to be productive even for the learning situation. In learning, there are many descriptions, but they are not the most important. The resulting physical object is the most important: a system with its prescribed properties and known behavior during utilization.

What is the target system of a bridge construction project? The bridge, of course! But to build a bridge, you need to create a project organization that will carry out its creation, then work on this organization in terms of design (usually in the city, at the design institute), then in terms of construction (several thousand people in an open field!), and only then can you enjoy the bridge. This is all the chain of creation: create the creator, then the creator creates the target system. These can be not only chains but more branched graphs, where there may be many links (creator of the creator of the creator). Imagine, for example, any of the programming projects, of which there are many in the context of building a bridge. Why do they exist? Why all this software? To eventually get the bridge!

Systems thinking requires tracking the entire chain from the software used in the bridge construction project to the bridge itself. If you fail to track, then the software proves unnecessary - even though developers are eager to charge for it, especially for unnecessary "features"/capabilities of this software. If the software's capabilities are not used, they may not work as intended, but payment will still be made if you successfully hide the connection of these software capabilities to the implementation of the target bridge. And if it turns out that the software's capabilities are not relevant for the bridge, that the software is not needed, that the software project is not worth the trouble, then don't pay for it. Systems thinking will check if you are wasting effort on work that is not needed.

Systems thinking forces you to think about all of this at once, and not at the moment of signing the acceptance documents for the "software development" project. Usually, programs as systems by themselves are not needed by anyone; they are needed only as parts of some other systems - you need to make sure that the development focuses on these other systems first and foremost, and the programs only as parts of these systems or as parts of systems that make these target systems - you need to understand all the chains leading to reality, to the physical world. Do not confuse the photograph with the subject shown in the photograph, the book with the living world described in the book, the software with the real world described and changed by the software.