Project Unicorn Learnings

After several months of working with developers and shipping software projects on Project Unicorn - we've learned a few things when it comes to writing and building software with teams that form spontaneously online. During this time, I’ve improved my software skills, picked up new technologies, practiced leading a small team of developers, and now have a clearer picture of what it takes to build and ship software with a small group of developers. Admittedly, it hasn't been easy so let me share some of the challenges we faced early on as a team that I see other remote teams face as well. The focus here is less on technical challenges since those are less likely to derail a team, but more on the challenges when it comes to team momentum, planning, accountability, and looking for help.

• Maintain the momentum The feeling of positive momentum and excitement comes and goes. And when it initially goes, it kills most projects. The same way excitement is contagious when you start a new project so is discouragement. I don’t think there is a single answer to this one except to start by working on something you are genuinely interested in. That interest will manifest itself into excitement when you sit down and work on your project. It will push you through the technical challenges, members leaving your team, or the little to no progress on some weeks. You can’t always control the level of your teammates excitement but you can control yours. Start there and let it be contagious.
• Plan first. Code later. When joining a project on a Slack/Discord team, planning is extremely important. We’ve seen members immediately begin coding and those projects have failed. Here’s how that plays out. They lone wolf it for the first 1-2 weeks then realize they don’t know what they are building. By that time their team has lost momentum. Avoid these urges by planning first. Agree with your teammates on a set of core features, decide on the language/tech you will use, what role will each member will take on, and move forward from there. Break down what features are key for version 1 and drop everything else. This may take 1-2 weeks to do, but trust that this will work out better for your team in the long run. There are a couple practical suggestions here when it comes to planning your features. Organize your project into user stories and create a product backlog. You can try the MoSCoW method to prioritize your features. If you're building a brand new product, ideally you want to boil down your users stories into a feature-set that takes 2 months or less to build.
• Keep each other accountable. Unless 1 or more people on the project makes the effort to assign tasks, then nothing will get done. Progress will slowly stagnate. Eventually everyone loses steam and it’s over. So care enough to track your work. We tracked our work on a GitHub project board. And had weekly check-in calls at the end of the week to talk about what we worked on that week and what we will work on the upcoming week. Here’s an example of our GitHub board. For the calls we just hopped on a Google Hangouts that lasted 30 minutes to an hour. I recapped our call on the Slack group so everyone knew what they were responsible for that week. If no one else on your team is doing this take it as an opportunity and step in to drive your project.
• Ask for help. Everyone is always learning something and coming into a project with the understanding that no one is an expert is valuable. Of course, some developers will be more experienced than others but no one truly knows it all. Find out the skill levels of your teammates, and ask for help when you need it. There is nothing more counterproductive that working with developers who are defensive about what they know, or aren't willing to admit when they don’t know something. Make an effort to admit what you're unfamiliar with. Eventually, everyone on the team realizes that it’s okay to not know something, and the communication on the team turns from proving what you know to discovering better solutions through shared understanding.

The projects that stagnate and fail do so for more than just one reason. Hopefully these points solve the early challenges you will face on your next team project and you're able to successfully ship a project with your team!