Manager's Guide: How to understand that developers really work

This article is a translation of the material located on the link .

Have you ever met a manager, satisfied with the speed of development? Personally, I do not. But sometimes it’s much worse than just speed ... I’ve heard a lot of educative conversations with clients about a developer’s work - why you can't write code for 8 hours in a row and why sitting and looking at a wall or even playing table tennis, a developer can work, too that ponders the solution to the problem at this moment. One day, one of the top managers came into my room with a shout: “They don't work! They are on the internet !!! What can we do about it? ”

Story

So, I will tell you a story about two teams. Both of them worked on a mobile product of the same complexity. One of the teams worked hard all the time - 10-12 hours a day, often working on weekends. Each release was a battle for them - they almost always managed to roll it out on time, but it was not easy, very difficult. Everyone knew how hard they worked - there was a constant movement, and everyone could understand just by looking at the fact that the whole team was busy. Quite often, they had “critical blocks” before the release, and the whole team gathered to solve this problem. You could see them standing near the computer and discussing something. If they were lucky - the fix found did not lead to the emergence of new bugs, but sometimes there was a whole chain of them - one problem arose after another. So they had to work all night to prepare the build for release.

The second team was completely different - they started working at 11 am and went home at 6-7 pm. They also made regular releases and almost never had any delays. They worked a lot on the architecture of the application to make it understandable and easy to maintain. The architecture was not perfect, but they tried to improve it. They were not in a panic before the release, the developers could more or less predict the complexity of the new functionality. Yes, they also spent a lot of time on unit tests and integration tests. They could spend half the sprint on refactoring. Did they have easier tasks than the previous team? Not.

')
What did it look like from the managers? I bet you offer something like “The first team is working hard, the second is not.” Managers even tried to measure “productivity” by comparing the hours spent - the first team posted almost twice as many working hours in Jira. So, it was obvious to everyone that the second team is very lazy.

But what about the results? They were almost the same for both teams - running applications in production, less happy customers. I won’t even tell you that the second application worked better and contained fewer bugs (and this is true)

So, how to understand that your developers are working hard

This story demonstrates that you cannot judge the performance of a team by how busy the developers look.

Personally, I think real developers should be lazy. If they do the same thing twice - they are too lazy to repeat it, so they try to figure out how to automate this process. They are lazy, so they can not afford to repeat - get rid of them as much as possible. They are always looking for more convenient and productive options.

So, when a manager complains, “they watch videos on youtube during business hours,” I usually ask him / her - “But why is this a problem? You are not satisfied with the results of the team? ".

Here is a quick guide for project managers. First, determine what the problem is.

If there are no problems and errors in the design, but you feel that "this is not correct":

1. Unable to write code 8 hours a day. You need at least thinking time, because you are not a typewriter - you must first decide what to type. Time to think can sometimes take many times more typing.
2. As for deliberation, you cannot think 8 hours a day without a break (And here I do not mean the thought of the upcoming vacation — I personally can think about it all day). I meant "to invent." You need time to come up with ideas. You can't just be an idea machine. Therefore, there should always be a small "gap" in the working day.
3. It’s very hard for a project manager to understand how a developer works - for a manager, a day consists of interrupts, this is a “manager’s flow”. The flow of the developer, on the contrary, is continuous when you load all the information about setting yourself into the brain — variables and their values, objects, relationships, etc. You have to keep all this in your head to write code, in addition to the “model” of the solution. You get tired of it. Your brain wants a little rest. It's like carrying heavy boxes for hours — you just need to rest. And you unload everything from your brain and open Reddit. And at that moment, your manager and “Hey, why aren't you working ???”
4. Progress. You can not progress if all the time loaded. You simply do not have time for changes. Therefore, there must be time for this - for experimentation, for growth, for learning
5. This is not a factory. You cannot judge performance using simple metrics like “number of items released”. All these simple metrics, such as the number of lines of code or “number of features” in a certain time. Developers are not fools (unfortunately they are too smart) - when you start measuring them - they crack your metric. The only way to benefit from this is to set the metric of "success" - the achievement of some team goals, releases, profits, happy customers. No problem with that? So there is nothing to fix.

There are errors in the development
Try to find the root causes. The easiest way is to say that developers are lazy. Even if the developer does not work ... just does not work all day. Try to find out why. Maybe because you, as a project manager, do your job badly: the developer is not interested in the project? Because everything is very boring? Because "there is no point in doing anything, I will still be guilty in the end"?

Yes, sometimes you come across developers who just do not want to work. It is easy to understand. The solution is simple - you fire them.

So do not try to change people. Change the environment, change management, remove obstacles. Be a gardener - you can't make a real flower yourself, but you can grow it.