Many of you, dear developers, think that project managers waste your time and boss/babysit you around. All the time we’re: managing (while you know better what to do), coordinating (geez, it will be ready when it’s ready!), monitoring (you just love when people stand over your shoulder when you try to work, don’t you). What does all this useless nonsense mean?

Well, it means that someone needs to shield you from the clients (and vice versa).

In your eyes, our duties might seem like some counter-productive mumbo jumbo but let me tell you something – we do more for successful software development projects than meets the eye. So, today I’m going to address the five most popular whines… I mean issues, I’ve heard from software developers throughout my career. 

1. Why do I have to take care of tasks’ status? I’ll do that at the end of the sprint.

Believe it or not, maintaining order in a chosen task management tool (such as Jira, Asana, or Trello) can significantly improve the performance of the entire project team and open communication for a clear understanding of which team members do what. 

First of all, everyone will save a lot of time. Imagine a situation where each member of the 10-person team wouldn’t update their statuses in Jira. Effect? Nobody knows at what stage the rest of the team is with a given sprint or whether a colleague sitting next to you is doing the task they are supposed to.

Secondly, imagine the project manager or (let’s make it even worse) the client enters the board to check how the sprint delivery is going and sees that a few days before the end of the sprint most tasks are still “in progress” or in the “to do” status and absolutely nothing is delivered. Heads will roll… Fortunately, not yours but you will feel the consequences too – that kind of negligence will cause a lot of pressure and your favourite notorious questions from project managers: “Where are you with this task?”, “Why do you do several tasks at once?”, “When will this be finished?”, yadda, yadda, yadda.

I find no pleasure in asking those questions myself but clients are always in grave fear that the project won’t be delivered on time. That’s why I must devote hours to determine the current state of the sprint. And you are forced to update the status anyway – so, maybe it’s better to do it daily than at the end of the sprint when it’s taking a long moment to remember and write down what you did or didn’t do.

Finally, I often hear the sentence: “Well, this job went to the QA and I don’t know what happened with it”. If everybody took responsibility and updated the statuses, you would know, QA would know, I would know and the client would know. Annoying questions magically disappear! Simple as that.

2. What’s all the fuss project management has with time logging? Done means done.

The budget is seriously at stake here. When software companies are outsourcing developers’ work, they settle accounts with an external customer that ALWAYS wants a report including logged hours. Why? They want to compare them with a timesheet – a document that is the basis for issuing invoices. And guess what happens if the numbers don’t match? Before you know it, the client is making phone calls, writing emails, and sending post pigeons to project managers asking for an immediate explanation why they were charged for so many hours when they can see in the project management tool that the developers weren’t working that long. At this point, it’s too late to log those overdue hours in Jira because it will look suspicious.

Take my word for it – you don’t want to be in a situation where you have to explain to the entire management of your company that the client doesn’t want to pay for the work already done. 

That’s why we are trying to make sure that the whole team, without exceptions, always logs their time on the project’s progress.

It’s not a way to control whether you’re slacking off. It’s a way to prove to our clients that we’re NOT slacking off. And everybody wants to be paid for the jobs they’ve done. 

3. I did the task as it was described. The fact it doesn’t make sense is not my fault.

Well, technically it’s not your fault. But the blind performance of senseless tasks is a very bad idea (and certainly won’t help you be promoted). And YET AGAIN will trigger a time-wasting avalanche of questions from your project manager, whose only concern is to protect the entire team. After all, it won’t be you explaining to the client that a given task was already described and approved and that’s exactly what developers did.

The solution is really easy – you see something weird? Just raise an issue in advance.

In most cases, such a situation occurs when Refinement Backlog isn’t done quite well – why? 

• Because a project manager only has two hands and no time to teach many teams how to do it. 
• Because there’s a general “I-have-no-time” issue among developers. 
• Because of pressuring deadlines. 
• Because of constant changes in the project. 
• Because the task wasn’t described correctly nor verified during planning. 

Go ahead, pick your reason, but all aforementioned cases are very bad practices in the long run. 

So what would a project manager expect from a developer in a situation where the to-be-coded task doesn’t make sense for some reason? 

Firstly, remember that you’re not alone with this – you should mention the problematic task on a daily and ask the entire team to discuss it. Two (or more) heads are better than one and believe me, together you’ll find a solution quickly. After determining what is wrong and how to fix it without ruining the rest of the project, you should talk to the project manager and propose a new version of the task. After the re-estimation and the client’s approval, you can return to work.

By communicating problems, you significantly relieve project management and won’t cause frustration to the client who will be aware that their project scope is fully controlled by the responsible team. And you will be able to become a developer who has a direct impact on the project’s shape and success, show your maturity, and use your professional experience in practice.

4. No can do. Someone else must first complete their task and make that little change I need.

a.k.a. the problem of task granulation on the development side. 

Have you ever wondered why you decompose the scope of work to the smallest sensible element? Doing too many things at once just doesn’t work. Imagine several developers needing a simple change in the code, otherwise, it will be a blocker for all team members. Instead of making a branch with this small change and merging it as soon as possible, developers often come up with a brilliant idea that someone will do it when the opportunity occurs.

That creates two problems. 

• Firstly, we don’t know when and who exactly will finish this task (let alone the mandatory tests performed by the QA team). A day? A week? With good luck, if there are no errors and enough effort is put in, the task can be completed quite efficiently, but other developers will have to wait patiently to start their tasks (wasting valuable time, anyone?). 
• Secondly, the client will ask: “This small change has a task that has no coverage in branches, so how could it be done?”, followed by: “How much did this change will cost us, since there is no logged time because there is no branch?”. From a developer’s perspective, these questions may seem stupid, but I guarantee you that these are real-life examples. This is not what the business (and their budget) expects from us. 

Business isn’t familiar with software development, but it needs simple tools to determine whether the implementation of a given functionality has paid off. And since we create the code and are accounted for it, the client wants to see the effects in the form of branches and commits pinned to tasks in Jira.

Between these two parties, there’s a conflicted project manager, who completely understands both the arguments of developers and the character of the business, and must choose the lesser evil. Unfortunately for you, most of the time it is developers who are going to be told off to follow the established rules, schedule, and properly manage the repository and the division of work. Business is business…

5. Why do my project managers constantly organize meetings? Planning, daily, refinement, retro, review… I waste the time that I could otherwise spend on writing code (or browsing funny cats).

Yes, you could devote your time to coding but (everyone likes a good “but”, right? 😉) do you know exactly what to do or will you rather hit the client or manager with a whole list of questions as soon as you see your tasks for the day? All these meetings have their specific purpose – to facilitate your work when you turn on the computer, put on your headphones, and enter the Matrix to cut off from the surrounding world.

Those meetings are the opportunity for the team to plan work so that each and every one of you can sit down and, without any interruptions, continuously write code, test it, etc. 

Examples? Here you go:

• Refinement – understanding customers’ business requirements. You should ask the client all the questions you need (if they are present in a meeting) or write down a list of questions that will be forwarded to them.
• Planning – choosing tasks for the sprint and listing technical sub-tasks that are required to finish everything on time in a sprint without wondering how something should be done during subsequent implementation.
• Daily – updating team knowledge about where you are with delivering a sprint.
• Retro – recapping what went wrong in the previous sprint and what can be done to improve the situation.
• Review – providing the client with what was done in the last scrum sprint review.

When do these meetings make no sense? When they are badly run.

If the whole team really focuses on the value of the meeting, you will get over with it very quickly, will be able to return to your duties sooner, and be more satisfied with the work you’ve done. Therefore, if you think that you are wasting time on meetings, it means that they are badly run and/or you don’t pay attention and/or you aren’t needed there. 

A good project manager sucks but they are the ones to bring balance to the force

The role of project managers isn’t to be the most important people in the room – we just have to be the most responsible ones. Designers want trendy effects, developers want faster loading, QAs want everything to perform smoothly, the client wants everything done for yesterday, and the CEO reviews every penny. And we just want everyone involved in the process to work and prosper in peace.

Although sometimes it may seem that project managers are making your life more difficult, as you can see from these five examples, their behavior is usually justified by care for both developers and the project itself. I hope that this will allow you to be more forgiving to your PMs and to get more involved during the meetings (which will also be super beneficial for you). Remember that technical knowledge in this profession is not everything – soft skills are equally important.

So the next time you think your PM sucks, think about whether they do it for you.