Manager's guide: how to understand that developers really work

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

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


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 work - there was a constant movement, and everyone could understand just by looking 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 luck smiled at them - the fix found did not lead to new bugs, but sometimes there were a whole chain of them - one problem arose after another. So they had to work all night,

The second team was completely different - they started working at 11 a.m., and went home at 6-7 p.m. They also made regular releases and there were almost never any delays. They worked hard on the architecture of the application to make it clear 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 refactoring. Did they have easier tasks than the previous team? Not.
hard work

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

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

nobody cares

So, how to understand that your developers are working hard

This story demonstrates that one cannot judge team performance by how busy the developers look.

Personally, I believe that 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, therefore they cannot afford repetitions - they get rid of them as much as possible. They are always looking for more convenient and productive options.

So, when the manager complains “they watch the video on youtube during working hours”, I usually ask him / her - “But why is this a problem? Are you not satisfied with the results of the team? ”

Here is a short instruction for project managers. First, determine what the problems are.

If there are no problems and errors in development, but you feel that “this is not right”:

  1. It is impossible to write code 8 hours a day. You need at least time to think, because you are not a typewriter - you must first decide what to print. Thinking time can sometimes take many times more typing.
  2. As for thinking - you can’t think for 8 hours a day without a break (And here I don’t mean thinking about the upcoming vacation - I personally can think about it all day). I meant “inventing”. You need time to come up with ideas. You cannot just be an idea machine. Therefore, there should always be a small “gap” in the working day.
  3. It is very difficult for the project manager to understand how the developer works - for the manager, the day consists of interruptions, this is the “manager's flow”. The flow of the developer, on the contrary, is continuous when you load all the information about the task into your 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 comes in and “Hey, why don’t you work ???”
  4. Progress. You cannot progress if all the time are loaded. You just do not have time for changes. Therefore, there must be time for this - for experiments, for growth, for learning
  5. This is not a factory. You cannot judge performance by using simple metrics like "number of items released." All these simple metrics, such as the number of lines of code or the “number of features” in a given 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” - to achieve some team goals, releases, profits, happy customers. No problem with this? So there is nothing to fix.

work hard

There are errors in the development
Try to find the root causes. The easiest way is to say that the developers are lazy. Even if the developer doesn't work ... just doesn't work all day. Try to find out why. Maybe because you, as a project manager, do your job poorly: is the developer 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 simply do not want to work. This 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 cannot make a real flower with your own hands, but you can grow it.

Also popular now: