How to Build an Effective Development Team From Scratch

Problem

Building an effective development team is hard work that takes time and effort. Managers would often blend different approaches based on their past experiences and values most important to them as leaders.

I was granted an opportunity to build and scale two development teams of only one or two engineers to 10+ engineers. When building the team I was committed to incorporate best practices I knew about and most important values in their very foundations of the team.

Actions taken

I pictured a dream team I wanted to be in and based on my experience I picked the engineering practices and values that I wanted that team to have. That included:

• Changing code should be safe (unit tests covering your back, quick feedback);
• Finding the past context though a clean and linear commit history should be easy and accessible;
• Owning the knowledge all the way to the deployment of the code to production and assuring the possibility of an easy rollback
• We would agree on a set of frameworks and tools for each purpose;
• Ensuring good separation of concerns using design patterns such as the onion architecture;
• Sharing knowledge in a respectful way is of a paramount importance;
• Good enough documentation to get what is found in a git repository is in place.
  

Then I had to ensure that the team would fully own these guidelines.

• I would encourage discussion and solicit feedback by creating a safe space to express proposals, suggestions and comments at every team meeting.
• We would be very diligent about updating these guidelines, allowing for the new ideas and concepts to be developed and if accepted, documented and available.
• I would make sure to safeguard consensus during our decision-making process and get approval from the team -- that would create a rapport within the team and increase engagement.
  

The next thing I did was to automate the verification and allow people to ramp up to use/apply the standard. For example, I used some static code analysis tool that is commenting on pull requests to ensure we find non-compliant changes.

 

Also, I precisely defined a code review code of conduct to make sure that we conform to the highest standards. To ensure that we would be collaborative and respectful, I made sure to emphasize that code reviews are about the code and not people thus removing any ad hominem disagreement.

Finally, I provided the administrative rights for the team contributors to push their code into production.

Lessons learned

• Having well-defined guidelines simplifies the onboarding of new contributors; they get quickly involved in the process of their own improvement.
• The team arrived with their own way of writing/designing microservice and APIs and since most of our projects are similar in design and can be taken over by any individual contributor in no time.
• Using a ”bot” improves the productivity of code reviews as we don’t have to spend time on futile details and can entirely focus on the important content.
• All rules don’t apply to every subteam in the engineering organization. Therefore, it’s important to specify or change some of the rules to fit their specific needs.
• Imposing standards can lead to misunderstandings, such as why some of the rules are there. Empathy and open communication are key in explaining the positive impact standards will bring long-term