Hiring software developers is often a daunting task. Yet, managing development teams effectively could easily turn into a nightmare.
Especially if you don’t have a technical background you can often feel disconnected from the team as you don’t understand the nature of work. Furthermore, this can obstruct communication and cause misalignment between management goals and team performance.
Luckily in this article, you’ll learn how to be a good manager for a team of developers, even if you don’t have any technical background. You can use these tips and tricks, of course, to manage both fully-remote developers and on-site developers.
Let’s begin!
Managing Product Teams vs Managing Other Teams
Due to the different nature of the work, and the type of people – managing product teams (especially developers) has some important differences compared to managing other teams in the company (e.g. sales or marketing teams).
To understand the perspective of your developers – it is important to note that software developers usually have a lot more job offers (often with better salaries) compared to most other job functions. For the average developer, it is normal to receive messages from recruiters multiple times per week. Therefore, retaining the developers in your team relies heavily on intrinsic motivational factors. To be more precise, developers usually care about these three things the most:
- Building something meaningful (that has a positive impact on society);
- Solving interesting technical challenges;
- Constantly learning and growing as professionals.
That said, a sure-fire way of demotivating your team is to give the team tasks that do not lead anywhere. Tasks that lack meaning.
Another important difference is that developers are almost always introverted people (unlike some other teams). This can often require a different approach to communicating with them that may be different from your usual approach. Developers could perceive a loud and expressive communication style as a lack of substance (if there is no substance to back it up).
Developers like to focus on solving well-defined problems. They perceive this as meaningful and often don’t see the value in a lot of communication that is not about solving a particular problem.
Developers are usually not the best at speaking up their minds. Being supportive, asking people about their opinion, and giving them time and space to execute independently goes a long way to developers feeling like part of the team. Plus, it helps with getting their input incorporated into the decision-making of the team.
Onboarding New Developers
You can think of writing software as writing a co-authored book by a team of people. There are many “ideas” going on in parallel in different parts of the codebase. Some of them are work-in-progress and need to work together with each other. Therefore, giving the codebase to a newly hired person/team (without the support of the people in the old team) usually results in a terrible waste. It can set you back 3-6 months until the new people start to make real progress.
This means that you always need to keep in mind that someone new joining the team should have ideally at least 4 weeks of overlap with at least 1 person from the old team. That’s how you ensure that the newly hired developer knows about the different things that are going on in the codebase. This is how you can have effective developers without them spending 3-6 months figuring out things on their own.
Managing the Development Process
Programming and creating software requires a lot of deep, focused work. For this reason, it’s good to minimize the number of distractions and interruptions.
For example, you should keep the number of meetings between 3-5 meetings per week, maybe 8 meetings per week at most.
The next essential element of managing the development process is the so-called “Sprint”. Most software development teams work in Sprints. The Sprints frame the period of time (e.g. 2-week Sprint), which allows for the team to lock in a fixed scope of work that is expected to be delivered in this fixed period.
The fixed scope for the Sprint must be clear and well-prepared when the Sprint starts (e.g. having all the needed designs ready). Also, the scope of the Sprint cannot be changed – only in rare, exceptional cases. This ensures whatever work-in-progress exists will get completed before moving on to the next tasks.
As you can see, it is considered bad practice to change the direction within a sprint. This is because solving a technical problem has a significant ramp-up period, sometimes 3-6 work days before there is a breakthrough in how to solve it. Switching things frequently will mean that the team will go from work-in-progress to work-in-progress, without completing things.
Whatever tasks are started in a sprint, usually should get completed before new tasks are assigned to the team. As such, Sprints are a great way for organizing the work process in software teams.
The Most Important Thing – Team Standups
If you get just one takeaway from this blog post it should be the following – do regular standups with your Engineering team. This means 3-5 times per week, for a team that has not worked together for a longer period of time (1+ years). The standups are a powerful way of enforcing accountability for results.
Moreover, on these standups, you can make sure that there is a two-way understanding and alignment in the team about tasks and priorities. For example, why does a particular task take more time than expected; is it due to a human error, or it is normal for the task at hand?
Having regular standups will also create an environment where if there are some problems in the development team, they will be uncovered and solved sooner.
How to Do Standups?
Most new managers get overwhelmed by regular standups, thinking they should have a super unique system and agenda for each standup.
However, in reality, it doesn’t need to be anything complicated. The standard structure that all developers are familiar with is more than enough. It goes like this:
- What did you do since the last standup?
- What do you plan to do until the next standup?
- Do you have any blockers or questions?
Everyone in the team should answer those questions at the standup meeting. For a team of 3-4 people, a 20-30 minute standup is usually enough.
Final Words
So there you have it! Be the manager that your team deserves.
Implementing these effective management practices will help you achieve tangible results with your Software team, rather than just monitoring and reporting.
