Ways to manipulate expert opinion

Who are the experts?

Modern projects are mostly complex. If it seems to you that the project is simple, then you, most likely, either do not have the full set of necessary information, or use ready-made technological “building blocks”, or you are an expert. A technical expert is someone who understands technologies and how to apply them well enough that his advice or his actions have a positive effect on the project in terms of the quality of results, risks, budgets and other design parameters. Usually, a technical expert grows (or rather sprouts) “from the inside” of his industry. Technical experts from academia, from financial circles, from a number of armchair managers in the wild are almost not found. Exceptions are so rare that it is easier to assume that we are dealing with another imitator charlatan. Rare Ostap Bender will miss the opportunity to powder the brains of provincial chess players, to devour for free and cut down the lungs some money. But in this article we will not talk about charlatans, but focus on the vital activity of real experts.

The help of a technical expert in projects comes down to the following set of actions performed in any combination:

• Information support decision making by the client. This includes the preparation of analytical notes, presentations (including their conduct), expert opinions, etc., as well as personal participation in meetings, conferences, exhibitions and other face-to-face events held by the client.
• Quality control of technical projects. As a rule, this includes work with TZ, project documentation, charts, etc. up to the analysis of profiles and resumes of team members.
• Direct participation in the development of design solutions, from participation in brainstorming to the development of project documentation (or coordination of this activity).
• Transfer of knowledge, mentoring, implementation of best practices. It happens that people themselves want to learn how to do something better. Most often this is what their superiors want. However, certain expectations are placed on the technical expert.

For the above actions, the expert gets paid. Very often, an expert is invited to one role, but then they try to force them to perform other roles from the list. Sometimes this is done intentionally in order to get a job for free, but most often it happens involuntarily as confidence in the expert increases. This should be appreciated and be ready to perform the maximum of the proposed work. Of course, expert's remuneration schemes should be flexible and should provide for such situations (for example, be hourly, as with lawyers). If the expert is internal (poor guy at the rate), then the list of his duties is formed naturally during the project and naturally grows constantly. That, however, rarely affects his income.

When a technical expert is invited to the project, it is assumed that he is already “ready”, and he knows everything that is required. No one cares about the price at which the expert got his knowledge, the expenses that he incurred, the time he spent on training, studying the documentation and systematizing the experience. Experts should not forget about this when discussing the amount of remuneration for their work, which the customer seeks to calculate at the "average hospital" rate for specialists from any recruiting site like HH.
')
In order not to go too far from the topic, hereinafter, we will assume that the expert is well-motivated to do his job qualitatively.

Why would anyone manipulate expert opinion?

Despite the fact that this question sounds somewhat naive, it is important to very well understand the causes of people's actions. It is no secret that technical people rarely have the proper level of empathy and developed emotional intelligence, which allows them to act confidently in a complex relationship within the project team. Techies tend to overly rationalize the behavior of other people, seek (or even invent) the causes of certain actions, suggesting that all key participants act solely in the interests of the goals and objectives of the project. Generally speaking, from the fact that the expert acts in the interests of the project, it does not at all follow that other participants in the project adhere to the same practice. People are mostly irrational, subject to emotions. If they make rational decisions, it is far from a fact that their rationality extends to the project. People always do things in their own individual context, consisting of many layers - previous events, relationships with others, character traits, expectations and a common vision of the future, feelings and emotions, etc.

The work horses of the project are engineers, technicians, programmers. Compared to an expert, these people have a relatively narrow outlook and a rather one-sided understanding of the situation. There is nothing bad in this, it is enough that each of them is good at his work, often requiring complete immersion and specialized skills. Sometimes experts have ideas. To specialists, their ideas seem undoubtedly worthy of attention, they go upstairs with them and get there their rightful (or undeserved) tub of cold water on their heads. Because in the context of the entire project, these ideas may lose their importance, their implementation may adversely affect the neighboring areas of the project and all that. Ideas "from places" - the first place of the conflict of an expert and line specialists.

The opposition of linear specialists is connected exclusively with the defensive reaction that occurs when they feel the danger. Everyone who acts in the “field”, who honestly performs his duties, takes many small but important decisions at his own risk and peril. About which managers can not even guess. Experts can hide their "shoals", flaws, may be afraid of losing influence, authority. In poorly organized teams, line specialists often deliberately lock on key issues, thereby trying to further strengthen their position in the organization. An expert can easily identify such bottlenecks and destroy the cozy world created over the years.

People in vain consider themselves rational beings. Under the influence of fear, linear experts feel dislike for experts, and all that we have to deal with is non-constructive criticism, eternal opposition to all innovations, even sabotage — all this is rationalization of fear. It is often easier and more effective to work with fear as the root cause, rather than trying to fight back from the numerous attacks and inappropriate criticism that will never end.

Managers have no less reason to be wary of experts. Especially if the expert is going to give advice in terms of methods and methods of performing certain tasks. When reengineering processes, the redistribution of influence between the participants is inevitable, as well as its sharp devaluation in absolute terms. That is, the influence becomes less literally in every manager. It is not surprising that it is from the petty chiefs that we get the maximum and furious resistance.

Bosses are not afraid of bigger experts. For them, the expert is not a threat, but a means to achieve the goal. The goal may be the choice of a “pocket” artist who is beneficial for a personal pocket of a technical solution, the elimination of competitors at the court (in the case of organizational reengineering), and so on. In court wrestling, an expert opinion is a very significant weapon that, like a ram, can destroy any fortification heaps of “dear colleagues”.

We start manipulations. Work with written results

The results of the work of experts are presentations and text documents. The only available manipulation when working with written documents is the editing and distortion of these materials. No need to fear serious editing - such actions are too noticeable and require comparable expert knowledge. Usually limited to elementary techniques:

• Pulling out of context. We take one tablet or page we need, giving a link to the document. It is unlikely that anyone will climb to study the original sources. For example, if the document or presentation has a table with “pluses” and a table with “minuses”, it’s very easy to take either one or the other into your material. Tip - do not break the pros and cons into two different slides, make a general table.
• Delete inconvenient paragraphs or lines in functional analysis under the guise of "summary". With skillful handling, this method works wonders, changing the original idea beyond recognition. Tip - sew paragraphs with logical connections, often refer to other parts of the document. Give numbered lists instead of bullets and refer to the numbers. Do not be afraid, if the document will look a little strange, it's still not a novel.

A tightly bound document containing a summary at the beginning and at the end, in which the main idea repeated in different ways, permeated with references to sections, charts and tables, will become a real hell for a manipulator seeking to distort its essence when quoting.

If you need to give a series of slides in the presentation, consistently revealing a thought, use small schemes in the corner of the slide, use a postscript in the title “Slide X from Y”, etc. Any trick that doesn't allow is so easy.

Manipulating expert opinion "in real time"

Experts are often invited to meetings where they have to answer questions, submit their materials, or simply attend, giving the meeting particular chic. The task of the manipulator in this case comes down to forcing the expert to say the right words, which those present must remember and which will be entered into the protocol (which, by the way, the expert usually does not even see).

As a rule, in the case of face-to-face meetings, the manipulators are the big bosses. Such a boss can listen to the expert report with a bored look, without even asking him questions. But as soon as the expert says the right words, he is interrupted and confused.

The easiest way to illustrate this technique is by example. Suppose there are two software products - A and B. Product A is a multifunctional monster, it is three times more expensive and covers 100% of the requirements, and also contains another 200% of unnecessary functions. Product B is three times cheaper, it is more niche and covers 70% of the required functions, requiring the company to get the remaining 30% using other products and their integration. The expert intends to offer product B, which, taking into account all the additional costs, is twice as cheap as product A when purchased and three times cheaper during operation. But product sales manager A recently called on one of the bosses with an “interesting offer.”

Let us imagine now that at the meeting the expert reports on the results of his research.

Expert: Product A is the market leader in its segment, it is a powerful corporate solution ...
Boss: Tell me, is Product A 100% compliant with our requirements?
Expert: Yes, it meets our requirements by 100%, but ...
Boss: Does product B meet our requirements 100%?
Expert: No, product B meets our requirements by 70%, but ...
Boss: Please note that product B does not fully meet our requirements.
A curtain.

And now let's help our imaginary expert a little not to get into a puddle in the same situation.

Expert: Despite the fact that product A is the market leader in its segment, it has excessive functionality compared to product B ...
Boss: Tell me, is Product A 100% compliant with our requirements?
Expert: Product A functionality exceeds our requirements by 200%, which negatively affects its cost.
Boss: Does product B meet our requirements 100%?
Expert: Product B covers most of our requirements (for details, please refer to my report), and also has extensive integration capabilities for implementing the full range of functions using auxiliary software products listed on page 123 of my report.
A curtain.

I would like to separately recall the difference between the concepts of knowledge and skill . We know how to behave, what to say, what to do. But when it comes to practice, for some reason we do not do what we need, and often as the manipulator needs. Unfortunately, during the in-person battles in negotiations, knowledge alone is not enough, strong knowledge skills are needed, which are formed only in practice. Therefore, there is nothing wrong with catching the bait of the manipulator one, two or three times. But for the fourth time, you need to either learn or think about changing the type of activity.

Manipulating with raw data

The most common way to manipulate expert opinion from large and small bosses. The expert in the chess game of the project is a pretty strong figure - if not the queen, then the officer for sure. The difference between the project and the chess game lies in the fact that in the project not all the pieces go as they should. The expert is an exception - he almost always walks as it should. And the manipulators actively use this property of it.

The expert aims at the success of the project, to ensure that the project fits into certain parameters (deadlines, budgets, etc.). In the part of the project entrusted to the expert, he seeks to take into account and do everything possible to achieve the goal, even through compromises. It is the tendency to compromise that is the Achilles heel of the expert. The need for a compromise arises where it is impossible to “fit in” with the available means. The expert fully owns the technical content, knows the strengths and weaknesses of certain solutions, knows the limits of component modifications, taking into account possible technical risks.

In order to force an expert to make a certain decision, which is necessary for the manipulator, it suffices to work with external conditions and initial data. There are plenty of opportunities for big bosses.

Let us return to our example with products A and B. The expert, other things being equal, is going to prefer product B. But the manipulator needs an expert to voluntarily advise product A. What can a manipulator do?

• Work in related areas. For example, to collect for the expert reports on failed implementations of product B and supplement them with reports on the unimaginable successes of product A buyers. To do this, it’s enough to take real histories of product B introduction and marketing promises on product A, which look very similar, except that - true. This also includes a link to the successful experience of operating products A in neighboring companies.
• Offer the expert a pre-prepared form for presenting data - for example, a set of criteria for functional comparison, which includes the functions of product A, which product B obviously lacks. This is easier to submit under the guise of "corporate standards".
• Work with project risks in terms of terms. For example, if the delivery of product B takes a month and product A is shipped a week, you can delay the situation and seek advice three weeks before the deadline. Then the expert will not consider product B at all.
• Work with project risks in terms of budgets. If you give the expert to understand that the company is jam-packed with staff trained in using product A, and system administrators are not sleeping around with manuals for product A, and they don’t want to hear about anything else, then he will take into account lower operating costs of product A compared to cheaper ones. , but requiring retraining of employees with product B.
• Work with design requirements. Non-functional requirements “above TZ” is a favorite trick. Reference to external requirements, including informal ones. compliance. The most common case is a game with information security. This theme is muddy, allowing references to mythical and not very “people in uniform”, their suddenly arising “impassable requirements”, various “voluntary” certification, references to GOST standards that allow free interpretation, etc. Any expert understands that, without good reason, to touch the “specialists in information security” feed base is more expensive.
• Work with volumes of information. Sometimes an expert can download thirty volumes of a technical project and give them three days to analyze. You can not refuse. Give a full conclusion - too.

The tips in this section are trivial, but they need to be repeated once more in order for a complete picture to be formed in the memory.

Compare apples with apples. In the tables of product function comparison, it is extremely dangerous to leave empty cells with dashes opposite the function names. A rare customer understands the need for a particular function, and the dash clearly understands that this is bad. Dashes should be smaller. An exception can be made only for the analysis of TK coverage. But even there for each dash should be a link to another product, closing requirements. Unclosed requirements in the table - a direct path to the ban for the product. Because in fact such “dashes” unload the responsibility from the expert to the customer. And if the expert knows what to do with this responsibility, then the customer does not know (that is why he hired an expert).

Check the information obtained from independent sources, where possible. Communicate more with simple executors - as a rule, they do not receive instructions from managers regarding the issue of information or, as usual, take the liberty to interpret these instructions in their own way.

Require the necessary information in full! It is important to clearly understand that you are investing in the concept of “full volume” (as a list). If this is not possible, in a report in several key places, mention that the report is prepared on the basis of an incomplete set of documents (be sure to list which ones). You do not need to release the manipulator, who was obliged to supply you with the initial data, from responsibility for their completeness. If you had the luxury of preliminary negotiations with a client on the organization of expert work, giving him a list of the required initial data, mention that the missing data will have to be filled in for the interview, which will require an increase in the duration of the preliminary data collection phase.

The simpler the question that the expert has to answer, the more information he has to shovel. Top managers are not interested in details. They do not need you to hang up on them the responsibility for choosing product A or product B, company A or company B. If as a result of your activity there is no unequivocal choice, but there is only a comparison table of three thousand lines, this is equivalent to no result at all. It is clear that there is a conclusion with the input parameters: if X is A, and if Y is, then B. But you should not hide your inconsistency or lack of input data behind such “parameters”. As an expert, you get paid for simplifying the world, not for making it harder.

PS If you want to speak, please note that the article presents a structured personal experience, therefore, on the one hand, it does not claim to be universal, and on the other hand, it does not make sense to dispute personal experience, as well as oppose its own personal experience.