Errors in role definition ​

"If you read the word 'buffalo' on an elephant's cell, don't believe your eyes." This aphorism by Kozma Prutkov is fully applicable to project roles: we must identify them by words and actions, not rely on official job titles. Sometimes titles, of course, coincide with project roles. But more often than not, they do not. An agent with the title "programmer," for example, may turn out to be a technical writer for user manuals and may not know how to program at all. The same applies to self-designations; they can also be misleading. Only actions, only discussions of the subject area of a particular method of work (activity, culture, practice - there are a huge number of synonyms here) matter in a conversation.

If Prince Hamlet suddenly begins to ask, "Did you pray last night, Desdemona?" then it's no longer Prince Hamlet! It's Vasily Pupkin, who switched to another role (which one? At this moment, being well-informed is crucial! You might miss the moment when you're clearly told that someone's about to be strangled!).

At the unexpected moment of role switching for the performer/actor, it's useful to ask why they changed the discussed "subject of interest"/topic and took on a different role: you can learn a lot of interesting details. Most likely, this indicates that some new interest has emerged: Vasya Pupkin, an actor in your team, who was previously playing a role, remembered something important, and therefore switched roles, thus showing interest in another role. Don't forget to ask about the reason for changing the subject/"subject of interest"/"important discussed characteristic" when "people or AI" suddenly start changing roles in the course of a conversation. The positions of these agents do not matter, except to indicate the administrative authorities of the conversation participants. Position matters only when giving orders and determining stakes; it has no influence on thinking and acting!

Nevertheless, we remember that "they judge by appearances," and roles are often inferred from positions. Therefore, we recommend naming yourself as close as possible to your actual role. If you call yourself an "analyst," people will talk to you as someone who doesn't make decisions themselves but only "makes suggestions to management." If you call yourself an "engineer," people will talk to you as someone who makes decisions themselves, not just suggesting decisions for someone else.

Let's remind the main mistakes people make when defining external and internal (team) roles. If a student makes these mistakes (they are clearly listed here), they can confidently count on two points on the exam. If someone other than a student makes these mistakes, life will give them those two points:

• Instead of specifying a role, they name the performer – a specific person or unit (full name or unit/department/organizational link name), or even AI.
• Instead of a role, they name the "responsible party" (position, organizational unit, position in the staffing table), most often the "boss" (the mistake of listing "Theater Director" among the actors in "A Midsummer Night's Dream"). It can easily be identified by qualifiers like "lead," "chief," "manager"; these words in a role's title should be cause for alarm.
• They mention a title (academic degree, military rank) instead of a role, trying to indicate the level of expertise but not the type of expertise.
• They indicate the type of organization with many different roles (clinic, factory). For a medical project, stating "clinic" – means what working methods the clinic is engaged in, what are the important characteristics and preferences of this "super-role"? There are many people inside, they perform various methods of work in various roles, and among them, there will definitely be different preferences regarding the same characteristics of the same system, they cannot be mixed into one whole! Specify roles in large organizations in detail; the closer to specific professional roles, the better!
• They believe that one agent performing a role is one role. No, one performer/actor can play a dozen roles, whether it's about a person, AI, or an entire organization. However, a large unit or even many thousands of people can also fulfill one role (for example, the role of "player" in a game with two million players) or a complex network of many AI agents.
• They think that five external roles in a project are more than enough. No, it is usually counted in the tens. If only five external roles are identified, then there hasn't been enough thought put into it.
• They forget to consider their roles and interests. But you are also an agent participating in the project! What are you doing there, what are you aiming for (interests), what did you study for this, and do you have a high level of expertise in performing tasks with a certain method?
• They forget about the multitude of interests in the project role and the multitude of project roles that have one interest. However, the preferences in an important characteristic/subject of interest for these roles can differ. And there can be very different ways to implement these preferences: three actors performing the role of a doctor might be interested in arterial pressure and even agree that it urgently needs to be lowered, but then they offer three completely different ways to lower it! The saying about "two lawyers, three opinions" is just about that.
• They do not pay attention to the interest expressed in the current situation; they state the presumed interest from past or expected situations. There are no two identical projects, always clarify what is happening in your project, especially right now (as the project situation usually changes quickly: people are active!).
• They do not differentiate role subject interests, the interests/preferences themselves, do not anticipate the inevitable actions of agents in implementing their intentions to achieve the interests of their roles.

To understand the roles in the project, it's recommended to fill in a table with content like this. Here's an example of how to fill in such a table for a simple three-person development team meeting:

No. Role Role Method Performer Performer Position Performer Organization Performer Expertise Subject of Interest Preference/Interest Agent Strategy ("what they will do"/method) 1 Use Concept Developer Jobs to be done Dinara Programmer Development Department Novice Functionality Maximizing the number of features Interview everyone; if something wasn't clarified in the survey, come up with an answer 2 Visionary MVP Me Programmer Development Department Expert Functionality Minimizing the number of features Pushing for MVP, ignoring everything else 3 Operational Manager Estimation of work time based on Timur Department Head Development Department Novice Development time Minimizing development time Cutting features even in MVP

This table is intentionally designed to prompt questions that might be overlooked without it: to prevent confusion between roles and positions, think about the work method, and pay attention to the performers' expertise in specific roles. Managing attention to roles, subjects of interest, interests, and methods of interest realization during the meeting is an example of methodological (about work methods) thinking, a small part of it. Without this, there can be no systemic thinking because "the system is in the eyes of the beholder," and in this case, the viewer will be the role.

Whom else should have been invited to the meeting to discuss these subjects of interest fully? To answer this question, first and foremost, think about what roles may have different preferences in these important characteristics. Then, consider who::the agent can be an actor/performer of these roles. For example, an actor in the developer role who would provide an estimate of the development time for each proposed feature of the system could assist the actor in the operational management role in understanding their interest. To improve the results of the use concept developer role, invite someone more experienced rather than the current performer (since the current performer's expertise is "novice"). You could invite someone from the product promotion service (marketing) to better evaluate the MVP. The key is that this simple table can be completed in three minutes but helps with planning and better understanding the situation. In complex cases, such tables save months of fruitless conversations by unrelated people on unimportant topics.

Special attention must be paid to your own roles in such a table. Did you declare your roles, role interests at this meeting? Did you reveal your intentions, plans for realizing role interests? Did the meeting participants know what roles you played during the meeting if you did not explicitly state these roles?

Knowing the position and which organization you belong to is entirely unimportant; just like what roles you play outside the meeting. The crucial point is: during the meeting, did you behave in a certain way (according to the role)? What method/work approach did you use in your role? "None" and "common sense" is a very, very bad answer. It means that you did not play any role, acted arbitrarily, were not in the culture, did not demonstrate a style, and behaved like a "savage on a construction site." Did you help other meeting participants communicate better with you? For example, in the given scenario, did you clearly mention that you would use a method involving the concept of minimal viable product? Did you mention your preference for features relying on the MVP development method and provide arguments from the "MVP guide" (i.e., you provided culturally conditioned, role-based arguments, rather than personal opinions without a role)?

Did you respond in your presentations to the interests/preferences of other attending roles, showing an understanding of their subject interests and considering their plans for realizing their interests in your plans? Or did you just respond to "people" or positions, not actors-in-roles?

It is not necessary to build such a table in a written form in full at every meeting (remember that "chatting" is also a meeting!). However, initially, it will be more than useful to "think by writing," in this case, to simulate the situation with roles with documentation in the form of a table. At first, it might be difficult and time-consuming. For example, each agent might have three roles, and there could be a whole team of ten people at a meeting. Or there may be difficulties in identifying the role of AI. How to consider the role of AI? How does it work, who is the operator of this AI service (the role plays AI, or even not the creator but the operator of this AI, and the AI itself is its tool - like "the hammering" can be played by the carpenter Vasya or the hammer of the carpenter Vasya), because if something goes wrong, you will need to negotiate with the AI service provider, not the AI itself (with Vasya, not his hammer) - and not even with the role "provider" but with some sub-role because the "AI provider" can easily break down into many different roles, and negotiations will have to be made only with one of them, all played by different individuals or even entire company departments of the AI provider.

Thinking about roles and their methods will become easier over time to the point where you will do it "on the fly" and mentally. Of course, without some methodological/labor/activity/practical/engineering background, you will be unable to fill in such a table; for people without a wide-ranging perspective, what happens in the meeting will seem like magic based on the mutual agreements of the agents-participants. With the table, everything becomes transparent, the intrigue is clear, and actions that can be taken to improve the decision-making quality at such meetings can be easily identified.