Maximizing Efficiency and Innovation and Happiness: A Blueprint for Leading a Successful Dev Team

Why I write this?

As developers, we all know the importance of maintaining up-to-date, well-organized code and working together effectively as a team. But sometimes it can be challenging to achieve this, especially in small to medium-sized teams where everyone is working on different projects. In this post, I’ll share a strategy that I’ve found to be effective in organizing and collaborating with a team of developers. This strategy worked well for me in my previous company, where we were working on multiple apps, and it also helped us transition to working on a single app. I shared this strategy with a friend who recently became the tech lead of a small/medium-sized team of Android developers, and after applying it, he reported back that it worked well for his team too. I hope this strategy can help you and your team work more efficiently and harmoniously.

Step 1:

Hold a weekly meeting of at least one hour, plus have a Google Doc where team members can update asynchronously. Have someone lead the meeting or act as a neutral arbitrator to facilitate discussions and keep track of time. This role is called a Facilitator. If you need more information on how to do this, I highly recommend checking out the YouTube channel of AJ and Smart. They have a lot of great content on the Design Sprint process, and their book is also highly recommended (not affiliated link): https://www.amazon.es/Sprint-Solve-Problems-Test-Ideas-ebook/dp/B017S92JUY/ref=sr_1_13?keywords=design+sprint&qid=1648925988&sprefix=design+spr%2Caps%2C84&sr=8-13

Step 2:

Write three documents (or sections of the same document) outlining the processes, coding guidelines, and testing guidelines for the team. As the team lead, write out your initial thoughts on the best approach, and then have the team review the document and add any additional points to a wishlist. Allow the team to comment on all the points and offer their feedback.

Step 3:

Once everyone has finished adding their points, prioritize them as a team.

Step 4:

Hold a weekly meeting to discuss as many points as possible. If a topic is taking too long, have the team vote on the most popular option. It’s important to note that after making a decision, any remaining proposals should be saved and the team should be made aware that this is the team’s alpha approach. If things don’t go as planned, the team can iterate and try the next best approach.

Step 5:

Once the document is finalized or the team has decided on the most important points, begin implementing the agreed upon approach. Encourage the team to use the “boy scout” tactic, meaning that if they come across code that doesn’t adhere to the agreed upon approach, they should refactor it to follow the guidelines.

Step 6:

The final document should be considered the v1.0 for the team. To keep it up-to-date with newer approaches, team members can open a pull request with a new approach they’ve found. Bonus points if they present the pros and cons of the topic to the team in a presentation. If the team agrees on the new approach, it can become the new standard (v1.1).

Conclusion:

I hope this strategy for organizing and collaborating with a team of developers is useful to you. As I mentioned, it has worked well for me in teams of 6–16 developers, but I’m not sure how it would scale to larger teams. If I have the opportunity to test it in my new company, I will be sure to update this post. If you have any additional questions, don’t hesitate to ask.

Have a great week!