The main fear of companies is to lose control over the team. The price of an error is high if the developer with his salary sits and does nothing. However, the remote has become a must-have for almost every company. Then, how to control employees? What tools are good in employee monitoring — time tracking systems, desktop broadcasting?
What if we say that nothing? No need to waste resources on unnecessary control. You will save money and help people to be more relaxed at work.
Now we will tell you how it has been working for us for more than five years.
Bad practices
We communicate with our colleagues and ask our developers about the control during previous jobs. Our verdict is that the more seriously the screws are “tightened,” the easier it is to bypass the internal rules if one wants to since there is a false illusion of control and no one is looking at other aspects of development.
Here are the top 6 useless ideas about team control:
- It’s pointless to take screenshots of your desktop. Are you worried that IDEA should be open on the developer screen without any additional movie windows? Then, what prevents the developer from opening IDEA, making the mouse twitch periodically, and turning on a movie on his personal laptop nearby? It will be more difficult to keep track that he is not doing anything.
- It makes no sense to use a stopwatch to estimate the exact work time spent on each task. The number of seconds spent does not say anything about the quality of the solution and the amount of work done. Sometimes the most useful tasks can be done in 2 hours, and a simple bug can be searched for a week. From the point of view of teamwork, it is important whether the developer met the specified time (his assessment or the deadline set for planning). Also, did he solve the problem efficiently so that it does not come back to him for a fix? After all, you can make a two-hour task in an hour so that it will return after testing for another hour (and this is already 2 hours plus QA resources and a shift in plans).
- You cannot measure developer effort by lines of code. 2 lines of code can “cost” 5 minutes of time or a week of work, depending on the complexity of the task. The complexity is not included at all in this type of assessment.
- It is not worth measuring the quality of the code by the number of bugs without taking into account the nature of these bugs. Sometimes bugs per feature metric reveal the truth about the quality of the code. But what to do when a bug arrives due to a change in requirements (everything was developed according to the old requirements and tested according to the new ones)? Who is responsible for the bug? Who should spend resources on parsing each bug to calculate this metric honestly?
- It is not useful to subtract the time of short breaks from the length of the working day. Periodic breaks are necessary. You cannot sit at the workplace for 8 hours without getting up. There is a mode of work and rest. Over a long distance (from 10 years of experience or more), performance will be better in a person with healthy habits. Many people also think about the task during the short promenade. But if you force specialists to calculate the time of smoke breaks accurately, you can undermine their motivation. It is much more influential. Yes, a person will eventually work out these 25 minutes accumulated in a day, but he will lose the will to work effectively.
- Do not overload developers with unnecessary metrics that they cannot influence. Even the ratio of time spent on implementing a feature and the time spent on fixing bugs may not characterize code. As we noted above, you need to understand the error’s essence. If a person fears his fate on the project due to fluctuations in these metrics, work won’t be comfortable.
Superfluous metrics, accurate time tracking, and other controls require maintaining specific workflows. For example, if analytics are accurate to the second, someone should use these seconds for something. If there are 100 photos of each specialist’s desktop per day, someone will have to look at them. All these ideas create a false sense of control over the situation and devour the resources that could be spent on the development.
We don’t work like that.
Control without control
Our approach is to leave the atmosphere as free as possible. Make the control unnoticeable. This does not mean that there is no control. But it is implemented at a different level and integrated into the work in such a way that we do not have to spend additional resources on maintaining the control system itself. Our control is based on the teams’ professionalism, detailed documentation on projects, and precise requirements — in other words, the normal delineation of powers, where people with different roles should not go into the neighboring area and can rely on each other’s decisions.
Merge request level of control
Merge request is the best indicator of a specialist’s performance. But you cannot apply any universal metrics to it. It is much easier to rely on the professionalism of the team lead.
In our practice, project tasks are maximally decomposed and handed out, preferably one at a time. Yes, sometimes it happens that there are two tasks at work. But face the truth — at one point in time, a person is still thinking about one thing. He cannot write code with his left hand for one task and his right hand for another. As a result, we still come to the practice of “one person — one task.”
When a team leader knows the code and the team well, he can see how long it will take a particular person to solve a specific problem. Is the task taken by a narrow specialist in this matter, who is now at the peak of his productivity? Or maybe it was given to a beginner who knows the stack well but has no experience in the current project? Estimates in the first and second cases may differ by a factor of two, but this is always a more or less understandable value.
The study of a merge request provides a basis for thinking about whether the time spent by a particular person corresponds to the changes that he made. If the work is for an hour, and the task was done in two days, this is a reason to talk. In other cases, everything should go on as usual. Development is a complex and creative task. There is no need to strain those who deal with it with unnecessary control.
Human-level control
This is another level for which the team lead is responsible.
You do not need to be a psychologist to see if a specialist is responsible or not. If a person himself estimates that he will complete the task in 2 hours, and then for a week every day says “it will be tonight,” then something is wrong. The team leads or higher-level managers perfectly catch such “hints” and look at the statistics in Jira even before it becomes critical for the project. Then such issues are resolved on an individual basis.
Control at the level of team
The entire team participates in such control.
Our projects require a team of several people. But at the same time, we do not have teams of 100+ people where it is easy to “hide.” For each new project, a team consists of a minimum required number of people with different roles — analysts, front, backing, testing, team lead, project manager, product owner, etc. Each has its segment of responsibility.
Suppose one of them decided to “lay low” and do nothing. This will instantly affect the project. If analysts miss their part, the whole team does not know what to do. The backend will get stuck — the frontend will notice it, QA will have nothing to test — the entire project schedule will fail. The result, no matter how corny it sounds, depends on everyone.
If something goes wrong, it will be noticeable the next day — the rest of the team will understand that the next stage is not ready — the next has nothing to pick up.
Customer-level control
We have joint developments with customers. On such projects, another level of control is added — feedback from the client. The project manager from our side regularly communicates with the client, receiving estimates of the team’s work and specific specialists. It is also discussed how each of the specialists can grow within the framework of the project.
Timesheets?
Timesheets are used for financial statements. We fill in timesheets for the convenience of financial advisors. Globally, no one needs them anymore.
Sometimes data from timesheets are used to solve side problems. But this is not a common practice. For example, we had the idea of comparing the time recorded in these reports and the estimate on task scheduling to derive a specific “error rate” (and use it in future scheduling). But projects are different, and people are different — it will be challenging to find a universal coefficient.
Also, when filling out timesheets, we sometimes try to write off the time spent on meetings for particular tasks in Jira. But this is mainly done by team leaders and higher-level managers, analyzing their day. Usually, this is their personal initiative, which is not introduced on a team scale. It makes no sense for an ordinary developer with 1–2 short calls a day to have such difficulties. Working on one task at a time, he calls up either on this task or resolves some “corporate” issues (interview, for example).
How to disassemble mistakes
Only those who do nothing do not make mistakes. Anyone can temporarily lose productivity due to some personal circumstance or professional burnout. The main thing is not to tyrannize a person, especially at that moment, because he is already on his nerves. Excessive control and even more negative pouring out create more tension.
If the developer fails, the team lead insures him, trying to minimize the impact on the project and then figure out what happened. Usually, it is enough to make sure that the person is aware of the problem and leave him alone to figure it out for himself. For example, in some cases, when a developer who is only recently in the team makes a mistake for the first time, the team lead can work in parallel to hedge the project. But if a developer knows that he always does a great job himself, the team lead may not participate in this. The main thing is that, on average, the work goes well — so that after a failure or a drop in productivity, a person can fill in the gaps.
