Remote Project Management: Less is more

In our second Advent Calender post, Inpsyder Rich tells something about remote project management. As project manager he knows what developers love and hate when it comes to supporting their productivity.

Working from home can have its upsides. But working fully remote in an agile development team brings along its own set of challenges. Least of which is the daily person to person in-office interaction. You will only realize how MUCH work gets done in an office outside of traditional planning, meetings, tasks and calls to action, once your only means of communication with your colleagues are digital.

As a project manager, the knee-jerk reaction often is to establish a surplus of meetings or to micromanage your developers in order to counter that lack of “instinctive synchronization” as I like to call it. But in doing so, not only will that have a direct negative impact on your developers’ productivity. It will, quite frankly, make your devs loathe you.

Like every project manager, I can understand the need for transparency and efficiency since that is primarily our reason of existence inside a corporate structure. But as a wise old turtle once said: “One often meets his destiny on the road he takes to avoid it.”

So how can you make sure your productivity doesn’t take a hit while working from home? And how do you ensure you don’t drive your developers or yourself crazy? Since this is the internet and the internet LOVES lists, I’ve broken it down into

“5 Things your Developers will love you for”:

1. Make Communication meaningful

Working from home, there are only so many tools you have at your disposal to communicate with your developers. As with everything, communication (or to be specific: YOUR communication) has a certain inflation rate with your developers. If you tend to talk/text too much while delivering too little information or wrongly assess the priority of said information, over time, your developers will learn to ignore you.

Add to that the fact, that a lot of developers are “in the zone” while working. While this sounds bad, you as a PM want them to be “in the zone”, because once a dev is “in the zone” his productivity skyrockets (while admittedly his communication flatlines). Not hearing at all from one of your devs for half a day because he is just killing it, is an achievement! So it is your job as a PM to make sure you disrupt this “in the zone” work as little as possible.

For you, this means you have to categorize and prioritize information, feedback loops and questions accordingly. I know, it can be annoying as hell to wait for an answer for half a day, because it would be “just a quick email”, but trust me, the benefit of letting your people work in peace more than justifies the delay on that “one email”.

However, you can’t have your devs be “in the zone” all day, since you need to synch at one point, which brings us to the next point.

2. One Meeting to rule them all

I for one, hate meetings. I think 90% of them could be emails and if I think about recurring meetings that are there for the sake of it, my blood pressure starts to rise. There is one meeting however, I will fight for like a wounded lion: The Daily (or Daily Scrum, or Morning Meeting or Stand-Up or however you want to call it).

This meeting, who would have thought, is held daily at a fixed time in the morning. It is also timeboxed to run a maximum of 15 minutes. How you structure it is up to your personal style of managing and is impacted by the tools you use, its outcome however should always be the same: Transparency. Talk about what needs doing, who does what, when which developer is “in the zone” (translation for you as a PM: When are you not allowed to disturb them), who needs help etc. Also, don’t forget yourself. Let your team know what you are doing. If anything, it helps them understand what you’re actually doing and sometimes they might even have useful insight that can help you finish off tasks quicker.

But also seemingly mundane things like “I’m off early today” need to be addressed. You’re not sitting next to each other and you won’t be chatting about idle things on a cigarette break like you would in an actual office. This small stuff is important, not only for transparency and synchronization, but also for getting a feeling for what your colleagues are doing and to create a “Team” baseline.

3. Asume, your colleagues are your colleagues for a reason

This is going to be a short one. I’ve seen it time and time again: executives or project leads that do no trust in the skills of the people they work with.
Ask yourself one thing: Do you think you are competent and the right person for the job you’re doing? Yes? Well guess what, so is everyone else!
Just like you, everyone you are working with was hired for a reason. Stop doubting their skill, stop messing with their work and don’t micromanage them. Let them do their job. Easy as that.

4. Kill your own ego

Due to the nature of project management you will end up talking to (executive) management and/or clients more often. If not on a regular basis, than your developers will. Often times this leads to an impression that the PM is higher in the hierarchy than you developers. Well guess what pumpkin, you’re not. You are not their boss, nor their superior. You are a tool. Your Job is to lead them in the direction that is the most productive. You are a glorified human post-it note.

And the fun thing is, the sooner you accept that, the easier it will be for you to find common ground with your developers. Talk shop with them. Let them in on what you like and don’t like about your daily tasks (provided you have clearly marked the “smalltalk” channels of communication accordingly, see point 1 of this list).

While you will have less “professional” communication working from home than in an actual office, you need to make an effort to get to know your people, and for them to get to know you. The “watercooler talk” doesn’t happen by chance when working remote. You have to engage it actively. Make sure you are more than just a notification on their screen to your developers.

5. AAA: Analyze, Adapt and Adjust

This is basic project management, but gets easily overlooked, especially when things get busy. Make sure you sit down in regular intervals to talk about your day to day business. Be open, be objective. Clearly address things that worked and that didn’t work. Make sure to figure out together why things didn’t work and how they could be improved upon and then ACT on it. Project managing a team of developers is an ongoing effort!

* Many thanks to You X Ventures for the photo we are using in this blogpost header.