Execution cannot be pardoned


All matches in this article are accidental. Any analogies that may be seen in this text are unfounded.


I want to formulate a problem that I sometimes face as a development manager, and which each time plunges me into the abyss of spiritual doubts. The purpose of the article is to collect the opinion of the community on how to do the right thing in one delicate situation.

I invite you to take part in a small thought experiment, and, as a result, give an answer in the comments about what you would do if you found yourself in a similar situation.

The experimental conditions are as follows:

You lead several development teams. One of the teams (not the only one) consists of 10 people, makes a cool and popular product for end customers. The team includes:

  • 7 development engineers (for example, all full stacks to remove the complexity of non-overlapping stacks from the problem);

  • UI / UX designer;

  • Systems Analyst;

  • the product owner is a leading specialist from the Business, who determines the priorities of improvements and the benefits of new features.

One day the Product Owner comes to you and says that he is not happy with the productivity of one of the engineers. Allegedly, it does fewer tasks, and other engineers perform similar modifications faster (in the same code base).

It seems to be a standard story, which used to be solved by explaining to the Product Owner the complexity and non-triviality of the task that a particular engineer performed (as opposed to other tasks that seem “similar”).

After immersing yourself in the history of commits and talking with all the engineers on the team (including the one on which there are “questions”), you get the following picture:

  1. Indeed, the “problematic” engineer performs tasks more slowly than his colleagues. Moreover, tasks that are really similar in complexity, there are no pitfalls. It seems that he writes code about twice as slow as other engineers on the same team.

  2. The quality of the code is on par with the hospital average. There is nothing supernatural there. Tests are written, integration interactions, if possible, implemented through a queue broker, errors are logged, etc. All in all, everything is fine, as with other developers.

  3. The professional skills of the “problematic” engineer also correspond to the expected level, and somewhere even exceed the average level of the team. He knows his professional field well, suffers from perfectionism in moderation, adheres to accepted standards and development patterns.

  4. Other engineers avoid joint tasks with the “problematic” developer. This is explained by the fact that when there are controversial points in the implementation of a feature, the “problematic” engineer argues until he turns blue and does not hear the arguments of other developers. In the end, it still does it in its own way, and it (sometimes) has to be redone for code review. Each time it is a scandal and a tragedy. And if you don’t have to redo it (that is, the decision is correct), it turns into an intolerant tirade “I told you so.”

  5. The “problematic” engineer actively participates in all collective events and discussions within the company, including those that do not relate to the subject area of ​​the team. These are all kinds of public demonstrations of other products, discussion of architectural and DevOps issues, activity on creating a single UI set (not the task of this team), etc. In fact, he expresses his opinion on any issue, even if the question does not concern any stack. no team tasks. On the other hand, it helps the development of the company’s collective projects.

  6. The “problematic” engineer never sacrifices personal time to solve the problems of the team. In other words, if you ask him a question in the chat half an hour after the end of working hours, the answer will be only in the morning. During working hours, the reaction to questions is quite normal.

  7. Again, it makes no sense to count on the help of a “problematic” engineer outside of working hours. If there are any problems in the operation of the product and the involvement of development is required, then the “problem manager” will not answer calls and messages in the chat and will not join the solution.

You also spoke with the “problematic” engineer himself, his point of view is as follows:

  1. The guy feels quite comfortable in the team, did not notice that they did not want to do joint features with him.

  2. He sees and admits the problem with his productivity, but cannot explain it.

  3. When asked why he never helps the team in case of problems outside of working hours, he replies that “he works to live, and does not live to work”.

As an experiment, you described in detail several tasks for a couple of sprints and together with the problem engineer estimated the timing of their implementation (the engineer’s estimates were overestimated, in your opinion, by about 30-40%). You tightly controlled the timing and quality of the tasks, for the most part everything was completed on time with acceptable quality.

The owner of the product agreed that the speed of the problematic’s work increased during the period of tight control. However, after the end of this period, productivity dropped again.

So ladies and gentlemen, what would you do? Consider both the moral and the practical side of the issue.

Fire the troubled engineer

  • Obviously, the guy is not involved in the atmosphere of the team and does not live in its culture. Poor performance is most likely due to the fact that he takes a lively part in all public activities, but not in solving team problems.

  • Constant tension poisons the life of the entire team. Soon other engineers will refuse to work with him or quit.

  • The most “problematic” engineer will not get a promotion. He is wasting his time and does not grow professionally.

Let it be as it is

  • To be honest, the guy didn’t break anything like that. He works for the allotted time, does some tasks, and therefore brings benefits. Even slower than others.

  • Maybe he doesn’t need a promotion. He himself put it, “works to live.”

Give him a separate mini-project (even with vacancies so that he can recruit a team for himself)

  • An opportunity to grow in terms of management and architectural design. Maybe he will start to treat tasks differently?

  • How can you entrust the project? He does the tasks at the wrong time: there is practically no sense of responsibility. Although, maybe the responsibility to other developers (whom he also recruited) will force him to treat his work differently?

  • Isn’t it a lot of honor to do so many squats for one problem guy? Should each engineer with questions arise to give a separate project? Easier to fire.

Organize constant monitoring of the deadline for this developer

  • Diverting your resources to one developer. You will sag on other tasks.

  • And why would this be so special? Other engineers will immediately notice such brutal microcontrol, and how they will react is unknown.

  • Perhaps after some time he will develop a habit and control can be weakened.

Your opinion?

Take your pick, ladies and gentlemen. Just remember that at the time of reading this article, you are wearing the head of development hat, and the “problematic” engineer is your subordinate.

If you have any more options, write them in the comments.

Similar Posts

Leave a Reply