The 5 things a developer expects from a Project Manager: how a Project Manager can help developers becoming much more productive
To be effective as a software developer technical excellence is not enough. On top of that there are several other aspects on which a great professional should focus. Near the top of my list there is the ability to interact with other people involved in the project. Whatever is the nature of your project you will need to interact to get things done:
- as an open-source contributor you have to collaborate reviewing patches or having your patches reviewed, you have to address the issues brought up by users, you want to communicate your features to new users, planning with other committers or co-maintainers
- as a freelance you have to interact with the current customers and with potential ones. You have also to interact with other developers or designers or testers involved in the projects and you need to communicate clearly who is responsible for what
- when working in a company you have to coordinate with the other developers, in your team and in other teams, to communicate with your manager and most importantly to interact with project managers
Developers and PMs… not always love at first sight
Relationships with Project Managers can be a bit controversial from time to time: we as developers are very prone to complain about them. After all they are the ones bothering us about some change that need to go in at 6 PM on a Friday. Or the ones who keep pushing for features which do not make sense to us.
However I think that Project Managers play a fundamental role in successful team. And as a developer I can be successful only if the team is successful. For this reason I think that having a great relationship with Project Managers is they key for delivering results. I was lucky enough to work with amazing Project Managers that really helped me. This was especially true when I was at TripAdvisor: there I met PMs who were absolutely great. That does not mean I did not complain about them with my fellow developers from time to time :)
It does mean however that I understood that if we were going in the right direction, if we were delivering features at an high speed and if we were able to coordinate our projects with the rest of the company it was because of their work.
So I am very convinced that PMs can make a difference. But this difference can be either atrociously negative or wonderfully positive. I am not saying I understand all the responsibilities of a PM and I am sure there is a lot of things they do without interacting with developers like me. I am just thinking specifically to how PMs interact with developers and what kind of expectations I have as a developer towards PMs.
From my point of view a Project manager could make the life of developers easier by doing these five things.
1. Communicate business priorities and consider technical priorities
We are all over-worked and we all have crazy piles of work who someone expects us to do within the week. As a developer I need to be able to evaluate the effort needed to complete each task and the relations between tasks. Perhaps a certain refactoring will simplify developing a certain feature, so it makes sense to order those tasks accordingly. A certain task could take two weeks, while implementing these three other features could require just half a day for each of them. So I could prefer to work on them first.
But technical aspects are just half of the picture: ordering tasks require us to be aware of the priorities business have. What is most important for the customer? Which features can have an immediate impact on our revenues? That is very important for us to know to decide where to spend our energy and what to deliver first. I think PMs need to discuss frequently with developers what are the priorities and understand that business priorities and technical priorities need both to be considered to decide on what we are going to work next.
And sometimes PMs technical priorities are important too: they cannot always be ignored to consider only business priorities, because doing so it is going to affect our ability to deliver software and consequently the business.
2. Let the developers know about deadlines well in advance
Did ever happen to you to find out that something is needed… later today? Or that the customer was promised to receive a new build yesterday? Those are not nice surprises. Let’s be clear: sh*t happens and require us to deal with it. The application goes down and the company loses money every minute: you stop whatever you are doing and you fix it. A new bug is found and it is bad, a security concern needs to addressed as soon as possible. In real life there are things that we cannot plan for. We can just react to them.
However this cannot be the case for everything, we cannot always be doing Emergency-driven development. This is just bad practice. Deadlines need to be agreed upon and communicated, so that they can be planned for. As developers we frequently do not see the whole picture but the same goes for PMs: there are technical aspects that they could be ignoring and that could make not possible to meet a deadline, without knowing far in advance. So please dear PMs: let us know about deadlines as soon as you know them.
Caveat: when I say “let the developers know about deadlines” I mean the real deadlines. One of the worst thing a PM could ever do is to present some fake, self-imposed deadline. Some PMs came up with the idea of assuring themselves a time buffer by telling the devleopers that the customer expects the delivery to happen on the 1st when they actually agreed on the 15th. Maybe they do that because we frequently deliver things late but… guess what? Sooner or later developers will find out and think about all the useless stress or the long hours they went through because of your lies. How do you think they are going to react?
3. Manage communications
I know it could sound not plausible but developers tend to have a few defects. One of them is that developers tend to communicate… differently. They tend to be direct and blunt. And that works great with machines, a bit less with customers. Yes, it is possible that the SDK the customer given to you seems… suboptimal. Yes, it could seems a perfect example of what a bunch of monkeys could do if we would give them a box of cheap whiskey and a manual of all the possible bad practices in software engineering. Well, still it is not a good idea to let the customer knows about that. It is much better to let the PM rephrase that for us.
And I love when the PM chase the customer about that decision we need him to make. Or talk with the PM of another team to convince them to answer to the requests from our team. Yes, we really needed an answer, all the three times we forwarded again the same requests that was ignored for the last couple of weeks.
A fantastic PM will provide us with all the information we need to do a our job and ensure communication run smoothly with all the parties involved. We probably will not even realize the effort he had to put on this.
4. Shield developers from issues
Life in a company is stressful. Stress comes from different sources and it needs to be managed. As Software Developers we deal with a lot of stress coming from technical challenges: a bug which is very difficult to reproduce, an intermittent issue depending on threads synchronization, the new release of a framework which silently breaks everything, an unreliable piece of infrastructure that makes some integration test to fail. We have plenty of reasons to be stressed.
And PMs have too: they deal more than us with the internal politics, they take part in discussions about what features to develop and which not, they could fight to get resources for the team. They could compete with other teams, they have customers screaming at them. Well I am sorry for that but if PMs start to push all their stress on the developers, then we, the developers, will end up being between the anvil and the hammer. We would be both constrained by the reality of technical difficulties and the pink-pony-crazyness of customers and politics. That is just too much so let’s have a deal: we stress with technical stuff and that is our burden. All the rest, I am sorry for you PMs, but this is for you to deal with.
5. Make sure we work on relevant projects
It could happen to work very, very hard on building something that has a very limited impact on the company product. While it could be a satisfaction anyway for someone who loves to build cool stuff in the long run this is going to be detrimental for your career. It does not help you getting a promotion if you keep working only on irrelevant stuff. Working on something that can really make a difference for the business have several advantages instead: it gives you additional motivation, the possibility to get noticed and possibly access to more resources and more support from the organization.
Working on irrelevant features is not yet the worst thing that could happen. It could happen to work on projects that are discarded before or immeditaly after they are completed. Imagine put your passion and sweat on something that is just thrown away. Not a nice feeling, eh? So it is better to work with PMs who do not put you in such situations.
In the end
I think Project Managers intercept many problems before we can even see them. They are our interface with the customers and with the rest of the organization. They ensure we are working on something which will provide value to our users. They keep track of the whole picture so that we can have the luxury to just focus on the next feature to implement, test it and ship it.
And it is a fact that developers take PMs for granted most of the time. I think it is pretty common for developers to underestimate PMs. We often just do not understand all their responsibilities. But trust me, if you work with a great PM and a… not so great one, you will definitely notice the difference.
I hope both us developers and project managers can benefit from a better relationship. I can tell you it is possible to do so: I live with a PM who happens to be my girlfriend :)
| Reference: | The 5 things a developer expects from a Project Manager: how a Project Manager can help developers becoming much more productive from our JCG partner Federico Tomassetti at the Federico Tomassetti blog. |
This was very useful, as I am in a stage where I can implement with my team, what I’ve been learning from my managers last 5-6 years, so this was add-up to that and will absolutely help to bridge the gap which most times leave developers hanging with confusion of what to follow, Programming standards or Deadlines.? This is where Manager/Team Lead comes into picture, to show the way where the developer himself can walk to manage both the standards and deadline.
Thank you very much, Federico…!!!!
Thank you for the nice words and all the best for implementing the best practices with your team!
Very well and useful article.
Thank you Erdem!
Nice ideas, but specially in the “3. Manage communications” section, there are a lot of grammar mistakes. Just thought you might want to know.
I wanted to prove that I need someone to manage my communications :)
hehehe, gotcha ;)
Nice writing (and I like your ending sentence very much, thanks for your girlfriend as well :)
soooo true
Very nice article which captures some of the aspects respectively only a pm or developer can see : I am now a pm (with a developer career in the past) and I think the concepts you explain, the way you do, can be beneficial for both a pm and a dev reading. At the end of the day, great things comes from great teams, and pms have to realize developers are fundamental, as well as developers have to realize the same about pms… If understanding, transparency and trust are the pillars of a team, then the result will be awesome… Read more »
Thank you Emanuele for your nice words. Indeed my “official” goal was to give suggestions to PMs but the unofficial one was to make developers think about how important PMs are and how we take what they do for granted. I think you have a big advantage as a PM with development experience because admittedly we tend to not understand well each other :)