A little backstory: I began learning to program in early 2012 to build my new startup. In starting my company, I took two atypical approaches:
- I wanted to learn to program to build the first version and
- I decided to continue my tradition of bootstrapping instead of raising money.
Having had a couple of financial successes with my previous companies, I was able to work full-time on Uncover without taking a salary whereas my co-founder and the other people I work with would only be able to work part-time, during their off hours. The differences in our time commitments have left me to take on a lot of different roles, and I wanted to share my experience with project managing part-time people. Because of our unique situation, I’ve come up with a way to project manage Uncover that may also help you with planning out your Side Projects.
The Milestones and Project Roadmap
Because I work with four people who have a very small amount of time each week (anywhere between 2-10 hours), I do not want to waste their valuable hours with putting any of the project management burden on their shoulders. I want them to be able to see exactly what to do next without messing about in an elaborate system.
That’s why we use Google Drive’s Spreadsheet for our milestones. While a spreadsheet may not be practical for full-time teams with a lot of moving pieces, the scope of our work is small, and a well-designed spreadsheet is easy to navigate. Our spreadsheet has six columns:
- Title of the piece of work (e.g. “welcome flow”)
- Design time
- Frontend dev time
- Backend dev time
- Total hours
- Notes
Here’s a screenshot of the header:
Our team consists of three builders other than myself: two backend engineers and one visual designer. Together we get together regularly to estimate the amount of time each piece of work will take across design, frontend and backend. These phases together make up the total hours for that feature, allowing us to plan our work accordingly.
Under the heading “Notes,” we link off to our project’s GitHub Issues (more on that later). Instead of including elaborate notes in the spreadsheet as some do, I prefer to keep all specifications, comments, images and brainstorming confined to a GitHub Issue. Our spreadsheet is only for seeing our Milestones and Project Roadmap.
The only other feature of our spreadsheet is a color-coded priority list. Our priority system is oriented mostly toward what needs to be done first so that no one gets held up waiting for another person to complete their work. Anything left off the priority list is a “nice to have” and not required for our launch.
The To Do List
As I briefly mentioned above, [GitHub Issues] is where we keep our notes for each piece of work on our spreadsheet. The GitHub Issue contains the specifications for the feature and any discussion. Each Issue is linked to our Hipchat, which we use to keep in touch during the day. That is where any comment will appear in the chat feed for everyone to see.
The reason we have chosen to use GitHub Issues is because it’s how we deploy updates to our application. It’s easiest for everyone involved if our engineers can click into an Issue from our spreadsheet, see the specs, and get to work. Then any deployment they accomplish will close the Issue and we’ll be on to the next thing. If we kept our notes in other Google Drive files, Basecamp, or any other project management tool, that’d slow down our development time. While in other files the notes may be subdivided and more logically organized, they wouldn’t be faster for us.
The Check Ups
While 90% of our work is done remotely, we stay in touch every day through Hipchat, and we do get together once every week to two weeks. Even though people are busy at their day jobs and cannot immediately respond to the chat in Hipchat, when they do get a free moment they can join the conversation. An occasional Skype call at night can help clear up anything that wasn’t clear from the day’s messages.
Nothing beats meeting in person, and we try to get together for an hour or two over beers and pretzels once every week to two weeks. During those meetings, we discuss any outstanding topics and revisit our upcoming roadmap. These times are less for getting work done and more for making sure that everyone is up-to-date with what’s going on. Oftentimes, our visual designer and I will present the latest mockups to the team for feedback. He and I get together more often that the rest of the team, as we prefer to work together on Uncover’s user experience and product features. We wireframe together and then he takes that work home to complete the UI late at night.
While nothing beats in-person meetings for making sure that everyone is on the same page, I send frequent (2-3x a week) emails updating the progress of Uncover. While those updates are primarily filled with recently completed product work and what’s upcoming, I also mention more general things like new sales, new business development accomplishments, new revenue milestones, and any informative support emails we’ve received. I don’t want to burn people out by allowing them to forget that we’re not building product just to build it: the update emails remind them that we build product to touch the lives of employers and their employees and to build long-lasting companies. Part-time people can easily be burned out if your only interactions with them are product related. Don’t forget to emphasize the bigger picture and to have fun.