Bloodsuckers Programmer classification
Who are the leaders, and why are they needed? What is the use of them in life? What do they do? And what should they do?
On the one hand, traditionally, a manager is understood as one who manages — he plans, gives instructions, controls deadlines, yells louder than anyone, makes decisions, and bears responsibility for them.
On the other hand, there is an opinion that the head should deal only with the development of the assigned unit, not taking part in the operational management.
')
On the third hand, there is self-government and turquoise organizations that have proved in practice that such an entity as a manager is not needed at all - it’s just a set of responsibilities, roles and control points that are easily spread between different people.
So who is he, this leader, and why is he needed? Leader needs a company or a company needs a leader, as a source of income? Maybe he just justifies his existence, because the result is worth it - the income of managers is often incomparably higher than the income of ordinary employees.
I use a special model for evaluating managers, which I propose to read.
The model is simple to ugliness, but, as a rule, is understandable only to programmers. But you are programmers, and everything will be clear to you.
So, imagine a company that has automated its account in a certain information system. And next to this system sits a programmer, only one. He is an IT manager, a coder, and an architect - all in one. The situation is quite common for small, and sometimes for large enterprises - I myself have been, for some time, the only programmer in the enterprise.
So, now imagine that a programmer is the head of a department, and an information system is, in fact, his department, including personnel, equipment, processes, etc. And the department, and service, and department, and the whole enterprise is a system. And informational - it is also a system.
A programmer is free to use his system in different ways - to develop, maintain, delete, break, reduce or increase productivity, replace with another, write or delete documents, monitor balances, etc.
The head is free to do the same with his system (department) - develop, accompany, work as an executor, interfere, help, disperse, replace personnel, etc.
The model is clear: the head / department relationship is the same as the programmer / information system.
Now look at the leaders through the prism of this model.
The most primitive type of programmer is the one that does nothing at all, but somehow manages not to fly out of work. I personally saw this - they took him for the transition from complex 1C 7.7 to 1C 8 UPP, and he didn’t have a tooth in his mouth, either in the first or second, but stretched for a year - only because he ran to the general to set up the Internet in time, ICQ and download music from torrents.
Another example is a girl who couldn’t do anything herself, but had an extensive network of contacts among programmers and was, as they say, cute and charming, so the guys were happy to help, completely solving her tasks. Moreover, the guys worked in other companies.
You understand that with such a programmer the system lives its own life, practically doesn’t depend on it at all, and no visible changes occur on its arrival to the position before it leaves.
Among the leaders of these guys is also full - that they are, that they are not. Sometimes they are called wedding generals, but this is in cases where a manager can perform at least representative functions, for example, sitting beautifully at a meeting with clients.
Such leaders like all kinds of events and meetings - especially those where there are many people and it is not necessary to open their mouth. Sometimes they are so miserable that if they still get a task from the management, they cannot even delegate it normally, because the system ignores them altogether, unless someone takes pity and help.
It makes no sense to talk about the role of such a programmer and such a manager in the system and its development, because no role and development. This is the poorest case.
This is a separate kind of prank, with the difference that relatives do not have to do much to stay in place. They were led there by a shaggy paw, and they are sitting. Who all day, some before dinner, some after dinner, some at home.
The relatives already have influence on the system, since They are afraid of it - you never know what the reins will fall under the tail, you can lose your work.
But in fact, they usually do not use this influence. To be an element of the system, i.e. perform any functions in it, do not want to, because there will be responsibility and obligations, at least it is necessary to come to work. They cannot develop the system because this requires at least some competence and understanding of what is happening.
There are, of course, exceptions when a relative behaves not as a relative, but then we solemnly exclude him from this category. Sometimes family ties even help, making a person more responsible and efficient, for example, in a family business. Efficiency increases because the relative is not afraid of dismissal.
But in general, for the most part, such a programmer does not play a role in the life of the system, and the manager does not play a role in the life of the department.
It happens that a programmer turns into an operator. Not often, but it happens.
It only does what it does exchanges, loads and unloads files, makes backups, enters documents, generates reports, does some kind of data analysis, etc. In essence, just doing the work of the user. I have seen it in my life when I slowly, little by little, and the programmer turned into an accountant.
If turned, i.e. moved to another department and to another position - and to hell with him, normal such a transformation. But it happens that he works as an operator, and is called a programmer. Who is he then, in our model? Just an element of the system, which he had to manage. Who then controls the system and develops it? No one, until another comes and notices that there is something wrong.
With managers, this happens all the time, especially with the lower echelon, such as foremen, chiefs of stations, chief system administrators, etc. Their position is a formality, they control nothing and do nothing, they work like everyone else, they just have a bit more responsibilities, like going to the RAM and providing time cards.
Neither the leaders nor the others have any influence on their system. Do not manage, do not develop, do not respond. The system does not depend on them.
And this is a completely different case. Such a programmer, although not engaged in programming, is a unique element of the system. For example, he alone can count the cost and adjust it in accordance with the strategy of taxation.
In fact, this is the same operator, only more advanced, aware of its value and successfully selling it. Such a programmer claims that only he knows how to arrange the adjustment of register entries so that “nothing disappears”. Only he can correct the minus in the revolving, so that the subconto will not leave. You can continue the list.
Such a programmer is an integral part of the system, its bottleneck, appendage, which cannot be cut off. Without it, there will be a crisis, and everyone, including himself, understands this - everything rests on him. It makes decisions on the design of complex operations, on resolving complex problems, such as errors in uploading reports, etc.
There are even more managers of this type than programmers. They artificially and deliberately create conditions under which the system cannot exist even for one day without them (this is clearly seen when they go on vacation). They coordinate everything, check everything, especially what they provide “upstairs”, decide on each copy of the process (for example, the buyer's order), go to all meetings.
When they are told that they need to be delegated, they refer to employment — there is simply no time to sit down and think, write instructions and transfer cases. In general, this is their favorite excuse - employment, which they artificially created. And multitasking.
The situation sometimes looks ridiculous, especially when the supervisor changes and begins to ask our key element - what are you doing? And most importantly - why? The answer is usually - “so accepted”, or, if it managed to fix its indispensability in the standards of the enterprise, “it should be so”. By whom it is accepted, when accepted, why it is accepted - the answer is either not, or it cannot be pronounced, because “I came up with this meaningless crap” sounds so-so.
Both the programmer and the manager themselves gradually begin to believe in their uniqueness. Sometimes they even begin to feel sorry for themselves, and demand pity from those around them, or even induce this pity from their superiors to increase their income.
It happens that such a key programmer or manager makes changes to the system, i.e. acts on it favorably. But he almost always lacks a focus on ridding the system of himself. For example, a programmer can write a cool processing of the formation of batches of documents, which saves people from routine work, but only the programmer himself will use this processing. If he is asked to teach someone else, he will find a bunch of excuses, such as "yes, there is longer to explain, let me do better."
Similarly do the leaders, sharpening the system for themselves. For example, there was a commercial director who knocked out the condition: give me a percentage of the sales of the entire department, and I will distribute the premium as I please. You understand that for salespeople it becomes the main motive in working for such a leader - not to “sell more”, but “like more”. The manager cannot explain the distribution algorithm, because this algorithm does not exist.
As a result, for a programmer, for a manager, the result is the same: the system can neither exist nor develop without it.
There are some programmers who change systems like gloves. They are not particularly able to program, bring the introduction to the mind, solve minor and major problems of users, to benefit the enterprise.
In any crisis situation, when the system does more harm than good, they say: it's time to switch to another system.
Fortunately, now there are no problems with this, especially considering the mixing of the niches in the product line, the same 1C. It is possible to switch from UT 10.3 to UPP, then to KA 1, then to BP 3.0, then to KA 2, then to ERP, then spit on everything and introduce the UNF, then some kind of perversion like USP (if the industry allows), then Surprisingly, back on SCP. Each transition is at least a year. Count for yourself how long you can hold out on such a strategy. Have you met such programmers? I have met.
What does a similar manager look like? He is constantly changing the methodology, the main approach to management. Today he puts a plan for a month, tomorrow he will put a plan for a year, then he will switch to Agile, then to TOC, then to Lean, then to 4-4-5, then to budgeting, then to a budget model. It is still not bad if the manager knows all these techniques, at least you can practice their use.
But usually everything is more prosaic - such a manager solves all problems by restructuring. He makes two departments from one department, then ten, then one again, then recruits a new department from new people, then cancels and distributes them into the old departments, comes up with new posts and writes instructions, processes and standards, or quite childishly - changes divisions to divisions, divisions for departments, departments for teams, teams for districts, etc.
The essence of the approach both from the programmer and the manager is the same: as long as large-scale changes are underway, no one will get to the bottom of the results. And if you get to the bottom, you can always otmazatsya: we are in full swing of change, now it is simply impossible to answer your question, come up in a month, or look for an answer yourself.
The impact on the system is horrendous in scale, but meaningless in result and effectiveness. It is just a change for the sake of change, only on a colossal scale.
What is especially bad is that people around you get used to such behavior, and gradually they simply forget that these changes had a beginning, and there must be an end. They forget the chain of changes, which system or methodology has changed and why. In the end, after some time, you can simply repeat the whole range of changes again, and no one will notice. In practice, I observed such a picture, and calculated the periodicity of the cycle - 4 years.
Of course, there is no reason to speak of any benefit to the enterprise from such a programmer and manager.
Plyushkin is a character of Gogol's Dead Souls, a greedy meanie who dragged and kept everything he could find, right up to the stumps.
Such Plyushkin programmers love all sorts of solutions and code storage, such as a gita, but use them for purposes other than intended. Instead of looking there for a solution to their problem, they stupidly download everything that is enough disk capacity or money (for paid solutions). They are kept in neat daddies, sorted, sometimes they are tried to be built into their system in order to show them to the users or the director, giving out their own and thus justify their existence.
They themselves do not know how to do anything, so using someone else's small things for them is the only way to survive in the profession. They have neither strength, nor competence, nor courage for serious changes.
You can find out such Plyushkins by looking at the interface of their system - it will be filled with icons from various additions, the meaning of which will not be clear to anyone. Any panels of functions that duplicate the metadata tree, universal table sorting, exchange management in a database that does not use exchanges, a lot of reports, even for other systems, etc.
Similarly, the leaders behave Plyushkin. Read blogs, articles, all sorts of groups in social networks about how to make useful changes with small efforts. Because of the haphazardness in the choice of methods, the understanding of the problems of their department and the implementation itself, they usually get nonsense.
For example, Plyushkin will watch on TV that the new young governor is holding meetings standing up, saying it improves efficiency - and everyone, enjoy, subordinates. Previously, water in a mortar sitting pushed, now you will be standing. Or read another best practice that all employees must write a report for the day by hand, saying that this is not a computer copy-paste, but real, from the heart of the word - and here you are, daily essays, minus an hour from working time.
The impact on the system such programmers and managers have little, and mostly harmful, because fill it with incoherent debris and noise.
There are some programmers who, almost always, to solve any more or less complex tasks, are called outsourcers. Project implementation system, launching a new subsystem, integration with the site, development of a new document, adding props - for all external programmer (s) are encouraged.
There are the same leaders, personally seen. Need a motivation system? Optimize business processes? Strategy Development? Management System Analysis? The answer is one - we are looking for external specialists.
The effect on the system, it seems, turns out to be, but almost always crooked and harmful, because the consultant works with only one piece of the mosaic.
For example, it makes a motivation system for curved processes. Or he writes a strategy, disregarding the motivation for its implementation. Or, our native - does automation of snapshot processes, which loses relevance a year before the end of the project, although this is not important, because goals and motivation are also not taken into account.
In the end - always crooked, with a bias in some direction. Both at the head, and at the programmer. But the main thing - their own role in this development process is zero.
This is the most common type of programmers - those who do whatever they are told. Accordingly, they make senseless changes to the system, giving it, piece by piece, for the realization of someone's unhealthy ambitions. This is most of us, what is there to tell.
And such leaders - in bulk. These are all those who let outside automators, ISO 9001 implementers, internal bureaucrats of all stripes, who demand to provide a bunch of reports, pieces of paper, go through millions of approvals, learn songs and prepare scenes for corporate events, etc. In general, who opened a part of his system for external encroachment, as an entrance for the homeless, and now does not know how to drive them out of there in order not to sniff all this.
As a result, both the information system and the department or enterprise management system become like Frankenstein, who was slowed down, unable to take a single step.
Such people are pests because under the guise of "and I told me," they destroy their systems.
There are in the world and normal programmers, who themselves decide what to do with the system, knowing the goals before it. If the goals are set curves, then they are not shy, and correct them, and all manage to agree.
There are normal leaders who are constantly engaged in improving the efficiency of their system, and they do it thoughtfully, consistently and professionally.
Neither of them get inside the system, except in very emergency cases.
Neither of them, or others, tie the system to themselves, and at any moment they can leave, and the system will continue to work, although it will cease to develop.
The only problem is that neither of them exists.
There is knowledge, experience, competencies scattered around different people who can never agree. Some are able to do motivation systems, others strategy, third goals and indicators, fourth automation, fifth management systems. But they never work together and at the same time.
Development is always going on consistently, you can see it in projects that are sometimes started in companies.
For example, a motivation system based on current processes is being introduced. If it can be seen that the processes are curves, then this is ignored, so as not to go beyond the scale and budget of the project.
Or process optimization is being started, but automation is not keeping up with it, as a result of which a terrible hybrid from a new and old version of the one and the other is obtained.
I have already spoken about automation many times, especially external, by outsourcers. They simply make an automated cast of meaningless processes, non-motivating motivation, immeasurable goals and no control system at all.
There are endless races - each part of the system alternately takes the lead, which only aggravates the state of the whole population.
The solution is simple to ugliness - to integrate development. Change all parts of the system at the same time so that there is no imbalance between them.
Because the main problem is the imbalance, the mismatch of the parts of the system with each other. Although it seems that the problem is in any particular part.
For example, very often they drop automation — she’s to blame for everything.
We, programmers, usually blame the processes, they say there is a mess, and we are forced to automate it.
Introducers of motivation systems complain about processes, and non-automated indicators, and lack of goals. Etc.
But the real problem is the imbalance that creates the development race, and the company never gets the benefits of every part of the business system.
Implements ERP, and uses 10% of opportunities, because there are no processes for the rest. Implements a grading system and does not use it, because the calculation of indicators is not automated. He writes strategic goals, but he will never achieve them, because the processes are not restructured accordingly.
The essence is the same: each part, in itself, is not bad, but all together they do not work, because they are in imbalance.
The model I told you is not just to laugh. She - to understand the situation in a particular place in a particular company, with a specific leader.
I chose the analogy with the programmer for one simple reason - I am a programmer myself, and you are programmers. Surely, if you explain the role and influence of leaders to girls from HR, you will have to invent another model. Because the idea that I want to convey is one, and there can be many models - they are just for convenience of understanding.
But, as it seems to me, leaders are an atavism. Business does not need them. They are like a bad habit that you hate, but are afraid to quit. Managers create the illusion of support, stability, manageability of the business. They, like, “bear responsibility”, “make decisions”, “coordinate”, and the like, not meaningful words.
All these words came up with the leaders themselves. Try, for fun, to convince the manager that he is not needed. He tells you so much about how bad it would be without him that his ears would be covered. But listening to the manager himself about why a business needs him is the same as asking a prisoner to be shot why he should live.
A model of comparing a manager with a programmer, I hope, will help you, during such and similar conversations, not to forget why you need a leader.
It’s not necessary to do man, but the generally accepted model of a manager - “a big boss with a big salary”. To this, in fact, seek those who want to become a leader?
A good answer is given by the Belbin model. An ordinary leader is an indefinite compote of unclear responsibilities, which you just need to sort through the roles, and for a particular person to find a suitable job.
Can you coordinate the actions of people online? Ok, be the coordinator.
Can you inspire, support, move things forward? Ok, be a motivator.
Can you bring projects to the end in a short time? Ok, be a finisher.
You have a vision, you know where to go, can you come up with the right ideas? Ok, be a generator.
Can you analyze, keep in mind many parameters of the system and understand its vulnerabilities? Ok, be an analyst.
All these roles are not leadership. These are just roles, such work.
If you tell people what to do, it does not mean that you are in charge. The dispatcher also tells the taxi drivers where to go. He does not speak, said. He was replaced by the system.
If you can inspire people, it does not mean that you are in charge. Someone just enough to see the right film to be inspired, and you fuck him did not give up with his motivation. And someone's wife at home so inspire that will not find it.
If we expand the traditional "primacy" on the shelves of roles and competences, then nothing will remain of it. So why do you need such a leader? Moreover, with the layout, it turns out that he cannot really perform any of the roles.
And the king is naked, as stated in the tale.
On the one hand, traditionally, a manager is understood as one who manages — he plans, gives instructions, controls deadlines, yells louder than anyone, makes decisions, and bears responsibility for them.
On the other hand, there is an opinion that the head should deal only with the development of the assigned unit, not taking part in the operational management.
')
On the third hand, there is self-government and turquoise organizations that have proved in practice that such an entity as a manager is not needed at all - it’s just a set of responsibilities, roles and control points that are easily spread between different people.
So who is he, this leader, and why is he needed? Leader needs a company or a company needs a leader, as a source of income? Maybe he just justifies his existence, because the result is worth it - the income of managers is often incomparably higher than the income of ordinary employees.
I use a special model for evaluating managers, which I propose to read.
Model
The model is simple to ugliness, but, as a rule, is understandable only to programmers. But you are programmers, and everything will be clear to you.
So, imagine a company that has automated its account in a certain information system. And next to this system sits a programmer, only one. He is an IT manager, a coder, and an architect - all in one. The situation is quite common for small, and sometimes for large enterprises - I myself have been, for some time, the only programmer in the enterprise.
So, now imagine that a programmer is the head of a department, and an information system is, in fact, his department, including personnel, equipment, processes, etc. And the department, and service, and department, and the whole enterprise is a system. And informational - it is also a system.
A programmer is free to use his system in different ways - to develop, maintain, delete, break, reduce or increase productivity, replace with another, write or delete documents, monitor balances, etc.
The head is free to do the same with his system (department) - develop, accompany, work as an executor, interfere, help, disperse, replace personnel, etc.
The model is clear: the head / department relationship is the same as the programmer / information system.
Now look at the leaders through the prism of this model.
Weasel
The most primitive type of programmer is the one that does nothing at all, but somehow manages not to fly out of work. I personally saw this - they took him for the transition from complex 1C 7.7 to 1C 8 UPP, and he didn’t have a tooth in his mouth, either in the first or second, but stretched for a year - only because he ran to the general to set up the Internet in time, ICQ and download music from torrents.
Another example is a girl who couldn’t do anything herself, but had an extensive network of contacts among programmers and was, as they say, cute and charming, so the guys were happy to help, completely solving her tasks. Moreover, the guys worked in other companies.
You understand that with such a programmer the system lives its own life, practically doesn’t depend on it at all, and no visible changes occur on its arrival to the position before it leaves.
Among the leaders of these guys is also full - that they are, that they are not. Sometimes they are called wedding generals, but this is in cases where a manager can perform at least representative functions, for example, sitting beautifully at a meeting with clients.
Such leaders like all kinds of events and meetings - especially those where there are many people and it is not necessary to open their mouth. Sometimes they are so miserable that if they still get a task from the management, they cannot even delegate it normally, because the system ignores them altogether, unless someone takes pity and help.
It makes no sense to talk about the role of such a programmer and such a manager in the system and its development, because no role and development. This is the poorest case.
Relative
This is a separate kind of prank, with the difference that relatives do not have to do much to stay in place. They were led there by a shaggy paw, and they are sitting. Who all day, some before dinner, some after dinner, some at home.
The relatives already have influence on the system, since They are afraid of it - you never know what the reins will fall under the tail, you can lose your work.
But in fact, they usually do not use this influence. To be an element of the system, i.e. perform any functions in it, do not want to, because there will be responsibility and obligations, at least it is necessary to come to work. They cannot develop the system because this requires at least some competence and understanding of what is happening.
There are, of course, exceptions when a relative behaves not as a relative, but then we solemnly exclude him from this category. Sometimes family ties even help, making a person more responsible and efficient, for example, in a family business. Efficiency increases because the relative is not afraid of dismissal.
But in general, for the most part, such a programmer does not play a role in the life of the system, and the manager does not play a role in the life of the department.
Cog
It happens that a programmer turns into an operator. Not often, but it happens.
It only does what it does exchanges, loads and unloads files, makes backups, enters documents, generates reports, does some kind of data analysis, etc. In essence, just doing the work of the user. I have seen it in my life when I slowly, little by little, and the programmer turned into an accountant.
If turned, i.e. moved to another department and to another position - and to hell with him, normal such a transformation. But it happens that he works as an operator, and is called a programmer. Who is he then, in our model? Just an element of the system, which he had to manage. Who then controls the system and develops it? No one, until another comes and notices that there is something wrong.
With managers, this happens all the time, especially with the lower echelon, such as foremen, chiefs of stations, chief system administrators, etc. Their position is a formality, they control nothing and do nothing, they work like everyone else, they just have a bit more responsibilities, like going to the RAM and providing time cards.
Neither the leaders nor the others have any influence on their system. Do not manage, do not develop, do not respond. The system does not depend on them.
Octopus
And this is a completely different case. Such a programmer, although not engaged in programming, is a unique element of the system. For example, he alone can count the cost and adjust it in accordance with the strategy of taxation.
In fact, this is the same operator, only more advanced, aware of its value and successfully selling it. Such a programmer claims that only he knows how to arrange the adjustment of register entries so that “nothing disappears”. Only he can correct the minus in the revolving, so that the subconto will not leave. You can continue the list.
Such a programmer is an integral part of the system, its bottleneck, appendage, which cannot be cut off. Without it, there will be a crisis, and everyone, including himself, understands this - everything rests on him. It makes decisions on the design of complex operations, on resolving complex problems, such as errors in uploading reports, etc.
There are even more managers of this type than programmers. They artificially and deliberately create conditions under which the system cannot exist even for one day without them (this is clearly seen when they go on vacation). They coordinate everything, check everything, especially what they provide “upstairs”, decide on each copy of the process (for example, the buyer's order), go to all meetings.
When they are told that they need to be delegated, they refer to employment — there is simply no time to sit down and think, write instructions and transfer cases. In general, this is their favorite excuse - employment, which they artificially created. And multitasking.
The situation sometimes looks ridiculous, especially when the supervisor changes and begins to ask our key element - what are you doing? And most importantly - why? The answer is usually - “so accepted”, or, if it managed to fix its indispensability in the standards of the enterprise, “it should be so”. By whom it is accepted, when accepted, why it is accepted - the answer is either not, or it cannot be pronounced, because “I came up with this meaningless crap” sounds so-so.
Both the programmer and the manager themselves gradually begin to believe in their uniqueness. Sometimes they even begin to feel sorry for themselves, and demand pity from those around them, or even induce this pity from their superiors to increase their income.
It happens that such a key programmer or manager makes changes to the system, i.e. acts on it favorably. But he almost always lacks a focus on ridding the system of himself. For example, a programmer can write a cool processing of the formation of batches of documents, which saves people from routine work, but only the programmer himself will use this processing. If he is asked to teach someone else, he will find a bunch of excuses, such as "yes, there is longer to explain, let me do better."
Similarly do the leaders, sharpening the system for themselves. For example, there was a commercial director who knocked out the condition: give me a percentage of the sales of the entire department, and I will distribute the premium as I please. You understand that for salespeople it becomes the main motive in working for such a leader - not to “sell more”, but “like more”. The manager cannot explain the distribution algorithm, because this algorithm does not exist.
As a result, for a programmer, for a manager, the result is the same: the system can neither exist nor develop without it.
Glover
There are some programmers who change systems like gloves. They are not particularly able to program, bring the introduction to the mind, solve minor and major problems of users, to benefit the enterprise.
In any crisis situation, when the system does more harm than good, they say: it's time to switch to another system.
Fortunately, now there are no problems with this, especially considering the mixing of the niches in the product line, the same 1C. It is possible to switch from UT 10.3 to UPP, then to KA 1, then to BP 3.0, then to KA 2, then to ERP, then spit on everything and introduce the UNF, then some kind of perversion like USP (if the industry allows), then Surprisingly, back on SCP. Each transition is at least a year. Count for yourself how long you can hold out on such a strategy. Have you met such programmers? I have met.
What does a similar manager look like? He is constantly changing the methodology, the main approach to management. Today he puts a plan for a month, tomorrow he will put a plan for a year, then he will switch to Agile, then to TOC, then to Lean, then to 4-4-5, then to budgeting, then to a budget model. It is still not bad if the manager knows all these techniques, at least you can practice their use.
But usually everything is more prosaic - such a manager solves all problems by restructuring. He makes two departments from one department, then ten, then one again, then recruits a new department from new people, then cancels and distributes them into the old departments, comes up with new posts and writes instructions, processes and standards, or quite childishly - changes divisions to divisions, divisions for departments, departments for teams, teams for districts, etc.
The essence of the approach both from the programmer and the manager is the same: as long as large-scale changes are underway, no one will get to the bottom of the results. And if you get to the bottom, you can always otmazatsya: we are in full swing of change, now it is simply impossible to answer your question, come up in a month, or look for an answer yourself.
The impact on the system is horrendous in scale, but meaningless in result and effectiveness. It is just a change for the sake of change, only on a colossal scale.
What is especially bad is that people around you get used to such behavior, and gradually they simply forget that these changes had a beginning, and there must be an end. They forget the chain of changes, which system or methodology has changed and why. In the end, after some time, you can simply repeat the whole range of changes again, and no one will notice. In practice, I observed such a picture, and calculated the periodicity of the cycle - 4 years.
Of course, there is no reason to speak of any benefit to the enterprise from such a programmer and manager.
Plyushkin
Plyushkin is a character of Gogol's Dead Souls, a greedy meanie who dragged and kept everything he could find, right up to the stumps.
Such Plyushkin programmers love all sorts of solutions and code storage, such as a gita, but use them for purposes other than intended. Instead of looking there for a solution to their problem, they stupidly download everything that is enough disk capacity or money (for paid solutions). They are kept in neat daddies, sorted, sometimes they are tried to be built into their system in order to show them to the users or the director, giving out their own and thus justify their existence.
They themselves do not know how to do anything, so using someone else's small things for them is the only way to survive in the profession. They have neither strength, nor competence, nor courage for serious changes.
You can find out such Plyushkins by looking at the interface of their system - it will be filled with icons from various additions, the meaning of which will not be clear to anyone. Any panels of functions that duplicate the metadata tree, universal table sorting, exchange management in a database that does not use exchanges, a lot of reports, even for other systems, etc.
Similarly, the leaders behave Plyushkin. Read blogs, articles, all sorts of groups in social networks about how to make useful changes with small efforts. Because of the haphazardness in the choice of methods, the understanding of the problems of their department and the implementation itself, they usually get nonsense.
For example, Plyushkin will watch on TV that the new young governor is holding meetings standing up, saying it improves efficiency - and everyone, enjoy, subordinates. Previously, water in a mortar sitting pushed, now you will be standing. Or read another best practice that all employees must write a report for the day by hand, saying that this is not a computer copy-paste, but real, from the heart of the word - and here you are, daily essays, minus an hour from working time.
The impact on the system such programmers and managers have little, and mostly harmful, because fill it with incoherent debris and noise.
Escort lover
There are some programmers who, almost always, to solve any more or less complex tasks, are called outsourcers. Project implementation system, launching a new subsystem, integration with the site, development of a new document, adding props - for all external programmer (s) are encouraged.
There are the same leaders, personally seen. Need a motivation system? Optimize business processes? Strategy Development? Management System Analysis? The answer is one - we are looking for external specialists.
The effect on the system, it seems, turns out to be, but almost always crooked and harmful, because the consultant works with only one piece of the mosaic.
For example, it makes a motivation system for curved processes. Or he writes a strategy, disregarding the motivation for its implementation. Or, our native - does automation of snapshot processes, which loses relevance a year before the end of the project, although this is not important, because goals and motivation are also not taken into account.
In the end - always crooked, with a bias in some direction. Both at the head, and at the programmer. But the main thing - their own role in this development process is zero.
Be patient
This is the most common type of programmers - those who do whatever they are told. Accordingly, they make senseless changes to the system, giving it, piece by piece, for the realization of someone's unhealthy ambitions. This is most of us, what is there to tell.
And such leaders - in bulk. These are all those who let outside automators, ISO 9001 implementers, internal bureaucrats of all stripes, who demand to provide a bunch of reports, pieces of paper, go through millions of approvals, learn songs and prepare scenes for corporate events, etc. In general, who opened a part of his system for external encroachment, as an entrance for the homeless, and now does not know how to drive them out of there in order not to sniff all this.
As a result, both the information system and the department or enterprise management system become like Frankenstein, who was slowed down, unable to take a single step.
Such people are pests because under the guise of "and I told me," they destroy their systems.
Normal
There are in the world and normal programmers, who themselves decide what to do with the system, knowing the goals before it. If the goals are set curves, then they are not shy, and correct them, and all manage to agree.
There are normal leaders who are constantly engaged in improving the efficiency of their system, and they do it thoughtfully, consistently and professionally.
Neither of them get inside the system, except in very emergency cases.
Neither of them, or others, tie the system to themselves, and at any moment they can leave, and the system will continue to work, although it will cease to develop.
The only problem is that neither of them exists.
Key issue
There is knowledge, experience, competencies scattered around different people who can never agree. Some are able to do motivation systems, others strategy, third goals and indicators, fourth automation, fifth management systems. But they never work together and at the same time.
Development is always going on consistently, you can see it in projects that are sometimes started in companies.
For example, a motivation system based on current processes is being introduced. If it can be seen that the processes are curves, then this is ignored, so as not to go beyond the scale and budget of the project.
Or process optimization is being started, but automation is not keeping up with it, as a result of which a terrible hybrid from a new and old version of the one and the other is obtained.
I have already spoken about automation many times, especially external, by outsourcers. They simply make an automated cast of meaningless processes, non-motivating motivation, immeasurable goals and no control system at all.
There are endless races - each part of the system alternately takes the lead, which only aggravates the state of the whole population.
Decision
The solution is simple to ugliness - to integrate development. Change all parts of the system at the same time so that there is no imbalance between them.
Because the main problem is the imbalance, the mismatch of the parts of the system with each other. Although it seems that the problem is in any particular part.
For example, very often they drop automation — she’s to blame for everything.
We, programmers, usually blame the processes, they say there is a mess, and we are forced to automate it.
Introducers of motivation systems complain about processes, and non-automated indicators, and lack of goals. Etc.
But the real problem is the imbalance that creates the development race, and the company never gets the benefits of every part of the business system.
Implements ERP, and uses 10% of opportunities, because there are no processes for the rest. Implements a grading system and does not use it, because the calculation of indicators is not automated. He writes strategic goals, but he will never achieve them, because the processes are not restructured accordingly.
The essence is the same: each part, in itself, is not bad, but all together they do not work, because they are in imbalance.
Back to managers and programmers.
The model I told you is not just to laugh. She - to understand the situation in a particular place in a particular company, with a specific leader.
I chose the analogy with the programmer for one simple reason - I am a programmer myself, and you are programmers. Surely, if you explain the role and influence of leaders to girls from HR, you will have to invent another model. Because the idea that I want to convey is one, and there can be many models - they are just for convenience of understanding.
But, as it seems to me, leaders are an atavism. Business does not need them. They are like a bad habit that you hate, but are afraid to quit. Managers create the illusion of support, stability, manageability of the business. They, like, “bear responsibility”, “make decisions”, “coordinate”, and the like, not meaningful words.
All these words came up with the leaders themselves. Try, for fun, to convince the manager that he is not needed. He tells you so much about how bad it would be without him that his ears would be covered. But listening to the manager himself about why a business needs him is the same as asking a prisoner to be shot why he should live.
A model of comparing a manager with a programmer, I hope, will help you, during such and similar conversations, not to forget why you need a leader.
Where did he go?
It’s not necessary to do man, but the generally accepted model of a manager - “a big boss with a big salary”. To this, in fact, seek those who want to become a leader?
A good answer is given by the Belbin model. An ordinary leader is an indefinite compote of unclear responsibilities, which you just need to sort through the roles, and for a particular person to find a suitable job.
Can you coordinate the actions of people online? Ok, be the coordinator.
Can you inspire, support, move things forward? Ok, be a motivator.
Can you bring projects to the end in a short time? Ok, be a finisher.
You have a vision, you know where to go, can you come up with the right ideas? Ok, be a generator.
Can you analyze, keep in mind many parameters of the system and understand its vulnerabilities? Ok, be an analyst.
All these roles are not leadership. These are just roles, such work.
If you tell people what to do, it does not mean that you are in charge. The dispatcher also tells the taxi drivers where to go. He does not speak, said. He was replaced by the system.
If you can inspire people, it does not mean that you are in charge. Someone just enough to see the right film to be inspired, and you fuck him did not give up with his motivation. And someone's wife at home so inspire that will not find it.
If we expand the traditional "primacy" on the shelves of roles and competences, then nothing will remain of it. So why do you need such a leader? Moreover, with the layout, it turns out that he cannot really perform any of the roles.
And the king is naked, as stated in the tale.
Source: https://habr.com/ru/post/435168/
All Articles