How to successfully lead a Software Development Team

I was recently challenged to be a Technical Team Lead of a Software engineering team at Andela. This was a team of 8 enthusiastic entry level developers. We had to work on an open source project that was developed using the Django framework. The main goal was to implement some missing features and add value to the product. However, the most challenging bit was, most of them hadn’t worked with the Django framework before and were evidently new to Python. Half of them were actually having their first experience on a professional software engineering team. The team had 5 weeks to deliver the requested features to the product owner.

Engulfed in the fear of the unknown, I contemplated upon the task before me. It required discipline, patience and mature leadership skills. I had to ensure that my team grows their technical and soft skills. They had to be translated into professional engineers. Here are some of the steps I took to pull off a quality product with a seemingly amateur team.

1. Ask for advice

I embraced the fact that I was new to my newly assigned role. The first thing that came to my mind was to ask for advice from experienced Team Leads at the company. I didn’t want to repeat my predecessors’ mistakes. This saved me time and energy. I further got a mature and professional way of tackling issues.

2. Get to know your Team maturity

After asking for advice and gathering information about my prevalent task, I organized for a short meeting with my team. I was interested in knowing their strengths, weaknesses, technical expertise and self-learning ability.

My team after the team maturity meeting

After the meeting, I gave each one an assignment according to my assessment of their responses. The tasks I assigned ranged from; Hosting the project on Heroku with staging and production URLs, Configuring project CIs (TravisCI and CircleCI) and continuous deployment, setting up pre-commit hooks, creating a Pull Request template for the team, and sanitizing the project code base among many. Since most were still new to the Django framework, I recommended some material that could help them level-up as they prepared for some more challenging tasks ahead of them.

3. Methodology

The maturity of the team is indeed very important, however, the methodology one chooses for a software product may contribute to the product’s failure or success. Software development methodologies range from; Agile Software Development, Feature Driven Development, Rapid Application Development, et cetera.

However, I personally found Scrum, an agile framework to be very effective while developing software. The team and I agreed at a comfortable time when we would do Stand up meetings, which ideally involve declaring what one did for the last 24 hours, what he/she plans to do for the next 24 hours and blockers if any. We aimed at having short one week-long sprints and holding retrospective meetings on the last day of the sprint. All in all, a powerful methodology is always key in any software development team.

4. Set clear expectations

Now that I had acquainted myself with the methodology and maturity of the team, it was time to set clear expectations for the team. I categorized the expectations into two main categories; product expectations and team expectations.

Product expectations were;

1. Each sprint was to have a minimum of 4 stories and a maximum of 8 stories.
2. Thorough tests were to be written for each feature.
3. Development is not about delivering a story and creating a Pull Request. It should be about how the solution impacts the entire product at large, and the amount of value it adds to the product.

Team expectations were;

1. The naming of branches, construction of commit messages and code poise had to be consistent with all team members.
2. Each member was expected to clearly articulate atomic tasks worked upon during the daily stand-ups.
3. Communication was key. Ask as many questions as possible to ensure you have a thorough understanding of the task at hand.
4. A team member wasn’t expected to spend more than an hour on a blocker. Seek help.
5. Take your time to build it right, rather than to beat the deadline.

In order to meet the above expectations, I recommended some resources about the best Django development practices to the team. This was to minimise costly mistakes during code review sessions.

I further encouraged the team to have weekly knowledge sharing sessions. Each member would share something new they learned during the week. This could hence offer them a platform to learn from and challenge each other. This hence played a great part in building trust and knowing each other’s strengths and weaknesses too. Having a team that was self-supporting greatly impacted the output quality of each team member.

Documentation of code is one thing I didn’t overlook. I encouraged them to have reasonable comments in their code. This would help prevent scenarios where the developer that wrote the code and God, are the only ones that can understand what transpired.

5. Be available

Growing teams always require the availability of a Senior Developer to play the mentor role. I had to create time to guide members on the best possible solutions they could use. Though sometimes I could tell them to get creative, in order to see how proactive they could be. Most times I could get surprised by the striking creativity of some members. This hence made me realize how much I could indeed learn from my mentees.

6. Track performance of your individual members

In addition to being available to my team, I got an understanding that I had to clearly track the performance of each individual member. This could help me single-out the areas that needed improvement. The metrics used in this particular exercise were;

1. Quality of output
2. Quantity of work produced
3. Innovativeness
4. Communication skills

I would grade the above on a scale of -2 to 2. -2 meant very poor, -1 meant poor, 0 meant neutral, 1 stood for very good and 2 for excellent.

7. Give your teammates honest feedback

Finally, we used to have weekly feedback sessions where I could share honest feedback with the team. This included things they did well, things that didn’t go well and strategies for improvement. They would too give me feedback about what I did well and where I could improve since we are all lifelong learners.

In addition to the above, we had sprint retrospective meetings where each member would share thoughts about the concluded sprint. The questions asked during the retrospective meetings were;

1. What I loved in previous Sprint
2. What was done well
3. What could have been done better
4. What I hated
5. Fun moments
6. Hindrances or blockers faced
7. Things we should check on in the next sprint
8. Lessons learned
9. How I feel about myself
10. My goals for the next sprint

From my performance tracker, I hence realized that each member’s performance improved from sprint to sprint. Growth was indeed evident from the quality of work produced, team dynamics and stakeholder satisfaction.

I hope the above helps you manage your Software development team better.