Thinking About Humans: First of All They Are Role Performers

Of course, in real life we see first of all the performers-actors-people, not “roles”. But in the course of a play, we only discuss the roles, unless we are talking about the quality of the performance!

Who says the phrase "to be or not to be? Prince Hamlet or Joe Shmoe? At the moment of acting, they are both the same object, only they have different names and we pay attention to different properties of this object depending on this. When we are talking about the “character” we pay attention to the text and plot of the play (the activities/practices—the situational context in the project), and when we are talking about the “performer” we pay attention to the quality of the performance and the availability of the performer at the moment of the performance.

We can always point out to Joe Shmoe that he didn’t learn the part well, or plays someone else’s part, and in any other way make it clear that “you’re wrong, Joe” if we know the play he’s playing. If the play is unknown, we cannot understand whether Joe is right or wrong in his actions.

Therefore, systems thinking requires an outlook—a minimal understanding of how the activities/practices/plays of an engineer, manager, entrepreneur, and other enlarged roles in different spheres of activity are arranged. In 1997, A.Tyukov singled out the following spheres of activity: politics, religion, philosophy, art, science, education, public health care, physical training and sports, technology, design, commerce, finances, law, army, material production, and “enlightenment, which has not yet taken shape [1]” No outlook means no systems thinking, because it is transdisciplinary and is called to combine the role thinking of these separate spheres of activity.

We recommend having an “outlook knowledge” of at least the following activities/practices of modern engineering, management, of the entrepreneurial world:

  1. systems engineering (conceptual design, requirements engineering, engineering of systems architecture, configuration and change/life cycle management, verification and validation). Systems engineering practices the role of the systems engineer, which in turn is divided into a subset of the individual engineering specialties (conceptual designer, requirements engineer, systems architect, configuration/life cycle manager, and V&V engineer);
  2. systems management (operations management/supply chain/logistics, management accounting and controlling, enterprise engineering and enterprise architecture/technology management, organizational changes/development and systems leadership). Systems management is concerned in general with the role of the manager, but it is also divided into sub-fields (operations manager/logistician, financial manager, enterprise engineer, organizer/leader);
  3. system entrepreneurship (strategy, product promotion, corporate finance, corporate oversight/governance). And here the role of the entrepreneur is also divided into sub-sections (strategist, marketer/salesman—there is a whole bunch of different roles, financial manager, representative of the owner);
  4. the other spheres of activity (politics and political economy, religion, art, science, education and enlightenment, health care, sports, law, the army, private life/family). In each of these activities, too, it is possible to identify a role that is engaged in that activity and many sub-roles (e.g. in sports, it is easy to identify the roles of an athlete, a judge, a competition organizer, a coach, and many different other roles. If you are involved in sports, you need to have the horizon to recognize all the activities/practices of these roles, to know their concerns and preferences in order to participate adequately with them in the overall work of the project).

In systems thinking, we must always think about people’s project/activity roles: determine from the context what kind of play/type of project the people we meet are playing, and what roles these people play in that play/type of project. It should be a constantly functioning thought process, a constant thought effort—conscious and difficult at first, and then a thought automatism. We need to learn to see people as characters, to stop seeing them as role-players: we need to see Prince Hamlets, and not Joe Shmoes playing them. This requires a cultural/professional outlook, an awareness of the existence of basic activities/practices encountered in various plays/types of projects and their typical roles/stakeholders/concerned parties.

If we do not know about the activity/play/practice being played out in front of us, then we cannot evaluate the actions of these people (they will seem a personal whim), plan our actions (they will not matter to people-in-role, for they lie outside their role concerns, are literally uninteresting, will have no relation to their preferences in concerns), cannot play our roles in the play they’re playing (because we’ll be uncultured, “haven’t learned the part”, haven’t read any books, don’t know how to do it normally)—and without that they just won’t understand us! And we must not confuse Prince Hamlet and Joe Shmoe in any way! We should not address Prince Hamlet as Ophelia—the performer of the role will simply not know what to do and instead of working on the project will be a “small talk” with sorting things out and (proper) rebukes of unprofessionalism.

It’s a very difficult skill (seeing people’s roles and noting what practice they do, what variant of practice from what handbooks they play in those roles), but it’s a necessary one. It’s the first thing that systems thinking begins with. This means that you as system thinkers have to answer at any given moment—what role the person is playing now in front of you (what stakeholder), what is his role concern, what is his role preference in this concern, and answer to this role (and not the person performing the role!) accordingly, while taking some (your own) role in the play he plays—also becoming an character, not remaining just a performer. If you don’t play your part in his play, you will simply be invisible to him, your statements will have no meaning for him, you will be an “extra from the crowd” for him, the person-in-role will not be interested in communicating with you, nobody talks to extras.

It is especially difficult to play one’s own activity role rather than someone else’s (let’s call this skill role-playing, by analogy with acting). Sitting quietly and “understanding everything about other roles” (this is usually the job of an analyst) is only half the battle. After understanding, you also need to act (become “syntheticist” rather than analytic), presenting your role concern and role preference and manifesting in the activity a role intention to achieve your goals of preference realization. Of course, you can have multiple roles (especially in small projects where it’s always “one-actor theater”), but it’s best to label both for yourself and for others when you move from one role to another. This needs to be trained, to raise your role acting skills (in which you can highlight self collectedness as reliable attention management and role outlook, so as not to get into trouble by not noticing some culturally conditioned activity, culturally conditioned role).

There are a lot of difficulties here. For example, when someone yells at you, it is simply impossible to concentrate—you see only the person who is executing and his attitude toward you. But this “impossible to concentrate” only means that you are close to a thinking error: you have stopped thinking systematically, have returned to the thinking of a savage led by emotions—you see people only as actors/performers, you do not consider civilization’s knowledge of activities and roles in them. You are losing your professional outlook, you cannot fit your role competencies into these or those activities, you cannot take into account your role concern and realize your role preference in this concern because you do not notice role concerns and do not understand the role preferences of people-as-stakeholders, people-in-role.

It is important that all discussions in the project take place in terms of “characters” not performers. Compare the two dialogues:

  1. “Executive/performance” discussion, in terms of personalities:
  • Smith screwed up the drawings again! He sends them in .dwg format and refers to Johnson! Helen can’t work!
  • And what does Staininstsupport think about it?
  • He doesn’t care as long as Preptradedepot doesn’t mind!

Does everything make sense to you if you happen to be in a meeting? Can you ask any clarifying questions about misunderstandings—and what kind of questions? If you know all the characters well, can you predict in any way their expected reactions in this situation?

  1. Role discussion (“characters”, in terms of roles/stakeholders/concerned parties):

— The designer messed up the drawings again! He sends them in .dwg format and refers to the technical calculator! The archivist can’t work!

— What does the manufacturer’s technologist think about it?

— He doesn’t care as long as the hull supplier doesn’t mind!

Does it become clearer what you are talking about? What clarifying questions would you ask? Here’s another example where we name the performer by his or her job title, not by his or her role:

Senior Programmer says: When I looked at our project schedule yesterday, I realized that we might not have enough time for testing, so it’s a good idea to be concerned about ordering additional servers for this work.

Options for continuing the conversation (which one will you choose?):

  • Engineering: which bugs require additional servers to test them? Can we reduce the amount of testing? [and estimate the likelihood that the “senior programmer” didn’t think about these questions when she made her statement];
  • Managerial: Are we budgeted for this, or is it just like always? Do you have a draft contract to order new servers? Who’s going to find the vendor? [and estimate the likelihood that the “senior programmer” doesn’t really know the answers to these questions].

Is it to be believed that the “senior programmer” wants to discuss the engineering aspects of the case, did she really come forward as a programmer? Or did she act as a manager?

What line of conversation would you take: what would you be concerned about, what would you ask?

What would you do in this conversation (which competency would you pull out as your main competency?).

Think back to the last time you did this kind of role-playing in a conversation “who and what is he talking about—who and what should he be talking about”?

Do you keep track of changing subjects of conversation (changing concerns in the discussion)? Does this mean to you that people have switched roles, or pulled out their other concerns for discussion? How long (in hours!) can you keep your attention on the dialogue—at any given moment understanding “who (which role) is talking—who (which role) is responding—the subject/concern discussed, what the roles’ (not the role performers’) preferences of concern are”?

Discussion in terms of "characters’’ (understanding project roles as role/functional "actors’’ rather than specific personalities/performers, physical objects-people or people-in-organizational-position) is essential to communication: such discussion guides thought and allows us to understand which “plays” are now being discussed-what lines might follow, not just what lines are following right now. If some Prince Hamlet suddenly starts saying Ophelia’s lines, then we can continue discussing whether he saves the play because Ophelia fails to appear, or simply spoils the case as an incompetent actor-performer and should be immediately replaced as Hamlet, fired from the play and assigned another actor who is more competent in his role or at least more attentive.

When there is activity in process, it is better to call people by their project roles, not by their last names or the names of their organizations. The hardest case is when people in a project know the importance of some Mr. Brown (he definitely performs a project role! He has a significant impact on the project! He is the boss!), but cannot name his activity role in the project, do not understand what kind of practice/activity he performs and how qualified he is in this practice, do not understand his role concerns and his role preferences, do not understand the quality of his thinking in role practice. The intentions of Mr. Brown are therefore “incalculable” for the people in the project, they do not know what to expect from him, how to react to his actions. This happens most often with bosses, people in positions of authority, about whose authority to manage labor and resources one can talk long and much, but their thinking, their practices, their roles-it is impossible to say this about them, knowledge of the industrial culture is powerless here. And the question of these people’s professional roles in the project, what their role concerns and preferences are, what they can do besides pushing something through with often significant power, must be specifically examined. They often look like managers, but are usually very narrow specialists in engineering or entrepreneurship, and even quite rarely in management, when it comes to their role work. The rest of the time, they just authorize other people’s role-work with their authority (formally checking that the rest of the project participants have no objections—but chat voting can do that too, no need for chat to be the boss for that!).

[1] Программа создания общественной профессиональной сферы просвещения - Психология и методология образования (in Russian)

*An excerpt from Systems Thinking course

1 лайк