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 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, address the issues brought up by users, communicate your features to new users, plan with other committers or co-maintainers, etc.
- As a freelancer you have to interact with current customers and prospects. You have to interact with other developers, 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 (on your team and on other teams), 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 prone to complain about them. After all, they are the ones bothering us about some change that needs 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 a 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 a 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 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 are 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 overworked and we all have crazy piles of work that 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 would prefer to work on them first.
But technical aspects are just half of the picture: ordering tasks requires 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 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 affect the business).
2) Let the Developers Know About Deadlines Well in Advance
Did you ever 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 we have 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 it impossible 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 things 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
It might sound implausible, 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, but less so with customers. Yes, it is possible that the SDK the customer gives to you seems… suboptimal. Yes, it could be 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. It is not a good idea to let the customer know these things. It is much better to let the PM rephrase that for us.
And I love when the PMs chase the customer about that decision we need them to make. Or talk with the PM of another team to convince them to answer requests from our team. Yes, we really needed an answer to the several requests you 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 runs smoothly with all the parties involved. We might not even realize the effort he had to put into 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 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 and they may have customers screaming at them. I am sorry for that, but if PMs start to push all their stress on the developers, then we 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-craziness of customers and politics. That is just too much so let’s make a deal: we stress with technical stuff and that is our burden. All the rest (I am sorry for you PMs) is for you to deal with.
5) Make Sure We Work On Relevant Projects
We could happen to work very, very hard on building something that has a limited impact on the company product. While it could be a satisfying 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 get a promotion if you keep working only on irrelevant stuff. Working on something that can really make a difference for the business has several advantages: 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 the worst thing that could happen. We could work on projects that are discarded before or immediately after they are completed. Imagine putting your passion and sweat into 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, and ship.
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.