How to understand developers are really working hard: manager’s guide

Have you ever met the manager who is satisfied with the speed of development? I, personally, not. But sometimes it is even worse than just the speed…I had so many  educational talks with the customers about the development work – why you can’t code 8 hours in a row and why sitting and staring at the wall or even playing table tennis can be a work too for the developer, as he is thinking over the issue during that time. Once one of the top managers entered my room shouting “They are not working! They are browsing Internet!!! What we can do with that?”

The story

So, let me tell you the story about two teams. They both worked on the mobile product for the client (similar complexity). One of the teams was working hard all the time – 10-12 hours a day, they often worked on weekend. Every build release for them was a battle – the managed to ship it on time almost all the time, but it was tough, really tough. Everyone knew how hard they are working – there was constant activity, and anyone could see, just by looking that, everyone pulled together as a team. Rather often they had “critical blockers” before the release and the whole team collected to solve the issue. You could see them standing by the computer and discussing something. They usually found the solution and fix it quickly. If they were lucky that time – the fix didn’t cause any new issues, but sometimes it was a chain of issues – one was discovered after another. So they had to work overnight to prepare the build to release.

The other team was totally different – they started working at 11:00am were leaving home at 6-7pm. They had regular releases too and almost never delayed them. They worked a lot on the architecture of the application to make it easy to understand and maintain. it was not perfect, but they tried to improve it. There were no “rush” before the release, developers could more or less predict the complexity of the new feature. Oh, they also spend too many time on unit tests…and integration tests. They could spent half of the sprint on refactoring. Did they have the easier tasks than the previous team? No.

So, how did that look for the managers from outside? I bet, you suggest something like “The first team is hard-working, the second one is not.” The managers even tried to check the “productivity”, as the comparison of working hours showed – first team posted almost twice more working hours to Jira. So it was obvious for everyone that the second team is very lazy…

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

So, how to understand that your developers are working hard

The story above illustrates that you can’t judge the “productivity” of the team by how busy they look like.

I, personally, think, that not lazy developers are not true developers) Whenever they do the same thing twice in a row – they are too lazy to repeat it, so they try to think of a way to automate the process. They are lazy, so they can’t allow repetivity – they are devoted to eliminate it as much as possible. They always look for the more convenient and productive ways.

So, when manager complaints “they are watching youtube videos during the working hours”, I usually ask him/her – “But why that is the issue? You are not satisfied with the team’s results?”.

Here is the small instruction for the project managers. First, identify, if there are any issues.

If there are no issues with development, you just feel that “this is not right”:

1) It is not possible to code 8 hours a day. At least – you should have time to think, because you are not the typing machine – you should decide what to type first 🙂 I think, “thinking” time can be sometimes several times bigger than “typing” time.

2) As for thinking – you can’t think for 8 hours a day too (I don’t meat thinking about the upcoming vacation – I, personally, can think about that full time). I mean “inventing”. To produce ideas you should have time. You can’t be the “ideas generation machine”. So there always should be some “gap” in the working day.

3) For PM it is very hard to understand, how the developer works – for the manager the day consists of the interruptions. it is the “manager’s flow”. Developer’s flow is the opposite – the continuous flow, when you load all the information about the task and the system into your mind – variables and their values, objects, connections, etc. You have to keep all of that in your mind to write the code, in addition to the “model” of the solution. You get tired of that. Your brains have to rest for a while. It’s like carrying the heavy boxes for several hours – you just have to rest. And you unload all of that from you mind and open Reddit. And at that moment you manager comes and “Hey, why are you not working???”.

4) Improvement. You can’t improve if you are loaded full time. There is just no “room” for changes. So there should be some time left for that too – for experiments, for improvement, for learning.

5) It’s not a factory. You can’t judge the productivity by the simple metrics as the “items produced”. All these simple metrics as lines of code or even “number of features” per certain amount of time. Developers are not fools (unfortunately, they are too smart) – when you start measuring them – they hack your metric. They only way to turn that for good – set the metric of “success” – meeting some common team goals, like releases, value, happy customers. No issues with that? Then nothing to fix.

There are issues with development:

Try to find the root causes. It’s the easiest thing to say that developers are lazy. Even if the developer is not working…just not working all the day long. Try to find out why. May be because you, as the Project manager, suck: he is not interested in the project? Because everything is so boring? Because “there is no point to do anything, I will be the one to blame in the end for any issues any way”?
Yes, sometimes you come across the developers who just don’t want to work. It’s not so hard to see. The solution is simple – you just fire them :).

So, don’t try to fix the people. Fix the environment, fix management, fix impediments. Be the gardener – you can’t make the real flower with your hands, but you can grow it.