Eliminating the contradictions of authoritarianism in management. Using the “Problem Management” process as an example
In this paper, by authorism I understand the phenomenon in which management primarily relies on the personal experience, knowledge and skills of the manager, while feedback from subordinates is secondary. The nature of authoritarianism is interesting and requires separate discussion, but here I will try to show how to level out the main disadvantages of the authoritarian approach to management and enhance its advantages. IT is very sensitive to management errors: authoritarianism can be destructive, or it can lift an enterprise to the skies (Steve Jobs was authoritarian).
Authoritarian approach and vice versa
There are two approaches to management: authoritarian and vice versa. On the contrary, it is an approach based on co-creation of value. Both approaches have pros and cons. Authoritarian the approach is based on the individual (the system is secondary), the result is achieved quickly and more obvious effect(which, however, is often short-term in nature), but the risk of failure is extremely high. The second approach relies on system needsit is more reliable and less risky, result it turns out thorough and strategic, but more longalas. And, unfortunately, here the risk of failure is just as likely, but failure will have strategic character.
The authoritarian implementation of the Cover Oregon website (USA) cost $248 million and was a failure. Cover Oregon was supposed to automate the delivery of private health insurance; it was to ensure participation in the state's Medicaid insurance program and other public assistance programs. The Cover Oregon website was intended to act as a one-stop shop for medical services in the state of Oregon. It was reported, but… When the site launched in October 2013, users could not even register on it. In November 2013, the state of Oregon hired hundreds of employees to process insurance using good old-fashioned pen and paper. The project was closed: an additional $78 million was required to finalize it, and the transition to a centralized analogue cost $4-5 million. Several investigations were carried out (https://www.oregonlive.com/health/2014/05/fbi_inspector_general_investig.html). It turned out that the project managers did not track implementation project, they simply showed optimistic reports that hid significant problems. From my point of view, authoritarian management almost always illusory. With an authoritarian approach, management is based on the personal experience, knowledge and instincts of the first person. Typically, with this approach, reporting is well developed. This example is a reason to take into account understand risks authoritarian management.
Alternative management, based on the principles of joint value creation (stakeholder requirements and agreements), is also not without drawbacks: critical risk that main goal of management (party line) will become secondary. I have encountered many times dictatorship stakeholderswhich sabotaged or made it unprofitable to achieve one or another goals.
One day in British Columbia they decided to create a fleet of high-speed ferries—well done! Local aluminum producers received orders, local shipyards received orders, jobs were created to build ferries from local aluminum, and politicians received public support. For $460 million CAD, three ferries were built, which just a few years later were sold for just $19 million CAD as scrap, despite the fact that there were buyers willing to pay both $60 and $88 million CAD. Ferries did not become high-speed for many reasons. The investigation showed that during the construction of the ferries, the political objectives of developing the local economy and social infrastructure were put at the forefront; project managers did not ignore the fact that local shipyards did not know how to build ferries. The investigation revealed that constructing ferries from third-party contractors was significantly cheaper. In management it is impossible follow the lead of interested parties.
Process approach to management as a way to solve the contradictions of authoritarian management
The weakness of the authoritarian approach to management is that the leader often manages “to the touch”. Reports they lie, subordinates hide. And democracy, in which the goal of the enterprise becomes less importantthan goals subordinatesthe leader is already full. Let’s help the authoritarian leader, especially since scientists came up with everything a long time ago.
Efficiency is the main advantage of authoritarian management, which can come to naught due to inconsistency of management, contradictions in horizontal interaction and contradictions in vertical communications. The process approach eliminates many management disadvantages. Let's look at the IT Problem Management process. His goal isprevention And minimization influence incidents for IT services. We will see how a well-structured process can remove some of the contradictions, but first I will describe the context of the reasoning.
An information resource (engineering system, automated system) has the following life cycle: Creation (Idea, Resource Allocation, Design, Development, Commissioning), Operation (Preparation of operational requirements, Creation of operational tools, Operations, Analytics), Disposal (Comprehension/reflection/validation, Discussion/communication, Improvement, Verification/validation of results).
Typically, the supplier organization (vendor, developer, etc.) is responsible for the Creation stage, and others are responsible for the operation of the information system.
In large organizations with information systems operating 24×7, their performance is monitored by a shift administrator, who resolves most incidents.
A problem manager is a leader (head of a department, for example) who takes upon himself the solution to the organizational component of the problem.
Let's think in this paradigm.
Contradictions in management procedures.
Inconsistency in control procedures is when one hand does something that the other does not know about. Let's consider a typical scenario for solving a problem diagnosed at the Creation stage.
A particular scenario for solving a problem. It would be good for the Administrator if, when implementing an information system or its version, the developer warned him about a possible problem and ways to circumvent it. Admin needs upper left corner of the diagram. Under authoritarian management, a quality control system is usually built (lower right corner), in which bad software leads to sanctions and the developer will feel bad if he admits that his system has problems.
With this approach, developers don't really want to talk about problems that may or may not lead to failures. It turns out that the admin wants know in advance, but the developer wants hide — contradiction.
In authoritarian economic systems, when a mistake is costly, the drawn diagram often does not work or only works formally. The supplier pretends that the system he has developed is ideal, rivets excellent reports with presentations, acceptance certificates are signed, the “great” system is implemented, but to the tears of administrators.
Managers who are unaware of the shortcomings of the system (which are not recorded anywhere) manage “blindly” and overpay. I came across a curious phenomenon when developers and administrators from different organizations agreed to jointly fix an information system behind the back of their superiors, who believed that the information system had no problems.
A process is a set of rules that are accepted by everyone. Accepting and understanding the problems of management inconsistency, we need to organize the work in the lower right corner of the diagram so that it does not interfere with the proactive fixation of problems at the stage of Creating an information resource, in the upper left corner of the diagram. A well-designed process removes contradictions between various procedures systems management. In other words: the disposal of an information system implementation project should not interfere with proactive problem solving. Therefore, contracts, SLAs and OLAs, must be concluded as honestly as possible, without lies and illusory expectations inherent in authoritarianism.
Even non-authoritarian economic systems have authoritarian controls. Many enterprises live in two realities: reporting and problem. One of key tasks process management “Problem Management” is casting reported reality to “real”. Slowly, step by step, you can train managers to talk about problems and the progress of their solution, minimizing illusions.
The task of ensuring realistic reporting is usually posed by the first person of the enterprise, who does not want to manage “blindly”. The Problem Management process is often called “director's” for this reason. Organizational issues of recycling are usually resolved on communication platforms in the format of “strategic sessions”. This is not a matter of one or two meetings.
Contradictions of horizontal interaction.
Let's consider a scheme for solving a problem that arose during the operation of the information system. Let, for greater certainty, the problem is related to poor quality software. Below is a schematic diagram for solving this problem.
Each rectangle from the diagram is a potential source of interaction contradictions: the developer does not always promptly develop workaround solutions (admin you have to get out using server settings), the admin does not always provide complete information about the state of the system, and does not always follow the developer’s recommendations… As a former developer, I admins were unclear for a long time. They thought I was shallow and unreliable, I thought they were boring and uncreative—both opinions are wrong. I started drawing the first cross-functional diagrams like the one above to find common language admins. They really like the squares with arrows. Usually, each square of the process is hung with a metric or even an indicator. There is no stronger feud than a feud over performance. With authoritarian approaches to management, such conflicts are hidden even from line managers, especially since the director does not know about them. The task of the process is to ensure consistency in the actions of process participants. Before the game in “fool” to be specified rules. For conflict reduction and increasing mutual understanding between participants, when building a process, it is recommended to communication platforms for building process procedures.
I. Attention! With the help of communication platforms, it is possible to define mechanisms for determining and monitoring target and planned values of indicators. But such tricks are, of course, the art of management. Easier set target indicator values “by eye”authoritarian. In the previous article, I gave an example of English hospitals, when ambulances with patients inside were idle on the streets in order to comply with the waiting time in line. In this paragraph I'm bragging. Eh!
Contradictions of vertical communications
The Boeing 737 MAX had problems with the MCAS flight stabilization system; pilot unions and engineers have been talking about this for many years, but it took two plane crashes and 346 deaths to hear these appeals. (https://mitsloan.mit.edu/sites/default/files/2024-04/Boeing%27s%20737%20MAX%208%20Disasters_0.pdf)
As a software product, MCAS had the following typical information systems design problems and low software quality:
The system read information from only one sensor. When the sensor failed, there was no plan B. (In 2019, CNN reported that since 2004, the FAA has received at least 216 messages o infailure of AOA sensors or the need for repair, replacement or adjustment) The solutions applied to the problems carried risks and changed the typical operation of the aircraft.
The system was originally designed to operate at high speeds, while stabilization was also necessary at low speeds. When expanding the functionality, we introduced dangerous “crutches”.
Typical design problems were accompanied by typical organizational problems:
Solving design problems and low software quality carried out reactivelyAfter the incidents occurred, the cost of some of them was measured in human lives.
The problems with MCAS and the resulting risks were known, but Boeing executives ignored the problem.
Airlines, i.e. customers/clients, were not informed about the issues and risks of MCAS. Often, clients were not informed about the “workarounds” found
We see an example bad vertical communicationshushing up the problem and disastersin the end. The Boeing 737 MAX has been grounded for years. There were billions of losses.
The complexity of vertical communications is most often associated with the difficulties of escalating a particular issue. Schematically, escalation looks quite simple.
The scheme provides for both a process-based, algorithmic approach and manual control. In life, interaction with the outside world often occurs manually, if only because those around you “don’t care” about your internal processes. Capacity management, suppliers and are usually good while they're in there. Manual mode has its own nuances.
The higher the position, the more difficult it is to resolve issues that your subordinates could not cope with. Not every manager will find the courage to admit that the system put into operation “no comments” no good. Not every leader will manage to knock out extra millions on necessary power. Very scary admit that impressive successes projects are of a purely reporting nature, but reality screams about failure.
Escalation is the most difficult procedure of the process: it is easy to solve the PostgreSQL problem using Huge Pages, it is much more difficult to find money to redesign a suboptimal application model that creates an unacceptable load on the database server.
The manual escalation mode is seemingly simple: consult, understand what to decide you can'tescalated the problem “up”. Top looked, consulted, realized that can'tescalated the problem even higher. As a result, it is formed a lot of unsolvable problems. “And what?”—will ask you director. Science and the Internet are not generous in describing the mechanisms of problem escalation – this is a gray area of practice.
Organizational “trouble shooting»—not algorithmized control area. Solutions to such problems may lie in the field of managed communications: strategic sessions, communication platforms in the form of games, brainstorming sessions and banal meetings.
Basic procedures and contradictions of the Problem Management process
The configuration of the problem management process very much depends on the organizational structure of the IT enterprise and the maturity of its management system. I will list the main possible procedures of the process and the contradictions that accompany them.
Identification and registration of Problems. The main contradiction is in hiding problems.
Problem analysis. Contradictions in the exchange of diagnostic information between various participants in the process (development, servers, network, related systems).
Finding the root cause of the Problem. Contradictions in determining the root cause zone, evidence of its presence.
Finding a workaround. The contradictions of interaction were discussed above.
Finding a permanent solution to the Problem. Communicative contradictions between admin and developer.
Implementation of a permanent solution to the Problem. Contradictions between admin and developer.
Control of known errors.
Suspension of work on the Problem. If the problem cannot be solved for objective reasons, for example, the developer went bankrupt, it can be suspended if a workaround is known. Many different contradictions.
Escalation of problems to the level of middle management were discussed above.
Escalation of problems to the level of a senior manager was discussed above.
Escalation of problems to the supplier. Contract management contradictions.
Closing the Problem. Conflicting criteria for the quality of problem solving. For example, let’s say we always have low-quality software and poor testing. The solution to ten problems with the inaccessibility of various pages is the solution to ten specific problems. But the problems of testing and organizing development remain unresolved.
Communication as a way to solve problems
“I'm a cleaning lady. Don't be afraid of me. Speak boldly and clearly, because I am a stupid cleaning lady. No! A cleaner is a respected profession! I am a child from seven to fourteen years old. Explain to me simply, like a child. And don’t be afraid!” – this is exactly what I spoke with one programmer who was terribly afraid to speak, and if he spoke, it was incoherent nonsense, despite his remarkable intelligence. Not only everything know how to communicate.
One of the points of this article is that communication is important. Process management must ensure communication between participants throughout the life of the problem. When managing a process, you need to be able to “see” areas of the process where communication problems arise: warring divisions, often officially friendly; managers often cannot condescend to communicate with a simple performer; a simple performer can be a sociopath…
This topic requires separate reflections; here I just want to say that the development of the process from below depends on the quality of communications. Communication management, oddly enough, requires the maximum authoritarian approachesso as not to turn brainstorming into a bazaar and benefit performances for “informal” leaders. Before any communications (exchange of experience, strategic sessions, brainstorming, games, etc.) it is necessary to conduct a thorough analysis and work with big data to identify and trace deviations. During communications, employees receive a calculated and clearly described contradiction, and then a more or less accurate solution is sought.
What will we get after implementing the Problem Management process?
Summary section of the article.
The first level manager will receive:
Measurable information about the quality of the IT infrastructure in terms of failures (causes, duration, frequency)
Measurable information about the degree of IT readiness for possible failures
Prioritized capacity upgrade needs
Measurable information on progress in implementing changes to solve problems
Measurable information about the quality of provision of “problematic” IT services
Reduced interaction problems between employees at the operational level
Increasing the efficiency and quality of problem solving, that is, reducing the impact of failures on automated business processes
The process approach minimizes the influence of the human factor and the influence of tyrant leaders in management and, at the same time, strengthens the authoritarian approach of top officials. This is where its contradictory charm lies.
Using process approach tools in management is expensive. If you don’t know how or leave everything to chance, then the high cost will become incredible. Therefore, when implementing and operating processes, you need to regularly ask a simple question: what contradictions will this or that process remove? It is necessary to carry out audit and analysis to identify contradictionsexisting in the enterprise. And, starting from the identified organizational problems, develop and implement process tools.
Funny story about the contradictions of vertical communications, for the mood:
King Gustav II Adolf of Sweden built one of the most grandiose and expensive ships and named it Vasa. In the summer of 1628, the flagship ship made its first voyage: it left the harbor, sailed less than a mile and sank: the center of gravity was too high due to the abundance of cannons and decorations. According to various sources, from 50 to 400 people died.
Meanwhile, tests were carried out before the voyage, problems with stability were revealed, but everyone remained silent. The Admiral, responsible for building the ship, also remained silent, interrupting the tests of the ship, realizing that the ship could capsize right in the port. Before the first voyage, the ship was simply loaded thoroughly.
After the Vase sank, they conducted an investigation, during which they found out that no one was to blame. Because the technical documentation for the ship was signed by the King of Sweden Gustav II Adolf himself.
