Have everything organized beforehand
Time estimates should have been taken care of before you start assigning tasks. If they weren’t, spend a few minutes putting one together with your team so that they have a general idea of what they are expected to do. Be able to explain the tasks to your team and if you can’t, be ready to go find the answers. Setup the communication system you want to use and then show your team how to use it.
If you can, have a database backup ready for their local machines when they start setting up the project. You want to have everything your developers need to get started ready for them. The level of organization you have before you talk to your team sets the tone for how the project or how the sprint will go. Once you take the work to your team they will be ready to get started and they’ll be looking at you when they have questions.
Be available for and willing to answer questions
It’s surprising and sad how many project managers try to avoid talking to their teams. The give out vague instructions and then can’t be bothered for days. Don’t be that person. You are the main person the developers will come to when they have questions about a feature or user story. Be ready to answer every question you get with useful answers.
Even if you don’t know the answer at the moment, let the developers know you will find out for them. Just let them know that you are there for them when they have questions and that you’ll actually respond to them. Make a new Slack channel or something if you need to share common documentation among the group. Having a central place for the team to look over documents and talk to each other is critical for any project manager.
Know what everyone should be getting done and when
Go through the task list at least once a week with everyone. That way everybody has an idea of what the task list priorities for the week are and they can help each other with questions. Be clear with the deadlines and any expectations in the beginning. Nobody should be wondering when they need to have their pull requests ready.
Make sure the priorities of the tasks are defined so people know what to work on after they finish their current task. Just be transparent about what’s really going on and your team will respect you. It’s not a problem if everyone knows everyone’s deadlines and tasks. Most of the time it’s better that way.
Be willing to jump in on the project if you’re needed
If there is a deploy that needs to happen on a Friday night, be willing to stay with your team until it’s finished. When your team gets stuck on an issue, try to get in there and help them figure it out. The worst thing a project manager can do is abandon their team when they are needed the most. It's your job to make sure the team gets the work done on time which means you might need to get in there and help out.
Even if you don’t know how to write code, you can be there to answer questions or to make sure the developers have access to the resources they need. So many project managers make ridiculous requests at odd hours and leave and it starts to build some tension between the team and the managers. You want your team to listen to you and have confidence in you and one of the best ways to do that is to get in the trenches with them.
I can’t say I’ve been a project manager for very long (or if I'll stay one), but these are a few things I learned from some of my good project managers. Anybody out there with more project management experience? Have you switched from developer to manager and do you like it or want to go back?
Hey! You should follow me on Twitter because reasons: https://twitter.com/FlippedCoding