How many control levels should be


    Somehow at the FB, a discussion was formed among friends about how many levels of management should be in order to ensure the effective operation of the organization. I recalled the report of Arnold (not a terminator, but mathematics), presented almost 20 years ago, at a seminar under the Presidential Council of the Russian Federation. The report made a rather unexpected conclusion.
    “The multi-stage control described by our model for n> 3 is unstable. Two-stage control leads to periodic fluctuations, but does not cause a catastrophic increase in fluctuations that occurs with three or more step control. True stability is ensured only by one -stage management, in which the manager is more interested in the interests of the case than in encouragement from the authorities. ”

    How is this possible if the organization has thousands of employees?

    And it's all about project management.

    I’ll clarify right away, “if a tram driver starts looking for new ways, wait for trouble.” If external conditions are well known and stable, if production operations are well studied and repeatedly tested, and the functions of performers are defined and constant, in these conditions narrow specialization and conveyor serve as the basis for efficiency. In the absence of disturbances, the organization can be in an equilibrium state (albeit unstable) for an arbitrarily long time and withstand any management hierarchy. We recall the multilevel bureaucracies from Ancient Egypt to the Soviet era.

    But, if the external conditions are dynamically changing, if the organization wants to get a unique result, to develop a new product, the requirements for which are constantly changing, for the first time apply production technologies, if intellectual efforts, creativity, and the search for new opportunities are required, then in these conditions a project management organization is used. And it was Arnold who spoke of the control models in such systems.

    “But wait,” the reader will say, “the project activity has its own multi-level hierarchy: goals, strategies, programs, portfolios, projects, subprojects, work packages. And at each level sits its own manager. Well, where is "... one-step management, in which the manager is more interested in the interests of the case than in encouragement from the authorities"?

    The basis of project management is a hierarchical structure of work. A serious mistake is the process decomposition: analysis, design, coding, testing, documentation.

    The correct structure should be result oriented. Therefore, each package of work must be considered as a mini-project aimed at achieving a unique result and managed individually. And in order for this manager to be “more interested in the interests of the case than in encouragement from the authorities,” all four conditions must be met.

    1. The expected result is set. “What”, and most importantly “why” (but in no case “how”) should be done.
    Once a colleague, Alexander Orlov, said here
    such a story
    I remember when I told Intel to my employee: Max, look at static analyzers. Max says, they say, not a question, and leaves. Comes in 3 days. Me:
    - Well, how?
    - I looked.
    - And ...?
    “Here is the table ...
    I almost killed him.” I needed a person to find a free static Java code analyzer and screw it to our version control system.
    Max understood the task in his own way - that it was necessary to conduct a comparative analysis of the available static analyzers. A man downloaded and installed all these analyzers, came up with metrics for comparison, found test cases. For three days he was engaged in a rather meaningful activity. And I, as his manager, ended up dissatisfied.

    IMHO, the problem is that Max was given a task, and not a goal - no. A task without a goal, as a rule, does not make sense. A goal without a task makes sense. In this case, the goal, apparently, was to improve the quality of the code. Alexander did not voice it - this is his mistake. Max did not ask: "what the hell?"
    A manifestation of unprofessionalism on his part.


    2. The rules of the "game" are defined. The minimum restrictions associated with the system architecture, the coding standard provided by the API, which is definitely not necessary. Remember, the more rules and standards, the lower labor productivity.

    3. Allocated resources and their working hours, hardware and software, etc.

    4. Established measurable criteria for evaluating the result: what is good and what is bad.

    And it's all. We get a stable one-stage management, in which the head works in the interests of the business, and not the boss.

    Something like this.

    Also popular now: