Lessons learned growing a team for my side project
25 weeks ago, I began a side project to build a language learning app. Today, this side project has grown to 14 developers and 1 designer despite having no revenue, no funding, and no users. Throughout this journey, I experimented with many different ideas to make sure that we build a great team and learned tremendously from the experience. As we approach our January 22nd launch date and enter a new chapter of this project, I would like to share a timeline of the things we experimented with and lessons learned leading up to our launch.
Weekly Sprints
When I first started the project, one thing I committed to is to have a weekly sprint meeting. My first week started with some modest html/css/javascript, and a steady growth in the codebase would follow with each sprint. The first couple of sprints were between me and a friend who was nice enough to mentor me. Our weekly meetings showcased the app’s progress, set goals for the next week, and addressed any issues that came up during the week. As the team grew, the goal of the weekly sprint stayed the same. Since I started the project, I have never skipped a sprint and looking back, I believe that the consistency of a weekly sprint meeting is critical to building a well functioning team. It is the one meeting that everybody knows they must attend no matter how busy they are. Otherwise, they will let the team know in advance that they cannot make it.
New developers
Since one of the reasons I started this project was to learn web development, I eagerly invited other learners to join my project. I found out that there are many junior developers who are hungry for experience, and I welcomed anyone willing to join my project with open arms. With new developers on the team, I made sure to enforce code reviews. Pushing code to master branch was now prohibited and all code must be reviewed and approved by another person. With new people in this project, I made sure that we took the time to go through every single issue, talking through them, and discussing how to implement them. Although this made the Sprint much longer (about an hour), it ensured that everybody had tasks to work on each week.
Tools
To keep track of issue assignments, progress, and code quality, we started with JIRA and Bitbucket. The integration between code and resolved issues sets a high standard for issue tracking and code management. Unfortunately, as we brought on our 6th developer, running into BitBucket payment issues and reading Hacker News inspired us to look for new alternatives. As of this writing, we have been using GitLab for the past 11 sprints and we absolutely love it. In addition to the unlimited number of devs and a private repository, GitLab offered an integrated issue tracking environment. It had everything we need in one place.
Communication
Since the team is remote we needed a way to communicate effectively. We started out with HipChat because of its JIRA and Bitbucket integrations, but it was buggy. There seemed to be random notification failures and our chatroom was a ghost town. This worried me because most people I brought to the team either had full-time work or school. Without an engaging communication platform, it would be easy for people to go back to their daily lives and forget about this project. I thought Facebook messenger would solve this problem (since most people already use it) but it turned out to be a little too invasive. We eventually settled on Slack and after switching to Slack, I noticed that people are much more engaged compared to the previous communication tools.
Getting feedback
Since I did not have any experience leading a team, I wanted to get operational feedback. Unrelated to code, this feedback did not belong on the JIRA board. We then tried using Trello to keep track of retrospective issues like what went well and didn’t go well each sprint. Unfortunately, no one was inspired enough to write feedback on Trello so we stopped it. Now, the sprint leader collects feedback throughout the week as well as during the sprint meeting and simply writes them on our sprint wiki page (a summary page of all our weekly accomplishments).
Sprint leader
When it was just me and a few developers working on this app, we decided that it would be fun to take turns leading the sprint. This tradition has continued and last Friday Manik, a business dev at Inspectlet, led the team through all the features completed in the past week and collected feedback on how the week could improve. At the end of the sprint, he nominated the next person to lead the sprint. This week, it would be me!
No developer left behind
There were many times where I wanted to do everything myself, especially the easy tasks. However, the easy tasks are also really good introduction to the codebase for new developers. I learned to avoid doing the easy tasks. We also made a practice of breaking down more complex issues into exact steps, so that beginners know how to start and can contribute what they know. When stuck, they know exactly which step they need help on. Recently, Bill experimented commenting on the code to guide developers through an issue. It seemed very helpful, we will continue experimenting with this idea.
Issues we came across
- Sprint: When the team was small, we went through every issue together as a team. However, as the team grew, this practice caused Sprint to take a long time. As a result, we changed the sprint to demo all the improvements made during the week so everybody on the team knows and understands the product, set goals for the next week, and go over any issues that came up during the week. Unfortunately, the unintended side effect is that new developers sometimes feel lost and I realized going over issues is actually very helpful for new developers. It was what kept the team going in the beginning. To remedy this issue, our sprints now have two parts: One that everybody attends where we demo new features and plan for the next week, and an optional second half where we walk over all the issue list.
- Sprint Quality: Our weekly sprint meeting is the most important meeting we have and I believe that it is very important to lead it with a consistent level of quality. To accomplish this, I created a Sprint Leader document that gets passed down from leader to leader, updated after each sprint to address any issues that could have affected the quality of that sprint. In the document are lessons on how to inspire the team, things to pay attention to, how to lead the team effectively, and all the important topics and metrics to cover during the sprint.
- Onboarding: I feel that it is very important to bring on new developers properly. Personally, it is hard for me to take a project seriously if I don’t feel welcomed or if I feel that the team is disorganized. I made sure to meet with every developer and either personally help them or have somebody to help them from setting up to getting their first 3 merge requests merged into the codebase.
- Mentoring: I thought that pairing a new developer with a more experienced one would be inspiring for the new developer. In reality, very few people actually like mentoring/teaching others. It is a huge time commitment with very little reward. As a result, we simply just hold regular office hours (and we can do a better job at that).
As we approach our launch date next week and I reflect on the past 25 weeks, I can confidently say that the effort spent building a well functioning team helped me grow even more than what I imagined in the beginning. Since everybody had different interests, this project grew in many different directions that I would not have thought of. If I had built this project out myself, my project would not have:
- Code discussions and reviews for better code maintenance and architecture
- Test suite for code reliability
- Amazing libraries to make the codebase easier to maintain
- Wiki documents introducing different parts of the code base
- Jenkins automatic deploy process after code gets merged in
- Marketing ideas and suggestions
- Beautiful designs to make the app look polished
- Web app AND a native mobile app
- and most importantly, amazing people that inspire each other with new ideas
I hope sharing this experience also helps you start and grow your side project. If you are interested in finding out more about our app, visit https://llip.io.
