December 13, 2017 at 11:57Butchert Engineering: How to Win?
So, let's start with the definitions. The developmental bathhurt is a special kind of bathhurt, which manifests itself in the form of a complete denial of the possibility of improving the developer's product without his participation (hereinafter referred to as BR ). It leads to various types of sabotage and degradation of the product itself. This article is an attempt to highlight the problem and look for solutions.
A bit of context. We are engaged in website acceleration services. Usually this is work on the client side and a bit of server tuning. Sometimes you have to embed yourself in someone else's server code to solve performance problems. If a client has a development team, we regularly meet with them.
Three sides are needed to form a BR. Next, we describe them together with the interests that lead to the bathhert situation.
The first side is the development team, which should have a sufficient history of interaction with the project code (for example, development from scratch or long-term support). Their main interests are: to maintain their own authority, self-esteem and stay in the project, to prove their indispensability.
Second side- This is another development team invited to solve local problems: finalizing a component, project audit, solving performance problems, consulting. Their interests: to successfully carry out the project, get a case, increase reputation, additional sales of services.
The third party is the owner or project manager, who invited the second team to solve the local problem. His interests: to improve the quality of the project, solve problems for users, increase project revenues (while not losing control and retaining all the strengths, including the development team).
The nature of developers ’velvet is different. For example, it can be self-confidence and correct decisions. In some cases, it is a fear that it will be replaced by more advanced developers who were able to fix problems in the project. Sometimes - the inability to learn and perceive new approaches and technologies. In any case, the bathhurt leads to problems for all parties involved.
Difficulties arise when trying to interact with development teams. The first team (project old-timers) is not interested in the success of the invited team (or does not want to believe in it). Result: sabotage of all actions. This process begins by delaying the transfer of access to the project program code and ends with blocking the implementation of changes. Denial of access is easily motivated by security issues; implementation of changes is blocked on the basis of evaluating code changes that are “incorrect”, “unnecessary” and “unprofessional”.
Further, the project manager reports on the complete failure of the invited team and the need to roll back all changes.
The project manager faces a difficult trust issue: on the one hand, a team that is immersed in a project has a significant trust limit (the project still works). On the other hand, there is an invited team with which he works for the first time, the trust limit of which is obviously lower.
If the leader has sufficient technical training and can understand the real state of affairs - well. However, the story does not end there. Then he will have to push his team to accept the changes and “sprinkle ashes on his head”. This can in turn cause new problems.
If the leader cannot independently understand the details of the dispute, then most likely he will choose the path of least resistance - abandon the project with an invited team and accept the point of view of its developers. This option is the least conflicting, but leads to the failure of the initial task (completion of the project, audit).
Here I do not have a definite answer. I can offer only a few methods.
Method number 1 - communication . From the very beginning, it is necessary to establish effective communication between the development teams, explain to all parties the goals and objectives of the project. The feedback and understanding of the process by all parties is important here. Unknown generates fear and distrust.
Method number 2 - turn off emotions . We are all human beings and we tend to react emotionally. This is especially true when it comes to your brainchild (program code). All argumentation in disputes should be based on objective data and logic (if your project has clear criteria and metrics - excellent). In no case should one pass on to individuals and lose the business tone of communication.
Well, the last one, which is a method of prevention, and not treatment - insure risks. If you know in advance about the bathhurt problem, you can foresee this risk in the contract, warn the customer, etc.
Have you met with the developers' bathhurt in your practice (on either side)? How did you fight?
Where can I meet BR?
A bit of context. We are engaged in website acceleration services. Usually this is work on the client side and a bit of server tuning. Sometimes you have to embed yourself in someone else's server code to solve performance problems. If a client has a development team, we regularly meet with them.
Three sides are needed to form a BR. Next, we describe them together with the interests that lead to the bathhert situation.
The first side is the development team, which should have a sufficient history of interaction with the project code (for example, development from scratch or long-term support). Their main interests are: to maintain their own authority, self-esteem and stay in the project, to prove their indispensability.
Second side- This is another development team invited to solve local problems: finalizing a component, project audit, solving performance problems, consulting. Their interests: to successfully carry out the project, get a case, increase reputation, additional sales of services.
The third party is the owner or project manager, who invited the second team to solve the local problem. His interests: to improve the quality of the project, solve problems for users, increase project revenues (while not losing control and retaining all the strengths, including the development team).
The nature of developers ’velvet is different. For example, it can be self-confidence and correct decisions. In some cases, it is a fear that it will be replaced by more advanced developers who were able to fix problems in the project. Sometimes - the inability to learn and perceive new approaches and technologies. In any case, the bathhurt leads to problems for all parties involved.
What is the problem?
Difficulties arise when trying to interact with development teams. The first team (project old-timers) is not interested in the success of the invited team (or does not want to believe in it). Result: sabotage of all actions. This process begins by delaying the transfer of access to the project program code and ends with blocking the implementation of changes. Denial of access is easily motivated by security issues; implementation of changes is blocked on the basis of evaluating code changes that are “incorrect”, “unnecessary” and “unprofessional”.
Further, the project manager reports on the complete failure of the invited team and the need to roll back all changes.
The project manager faces a difficult trust issue: on the one hand, a team that is immersed in a project has a significant trust limit (the project still works). On the other hand, there is an invited team with which he works for the first time, the trust limit of which is obviously lower.
If the leader has sufficient technical training and can understand the real state of affairs - well. However, the story does not end there. Then he will have to push his team to accept the changes and “sprinkle ashes on his head”. This can in turn cause new problems.
If the leader cannot independently understand the details of the dispute, then most likely he will choose the path of least resistance - abandon the project with an invited team and accept the point of view of its developers. This option is the least conflicting, but leads to the failure of the initial task (completion of the project, audit).
How to treat?
Here I do not have a definite answer. I can offer only a few methods.
Method number 1 - communication . From the very beginning, it is necessary to establish effective communication between the development teams, explain to all parties the goals and objectives of the project. The feedback and understanding of the process by all parties is important here. Unknown generates fear and distrust.
Method number 2 - turn off emotions . We are all human beings and we tend to react emotionally. This is especially true when it comes to your brainchild (program code). All argumentation in disputes should be based on objective data and logic (if your project has clear criteria and metrics - excellent). In no case should one pass on to individuals and lose the business tone of communication.
Well, the last one, which is a method of prevention, and not treatment - insure risks. If you know in advance about the bathhurt problem, you can foresee this risk in the contract, warn the customer, etc.
Have you met with the developers' bathhurt in your practice (on either side)? How did you fight?