7 mistakes to avoid when managing software developers

Managing developers is as demanding as it is rewarding. Since your job involves dealing with people, technology, and resources, you have to handle many tasks simultaneously.

Therefore, it’s not surprising that occasional missteps happen even to excellent development managers.

Luckily, once you recognize the mistakes that may be hindering you, you’ll be able to turn them into opportunities for improvement.

This article covers the most common mistakes and provides advice on how to overcome them.

Whether you are a technical lead or a project manager wanting to find how to manage your dev team better, you should be aware of common mistakes so that you can identify and avoid them.

Failing to set priorities

Onboard the new dev, plan the upcoming sprint, attend meetings, and, oh—didn’t somebody ask you to review their monthly training plan?

If this is what your average day looks like, the biggest mistake you can make is to try tackling all these tasks at once. However, setting priorities can help you ensure everything is done correctly and on time.

Unfortunately, prioritizing is easier said than done, especially for managers and leaders. A McKinsey survey has shown that only 9% of executives are satisfied with their time allocation, and only a half said that their time management matched their organization’s priorities.

If you don’t want to contribute to such unfavorable figures, you should work on setting your priorities. Different variations of prioritization matrices could help you with this. Here’s one based on the prioritization matrix provided by Process Street.

As you can see, you don’t have to wear sunglasses and a black trench coat to create your productivity matrix (but it would be cool if you did).

All you have to do is list your tasks and assign them a priority status according to their importance and urgency. If that sounds like a daunting task in itself, you might want to try out Process Street’s free template available here.

Let’s see how prioritization works in practice.

Miles Tjandrawidjaja, a software team lead at ApplyBoard, starts each day by listing all tasks he needs to complete and organizing them.

“I’ll also spend time breaking down tasks into smaller, executable chunks. I may do some code review, and evaluate any opportunities to de-risk the project our team is assigned to.”

So, if you give up the notion that everything needs your immediate attention, you’ll not only manage your time better but also be there for your team in a more meaningful way.

Similarly, it’s vital to realize that not all tasks have to be carried out by you specifically. Delegating is an art form, and you can learn more about it in the following section.

Not delegating enough

Managers feel more productive when they don’t spread themselves too thin. Even science confirms that delegating tasks positively affects employees and businesses, but we’re still often reluctant to hand over the reins to our teammates.

Unfortunately, that is a costly developer managing mistake. You can fix it by learning to delegate.

There’s a quote attributed to Napoleon Bonaparte that goes like this: “If you want a thing done well, do it yourself.”

However, we shouldn’t forget that Napoleon never had to manage a team of software developers.

So, let’s hear what people who did have that experience say about delegating.

We’ll start with Andrei Gridnev, a software developer and manager currently working with Up, an Australian digital bank.

Gridnev claims that delegating requires some planning. Here are the elements he suggests managers should decide on in advance.

• Picking responsibilities to delegate
• Choosing the right developers to delegate to
• Coaching developers

So, you shouldn’t ask the first engineer you see to take on half of your to-do list.

For instance, if a junior developer needs mentoring and you don’t have time to work with them yourself, you should first examine which one of your teammates has the most appropriate skills to carry out the task. You should then train them on how to carry out the task well.

A Quora thread on delegating in software teams has revealed that other management experts implement a similar approach.

Here’s a screenshot of the comment written by Katerina Bohle Carbonell, a behavioral scientist working with tech companies.

As you can see, Carbonell’s delegation steps greatly overlap with those that Gridnev mentioned.

However, she also mentioned creating a matrix. So, if you decide to design a priority matrix, you could also do one for delegating.

That way, you’ll be able to quickly assess your delegating options for maximum efficiency.

Not giving enough feedback

You can’t expect developers to make progress if they don’t know how they’re currently performing. Because of that, it’s in your best interest to avoid the common mistake of not giving enough feedback.

There’s always room for improvement when it comes to managers providing feedback. According to Officevibe, more than twenty percent of employees claim they don’t get enough feedback, which impacts their ability to improve.

Based on these figures, your developers will likely be glad to hear comments on their performance.

However, providing excellent feedback requires some preparation.

Nonspecific comments can’t help your devs assess their own work, so you should make sure your feedback is constructive and supported by examples of their work or behavior.

Omer Rosenbaum, CTO of Swimm, a development documentation company, advocates such an approach. He suggests collecting observations, examples, and compiling suggestions for the future before inviting a developer to a feedback session.

The following image shows a part of Rosenbaum’s developer feedback checklist. You can access the entire checklist in his blog post here.

Another valuable piece of advice for giving professional feedback comes from Małgorzata Szwarczyńska, a lead QA engineer at The Software House.

Szwarczyńska warns all managers against getting personal with the feedback. Instead, she advocates giving feedback on the situation, not the person, and finds the “I” communication method the most effective.

For instance, if you notice a dev has developed a habit of ignoring Slack messages, you can include the observation in a feedback session. Here’s the phrasing Szwarczyńska suggests.

“Sometimes I have problems with getting information from you when things are urgent. Can you tell me the best ways to contact you in critical situations?”

All in all, feedback is a valuable tool that you should leverage. Providing it as often as needed will help you get the most out of your team.

Not celebrating small wins

Looking forward to one huge goal will only spark motivation for your team at the beginning of a project.

If you want to manage a team of motivated developers, you should avoid the mistake of focusing on one singular goal and celebrate all the little wins that happen along the way.

We aren’t talking about champagne showers after every code push. Even a Slack channel dedicated to celebrating progress will make your developers feel valued and appreciated.

When you make it a habit to celebrate small wins, you’ll simultaneously build an excellent culture and employer branding. A great example of a company that incorporates celebrating success in their company culture is Zappos.

Zappos, an online retailer company, prioritizes good relationships between management, employees, and customers.

One of their strategies for creating a positive culture is celebrating and sharing success.

Whenever a team reaches a milestone, completes a goal or a project, they announce it throughout the company. There are ringing bells, happy hours, and carnivals.

When celebrating a significant achievement, employees also get bonuses and thank-you gifts.

If you don’t want to spend too much time deciding what accomplishments are worthy of celebration, you could also implement periodical reviews highlighting the accomplishments of the previous week or month.

ApplyBoard, the company we’ve mentioned earlier, does just that.

The engineering team comes together in a video call for demonstrations every Friday. They discuss the code the devs wrote during the week. The team lead finds practice beneficial for the group morale.

“This is a great opportunity for the team to learn from each other, and witness the fruits of our labor.”

So, you don’t even have to wait until you impress a client with a new feature to celebrate. If a dev has found a way around a problem or created a helpful library, make sure you announce the accomplishment.

This will help other team members see that the management recognizes their work and keep them inspired and enthusiastic.

Not investing in your technical knowledge

Relying on your existing technical knowledge is a mistake that technical leads often make. You can avoid it by keeping up with the latest technologies and constantly upgrading your knowledge.

Our article on training developers talked about how most developers are intrinsically motivated to keep advancing their technical skills. However, they expect the management to do the same.

So, if you’ve been promoted from the role of senior developer to the manager role, you have to keep investing in your knowledge to stay relevant and inspiring.

Elye, a technical lead, has compiled a list of mistakes he’s made as a development manager.

One of these was not updating his technical knowledge after being promoted from a developer to a manager.

Here are Elye’s thoughts.

“As I became a senior manager, I now had managers working for me. I thought to myself, perhaps I should focus on leadership and read more management and leadership books. My supervisors and managers should handle all that technical stuff. I was so wrong.”

After no longer being able to understand the challenges the devs were going through, Elye decided to focus on growing professionally in areas that are important to the team, and has remained an effective manager since.

Project managers aren’t immune to becoming disengaged from their teams’ work on the ground, either.

In fact, developers tend to complain about the lack of PMs’ technical abilities, as seen in the Quora thread shown in the following image.

While most devs stated that they didn’t hate PMs, many found the inadequacy of technical knowledge aggravating. Here’s a representative answer.

This programmer feels that PMs receive poor technical education and that they should try to educate themselves about software development to be more effective in the role. Other comments agree with the idea.

To conclude, if you’re leading a software team and don’t have an IT background, you should make an effort to invest in your technical knowledge so that you can be on the same page with the developers you’re managing.

Still doing too much coding yourself

Knowing that you can code better and faster than the developers you’re managing makes it challenging to let go of that part of the job. Still, you should know you’re much more helpful when you manage developers instead of doing all the work yourself.

An excellent software team manager is involved with their team.

Anirudh Garg, an engineering program lead at Asana, frequently meets with his team to ensure everybody is up-to-date on the state of work. You can see him in the lower left part of the image showing one such meeting.

Despite being so engaged with the team, Garg actively tries to avoid the mistake of coding too much.

“Over the last few months, I have transitioned away from coding. I have focused time on pairing with our Product team, balancing work streams in my team, managing stakeholders, and reviewing technical design docs.”

Garg also added that he shifts priorities according to circumstances. In other words, if there’s a close deadline, he’ll join the coders. Otherwise, he’ll focus on management.

Engineering managers across different companies share experiences similar to this one.

In one session of Engineering Talks organized by Plato, the moderator Christian McCarrick revealed that the worst managers are those who spend too much time doing technical work. These managers are too busy with technical work to lead their team properly.

You can find the entire talk on Youtube.

McCarrick asked the panelists, also engineering managers, whether they had fallen into that trap at the beginning of their careers. Not surprisingly, all panelists said they had.

Therefore, you shouldn’t beat yourself up if you occasionally immerse yourself in coding. Just be mindful of the fact that the team needs you in other areas of work as well.

Micromanaging

Nothing can demotivate a team of developers faster than micromanagement. Luckily, the awareness of this management mistake is spreading, so you can easily spot it and avoid it.

To illustrate the importance of the problem of micromanaging, we’ll start this section with a defeating piece of data. According to a Trinity Solutions survey, 79% of employees have experienced micromanagement from their current or past managers.

Moreover, 85% of them have said that micromanagement negatively impacts their morale.

So, what can you do to prevent yourself from micromanaging developers?

You can start with simple steps, such as having faith in them. If you’ve mentored and trained them properly, there’s no reason to start doubting your developers’ abilities.

Letting developers use their skills is a practice advocated by many developers, and Franco Fernando, a PhD software engineer, is one of them.

This expert developer warns against micromanaging and adds that it creates unsatisfied workers. Here’s his explanation.

“Not only the environment becomes less productive, but also people get less and less satisfied with their job and start resigning.

I’ve never seen such a high turnover rate like in teams and organizations micromanaging their employees.”

We know it takes a great deal of confidence in your team to let go of micromanagement. Still, once you learn how to trust them, you’ll create a team of empowered, autonomous developers you can trust.

Conclusion

While reading this, you may have realized that you’re inadvertently making some of these mistakes. If that’s the case, try to think of your realization as an advantage.

Now that you’re aware of what can go wrong in managing software developers, you know how to turn your management style from good to excellent.

We hope that our bits of advice, together with the experience of industry experts we’ve examined, can help you guide your team to more victories and successful projects.