Things I Learned From Managing My First Project

A very long time ago I was an account manager for a very tiny web development firm. We managed about 100 accounts, although at any given time there were only a dozen or so active projects. I enjoyed the juggling and the coordination of the tasks, but I grew impatient with our developer, and taught myself more and more coding skills so that I could take on more and more of the tasks myself. Since then I've worn many hats, and coordinated many projects, but this year was the first time I officially wore the hat of "Project Manager" in my new position at Drupalize.Me. I learned a lot along the way about how to work with an internal project team. Most of it was obvious, but it took the school of hard knocks to bring me back to basics. Here are a few of the truisms I wish I'd remembered sooner rather than later.

Moods are infectious

Every day everyone brings themselves to work and in a distributed team you rely on voice and typed words. Sales folks train themselves to smile when talking on the phone. They say it changes the tone of the voice. If you feel the team is trending towards frustration take the time to check your own attitude. Smile. You might be able to pull the team into your good mood.

To track a trend, use empirical data

Much like watching your weight, daily fluctuations are typical, and it's the trends you want to watch. To monitor your team's health over time, you need to track everyone's attitude on a daily basis. Daily mood logs are used by many therapists to help a person track their well-being over time. Track your team's mood with empirical data instead of hoping you'll be able to see the trends evolve from week-to-week.

Language matters

We had been referring to our launchable site as a "Minimum Viable Product". It didn't resonate with the team, who wanted to create something better than something which was just barely good enough. We changed our language to remove the loaded phrase. In our ticketing system, we updated the backlog title to be "Launch Blocker Backlog" instead of "MVP Backlog" and pride emerged from the team for the product they were working on.

Closure is important

Originally we worked on two week sprints. At the end of a sprint, any ticket that wasn't completed lingered in an old sprint. Based on a comment from James Sansbury about one of his projects we changed how sprints were loaded and completed. Each sprint is now only a week long. At the end of the week, the old sprint is closed. Outstanding tickets are moved to the current sprint. Anyone is allowed to put an unfinished ticket into the backlog. No shame; no blame. We begin fresh today and move constantly forward.

Sort for yourself; format for others

I love spreadsheets. I assumed everyone else did too. They don't. Who knew? Instead of creating spreadsheets to share with others, I now create summaries with markdown within our ticketing system. Now that the team receives the content in their preferred format, I find them more likely to engage in conversation about it.

Adrenaline is finite

When I first started on the project, we kept making optimistic, arbitrary launch dates. Being our own client, we could make whatever deadlines we wanted. "In time for DrupalCon." "At the end of July." We had no empirical data to suggest these deadlines were possible. Shifting deadlines are exhausting and we were burning ourselves out. As soon as we removed the arbitrary dates, people were able to enjoy their tasks a little more instead of constantly feeling a time pressure. This made people happier.

Minor choice makes a major difference

When I was first given the job of "loading sprints", I assumed I was supposed to pick tasks for people. No one told me otherwise. I'd load up the sprints and send out assignments and would be met with the abyss. When we changed to everyone choosing their own tickets from a prioritized list, sprint loading became more dynamic and people had only themselves to blame if they didn't enjoy their tasks. It still takes me about 1.5 days to close a sprint and prepare the next one, but people seem to enjoy their work more during the sprint.

Acknowledgement kindles effort

In software, a job well done is often invisible. If I no longer see error messages, it's as if the solution had always been there. Ensure the effort of your teammates is visible. The more you acknowledge their work, the more they will want to work for you. Even if you are not grateful, or wanting to give thanks, you can still acknowledge the effort someone has invested in their tasks.

Moderate what you change, including your moderation

At first I found the lack of feedback on my processes really difficult. I didn't know how to evaluate if I was implementing good changes or bad changes. So I'd change my approach. Frequently. This made it very difficult for people to track what a week's process was supposed to be. Finally we threw it all out and started again. Consciously. Any changes we make are now immediately documented in a centralized guide. The guide is a trusted document, but also not so holy that it cannot be changed if the documented procedures are not helping the team accomplish their tasks.

I was prompted to write down my truisms after watching this presentation on prezi which had a diagram from The Five Dysfunctions of a Team (I highly recommend you read this book too). It's true that my list doesn't come with a neat little diagram and a cast of characters, but it made me feel better to remind myself of where I'd been and where I was today. Perhaps you have your own basic rules of life that you wish you could go back and share with your past self? "Future me" would love to hear about the lessons "past you" has learned about project management and working with an internal team.